Getting Started

Tutorials

How to Implement Skalli Extensions

You can write your own extension. A Skalli extension are all display & application logic elements needed to provide a specific functionality. You can simply bring Skalli to visualise their information.

Find out how to write your extension:

Configuration

There are different configuration possibilities for Skalli.

Various configuration settings can be managed via REST API calls. (There is a good Firefox add-in for that: RESTClient)

If you do not know how to obtain the Skalli sources and how to start it, please visit Contributor Guide first.

Choosing the Storage Service

Skalli is not bound to a certain storage mechanism but searches the runtime for suitable implementations of the interface org.eclipse.skalli.api.java.StorageService. If not explicitly specified, Skalli will use a file system based storage mechanism by default.

In order to switch to an alternative storage mechanism, you can either

use the OSGi console to enable the storage service implementation you prefer.
define the system property skalli.storageService and set it to the qualified class name of a storage service implementation.
define the property skalli.storageService in the configuration file skalli.properties which must be added to the root directory of the org.eclipse.skalli.core bundle. If you don't want to change that bundle, create a fragment with org.eclipse.skalli.core as fragment host and add the properties file there. Or download a blueprint from here: [1]. The value of the property again is the class name of the service implementation.
change the service component descriptors for your storage service implementations. For example, the component descriptor for the default FileStorageService resides in the OSGI-INF folder of bundle org.eclipse.skalli.core (look for the file FileStorageComponent.xml). The enabled attribute controls whether the service is started by default. For details see the documentation about OSGi Declarative Services.

Using FileStorageService: Setting the Workdir

If you are using the file system based storage mechanism, you should define a working directory. The file system storage service will use that directory for all project related data and customization settings.

The workdir can be specified

by defining a property workdir in the configuration file skalli.properties.
by defining the system property workdir=<path-to-working-directory>

The value of the property in both cases must be the absolute path of the working directory. If workdir is not set explicitly the current directory is used as default.

Using the Local User Store

Skalli is able to use LDAP for user management. If you want to use a local user store instead the LDAP user service in Skalli has to be disabled.

Open the OSGi console and type ls. Search for a service with the name org.eclipse.skalli.core.user.ldap and stop it (disable <ID>). Search for the service with name org.eclipse.skalli.core.user.local and start it (enable <ID>).

Users are stored in the directory <workdir>/storage/User. Each user is persisted in a separate XML file named <userId>.xml in this directory.

Example of a <userId>.xml file:

<org.eclipse.skalli.common.User>
  <userId>ad</userId>
  <firstname>Arthur</firstname>
  <lastname>Dent</lastname>
  <email>arthur.dent@milliways.com</email>
  <telephone>+000 314159265</telephone>
  <room>42</room>
  <location>End of the Universe (and then right)</location>
  <department>kitchen</department>
  <company>Milliways - The Restaurant at the End of the Universe</company>
  <sip>sip:arthur.dent@milliways.com</sip>
  <detailsMissing>false</detailsMissing>
</org.eclipse.skalli.common.User>

Note that userId must be the id of an authenticated user of your web container (Jetty, Tomcat etc.). For example, in Jetty you can define user ids in etc/realm.properties.

Configuring Administrator Users

Skalli administrators are allowed to do more than normal users, eg. they are allowed to:

edit all projects
delete projects
see issues for all projects
configure a Skalli instance

Skalli adds the command admin to the OSGI console that allows to list, add and remove Skalli administrators:

skalli admin [-list] [-add <admin_id>] [-remove <admin_id>] - maintain set of user with administrative permissions

If you for example want to add the user skalliadmin to the group of administrators type

osgi> skalli admin -add skalliadmin

Administrators are persisted in the directory <workdir>/storage/Group.

User Details Links

Defining the URL pattern for links to pages showing details about committers, contributers, members etc. In the Team info box on a project's detail page clicking on the name of a committer leads to the user's detail page.

PUT https://<your-host>/api/config/view/userdetails

<userdetails>
  <url>http://www.eclipse.org/projects/lists.php?list=projectsforcommitter&param=%s</url>
</userdetails>

Notes:

%s is a placeholder for the user's identifier.
The example above generates links for Eclipse comitters.

Proxy

If you are behind a firewall you should configure the proxy to use for outbound HTTP connections (e.g. to allow Skalli checking URLs defined by projects). For that you need to issue a PUT request to /api/config/proxy.

Example:

PUT https://your-host>/api/config/proxy

<proxy>
  <host>proxy</host>
  <port>8080</port>
  <nonProxyHosts>*.example.org;*.example.com;non-proxy-host</nonProxyHosts>
</proxy>

Note, Skalli administrator rights are necessary to perform that request.

Automatic URL Inference from SCM Location

A Skalli project can enable the "Development Infrastruture" extension to provide information about the project's source code repository, continous integration build (e.g. on a Hudson/Jenkins server), bug tracker used to track issues etc. Additionally, a link to a browsable frontend of the source code repository can be entered (e.g. a link to a gitweb server), as well as a link to a code review system like Gerrit.

However, Skalli also supports a mechanism that allows defining automatic mappings between the source repository of a project (in Maven SCM notation) and web sites for browsing of the source code, reviewing of commits etc.

For that you need to issue a PUT request to /api/config/devInf/scmMappings.

Example:

PUT https://<your-host>/api/config/devInf/scmMappings

<?xml version="1.0" encoding="UTF-8" ?>
<scmMappings>
  <scmMapping>
    <id>review.gerrit.example.org</id>
    <purpose>review</purpose>
    <pattern>^scm:git:git://(git\.example\.org(:\d+)?)/(.*)\.git$</pattern>
    <template>http://{1}:8080/#project,open,{3},n,z</template>
    <name>Gerrit Code Review</name>
    <provider>git</provider>
  </scmMapping>
  <scmMapping>
    <id>browse.gitweb.example.org</id>
    <purpose>browse</purpose>
    <pattern>^scm:git:git://(git\.example\.org(:\d+)?)/(.*\.git)$</pattern>
    <template>http://{1}:50000/git/?p={3}</template>
    <name>Browse Sources in GitWeb</name>
    <provider>git</provider>
  </scmMapping>
  <scmMapping>
    <id>browse.git.eclipse.org</id>
    <purpose>review</purpose>
    <pattern>^scm:git:git://git.eclipse.org/gitroot/(.+\.git)$</pattern>
    <template>http://git.eclipse.org/c/{1}/</template>
    <name>Browse Sources on Eclipse.org</name>
    <provider>git</provider>
  </scmMapping>
</scmMappings>

The first entry for example defines a mapping between Git repositories matching the regular expression (git\.example\.org(:\d+)?)/(.*)\.git (meaning: all Git repositories hosted by the server git.example.org) and a Gerrit code review system (purpose review). When a project defines an SCM location matching the given pattern, Skalli creates a link from the given link template by replacing the numbered variables with the content of the corresponding regular expression groups extracted from the SCM location. In the example above, {1} stands for the first group, i.e. the host git.example.org (without port), while {3} denotes the third group, i.e. the repository name. For example, an SCM location like scm:git:git://git.example.org/myproject.git would map to http://git.example.org:8080/#project,open,myproject,n,z.

For more details about Java regular expressions and groups refer to [2].

Notes:

The mechanism described above is not limited to Git as SCM system. It is based on a simple regular expression matching/replacing mechanism and should be applicable to all kinds of SCM systems.
The purpose of a mapping defines for which kind of links a mapping should be applied. Predefined purposes are:
browse

for a link to a browsable frontend of an SCM system like gitweb

review

for a link to a code review system like Gerrit

activity

for a link to a graphic visualizing of the commit activity of a project

activitydetails

for a link to details about the commit activity of a project

create_bug

for a link that allows to create bugs in a bugtracking system
Skalli Extentions are free to define additional purposes.
The id can be defined freely, but must be unique in the list of mappings.
The name tag defines the label Skalli should render for mapped links in the Development Infrastructure info box.
The numbered variable {0} is replaced by the project's symbolic name, e.g. with technology.skalli.

Mappings for Eclipse Projects

If you use Skalli pimarily for managing of projects at eclipse.org, you might find the following mappings interesting:

<?xml version="1.0" encoding="UTF-8" ?>
<scmMappings>
  <scmMapping>
    <id>browse.git.eclipse.org</id>
    <purpose>review</purpose>
    <pattern>^scm:git:git://git.eclipse.org/gitroot/(.+\.git)$</pattern>
    <template>http://git.eclipse.org/c/{1}/</template>
    <name>Browse Sources on Eclipse.org</name>
    <provider>git</provider>
  </scmMapping>
  <scmMapping>
    <id>createBug.bugs.eclipse.org</id>
    <purpose>create_bug</purpose>
    <pattern>^https://bugs.eclipse.org/bugs/buglist.cgi?.*(product=[^&amp;]*).*</pattern>
    <template>https://bugs.eclipse.org/bugs/enter_bug.cgi?{1}</template>
    <name>Create Bugs on bugs.eclipse.org</name>
    <provider>bugtracker</provider>
  </scmMapping>
  <scmMapping>
    <id>activity.git.eclipse.org</id>
    <purpose>activity</purpose>
    <pattern>^scm:git:git://git.eclipse.org/gitroot/(.+\.git)$</pattern>
    <template>http://dash.eclipse.org/dash/commits/web-app/active-graph.cgi?project={0}</template>
    <name>Commits Activity Meter</name>
    <provider>git</provider>
  </scmMapping>
  <scmMapping>
    <id>activitydetails.git.eclipse.org</id>
    <purpose>activitydetails</purpose>
    <pattern>^scm:git:git://git.eclipse.org/gitroot/(.+\.git)$</pattern>
    <template>http://dash.eclipse.org/dash/commits/web-app/summary.cgi?company=y&amp;month=x&amp;project={0}</template>
    <name>Commits by Company by Month</name>
    <provider>git</provider>
  </scmMapping>
</scmMappings>

Automatic URL Inference from Mailing Lists

PUT https://<your-host>/api/config/info/mailingList

<mailingListMappings>
  <mailingListMapping>
    <id>listserv</id>
    <purpose>browse </purpose>
    <name>Browse</name>
    <pattern>^(.+)@listserv.example.org$</pattern>
    <template>https://listserv.example.org/{1}</template>
  </mailingListMapping>
  <mailingListMapping>
    <id>listserv.archive</id>
    <purpose>browse-archive</purpose>
    <name>Browse Archive</name>
    <pattern>^(.+)@listserv.example.org$</pattern>
    <template>https://listserv.example.org/archives/{1}</template>
  </mailingListMapping>
</mailingListMappings>

This mechanism works similiar to the SCM mappings above. If a mail address is entered that matches the given pattern, then the template is evaluated and variables are replaced with the corresponding regular expression groups of the pattern. For example, myproject@listserv.example.org would give the URL https://listserv.example.org/myproject to browse the latest content or https://listserv.example.org/archives/myproject to browse an archive of the mailing list, respectively. The defined name is rendered as link label. You may register mappings for different mailing list providers in parallel.

Predefined purposes:

browse

a link to a browsable view of the latest content of the mailing list

browse-archive

a link to a browsable archive of the mailing list

subscribe

a link that allows to subscribe to the mailing list

unsubscribe

a link that allows to unsubscribe from the mailing list

Note, extensions are free to define additional purposes. The Mailing List info box ignores the purpose and just renders all links that match the entered mailing list(s).

Mappings for Eclipse Projects

If you use Skalli pimarily for managing of projects at eclipse.org, you might find the following mappings interesting:

<mailingListMappings>
  <mailingListMapping>
    <id>listinfo.eclipse.org</id>
    <purpose>subscribe</purpose>
    <name>Subscribe/Unsubscribe</name>
    <pattern>^(.+)@eclipse.org$</pattern>
    <template>https://dev.eclipse.org/mailman/listinfo/{1}</template>
  </mailingListMapping>
  <mailingListMapping>
    <id>mhonarc.eclipse.org</id>
    <purpose>browse-archive</purpose>
    <name>Browse Archive</name>
    <pattern>^(.+)@eclipse.org$</pattern>
    <template>http://dev.eclipse.org/mhonarc/lists/{1}</template>
  </mailingListMapping>
</mailingListMappings>

Scheduling of Validation Jobs

Defining a schedule for the asynchronous validation of projects.

PUT https://<your-host>/api/config/core/validations

<validations>
    <validation>
        <schedule>
            <daysOfWeek>*</daysOfWeek>
            <hours>*/2</hours>
            <minutes>0</minutes>
        </schedule>
        <minSeverity>ERROR</minSeverity>
        <action>VALIDATE</action>
        <userId>homer</userId>
        <entityType>Project</entityType>
    </validation>
    <validation>
        <schedule>
            <daysOfWeek>MON</daysOfWeek>
            <hours>2</hours>
            <minutes>0</minutes>
        </schedule>
        <minSeverity>INFO</minSeverity>
        <action>QUEUE</action>
        <userId>homer</userId>
        <entityType>Project</entityType>
    </validation>
    ...
</validations>

The first entry validates all projects daily every second hour (e.g. a 0:00, 2:00, ...) and reports issues with at least severity ERROR (other possible values: INFO, WARNING, FATAL). The entries of <schedule> support crontab notation defining the minutes (tag <minutes>), hours (tag <hours>) and days of the week (tag <daysOfWeek>) when a validation should run. 24-hour format is used for <hours> (possible values: 0..23). The day of the week can be defined with numbers (0=Sunday,1=Monday,...,7=Sunday), long names (SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY, SATURDAY), or short names (SUN, MON, TUE, WED, THU, FRI, SAT), respectively. Note that the names are handled case-insensitive, i.e. Sun, SUN and sun mean all the same.

Supported actions are

QUEUE

put all entities of the given <entityType> (currently supported values: Project) into the queue for entities to be revalidated. The validation is done asynchronously.

QUEUE_ALL

put all entities of all types into the queue for entities to be revalidated (<entityType> is ignored). The validation is done asynchronously.

VALIDATE

validates entities of the given <entityType> (currently supported values: Project). The validation is done synchronously. Note, depending on the number of entities to validate and validators to be executed this may consume considerable resources on a Skalli instance. You may want to schedule such actions during night times and choose an appropriate <minSeverity>.

VALIDATE_ALL

validates all entities of all types. The validation is done synchronously.

The specified <minSeverity> is passed to all registered validators, so that each validator can decide, whether it should produce issues or not. For example, a validator that checks links to other websites could be designed to produce FATAL issues, if the URL of the link is not a valid URL, ERROR issues, if the link points to a non-existing host, WARNING issues, if the host is temporarily unavailable, and finally INFO issues, if the link is redirected permanently and a project committer should adapt the link.

The severity of issues is defined as follows:

FATAL

The project (or one of its extensions) cannot be persisted before the issue is resolved. This severity usually indicates a syntactical problem, e.g. a malformed URL. Therefore, it makes not much sense to run a scheduled validation with <minSeverity> FATAL because such validations operate on persisted project data.

ERROR

The issue is serious but the entity can still be persisted. Example: A given URL is valid but points to a non-existing host.

WARNING

The issue is not serious, but should be fixed.

INFO

Not an issue at all, but a hint how the data quality of an entity could be improved further.

News and Alerts

Defining the target for the What's New? link, as well as alert and info messages.

PUT https://<your-host>/api/config/view/news

<news>
  <url>http://host.examle.org/whatsnew/technology.skalli</url>
  <alert>This is a test system!</alert>
  <info>Next Planned Maintenance: tonight 10pm</info>
</news>

Notes:

Users are directed to the news URL when clicking on the version link in the upper right corner, too.
The alert message is rendered in a red box, while the info message is rendered in a light blue. box The latter can be used for example to announce a planned downtime. Both messages are positioned below the tag cloud.

Branding

Branding of Skalli by overwriting the default page title.

PUT https://<your-host>/api/config/view/branding

<branding>
  <pageTitle>Projects@Eclipse</pageTitle>
</branding>

Notes:

The default page title, if not otherwise configured, is Skalli.
The string maintained in <pageTitle> defines the second part of the page titles only. Depending on the page displayed the left part of the page title gives additional information about the page content. For example, the detail page of a project shows the name of the project in the page title.

Gerrit

Set credentials for connections to a Gerrit server:

PUT https://<your-host>/api/config/gerrit

<gerrit>
<host>host.example.org</host>
<port>29418</port>
<user>Arthur</user>
<privateKey>-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,61D359AC0BC0C4BD
 
rSy...
</privateKey>
<passphrase>password</passphrase>
</gerrit>

Additional information:

Consider encrypting your private key so that it is not transferred and stored in plain text. Use <contact> to specify a link to reach out for help with respect to the Gerrit server. A link, labeled Gerrit Contacts, will then appear on the page. If empty no link will be rendered.

REST API Usage

All information associated with a project and its extensions, issues, users, access statistics etc. can be retrieved from a REST-like API with HTTP GET commands. Write access currently is only partly implemented.

In general, the REST API uses the same URL scheme as the browsable UI. For example, the detail page of a project with name technology.skalli is accessible with the URL

https://<your-host>/projects/technology.skalli

The corresponding REST information then can be obtained with a GET request like

GET https://<your-host>/projects/technology.skalli
Accept: text/xml
Referer: <contact information of the calling client, e.g. a user id or mail address>

The Accept header tells Skalli to return REST information as XML document instead of an HTML page. The Referer header is used by Skalli to track clients. Since the REST API is not yet finalized, the contact information provided in the header can be used to inform clients about changes in the API.

Alternatively, instead of sending HTTP headers, you can obtain the same with

GET https://<your-host>/api/projects/technology.skalli?referer=<identifier>

Note the prefix /api/ at the beginning of the resource path.

XML Schemas for the REST API

As stated above, the REST API provides all resources as XML documents. XML schemas for these documents can be downloaded from a running Skalli instance with

GET https://<your-host>/schemas/<schema>

where <schema> is one of the following:

project.xsd: Schema for a single project resource
projects.xsd: Schema for the all projects list
user.xsd: Schema for a user resource
issues.xsd: Schema for validation issues reported for a project
common.xsd: Common declarations used by all schemas

These schemas are documented and should be self-explaining.

Extensions provide their own XML schemas, for example:

extension-info.xsd: Schema for the Info extension (basic stuff like link to home page, mailing lists etc.)
extension-people.xsd: Schema for the People extension (info about project leads and committers)
extension-devinf.xsd: Schema for the Develoment Infrastructure extension (info about SCM locations, bugtracker etc.)
extension-scrum.xsd: Schema for the Scrum extension (additional info for projects following a Scrum-like development process)
extension-maven.xsd: Schema for the Maven extension (additional info for projects built with Maven)
extension-review.xsd: Schema for the Review extension (reviews and ratings of a project)

Note, this list is not complete since Skalli supports custom extensions. It is not required, but strongly encouraged that custom extensions provide a suitable XML schema, too. Skalli searches bundles implementing custom extensions for a folder named schemas and makes schemas found there available for download automatically (compare for example the bundle org.eclipse.skalli.model.ext.misc). The naming convention for schema files is extension-<shortname>.xsd. For details consult the tutorials and documentation about writing custom extensions.

Common Tasks

List the Projects

To collect information about all the projects available in Skalli issue a GET request to /api/projects. As a prerequisite you must be logged into Skalli and provide your user ID within the request:

GET https://<your-host>/api/projects?referer=<userId>

The response looks similar to:

<?xml version="1.0" encoding="UTF-8" ?>
<projects xmlns="http://www.eclipse.org/skalli/2010/API" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.eclipse.org/skalli/2010/API http://localhost:8080/schemas/projects.xsd" apiVersion="1.4">
  <project apiVersion="1.4" lastModified="2011-05-11T15:03:48.254Z" modifiedBy="admin">
    <uuid>98620072-2e54-4e71-9ce1-51a81fc8761c</uuid>
    <id>hello</id>
    <template>default</template>
    <name>Hello World</name>
    <link rel="project" href="http://<your-host>/api/projects/98620072-2e54-4e71-9ce1-51a81fc8761c"/>
    <link rel="browse" href="http://<your-host>/projects/hello"/>
    <link rel="issues" href="http://<your-host>/api/projects/98620072-2e54-4e71-9ce1-51a81fc8761c/issues"/>
    <phase>initial</phase>
    <description>The Hello World projects is a default dummy project</description>
    <extensions/>
  </project>
  <project>...</project>
 </projects>

Note that by default only some basic information is returned for each project, but no information from the project's extensions. However, by adding the query parameter extensions=<comma-separated list of extensions> to the URL, you can choose to retrieve information from selected extensions, too.

For example, with

https://<your-host>/api/projects?extensions=people,devInf&referer=<userId>

you could obtain the project leads and committers of all projects as well as information about the development resources (repositories, bugtrackers etc.) used by these projects.

Project Details

The previous request returned info on all the projects. You might want to limit this to only one project. To do so provide the project's ID in the request:

GET https://<your-host>/api/projects/<projectId>?referer=<userId>

It is also possible to list the issues for a specific project:

GET https://<your-host>/api/projects/<projectId>/issues?referer=<userId>

The response will return known validation problems in XML format.

User Info

To get the contact information of the user issue a GET request to api/user:

GET https://<your-host>/api/user/<userId>?referer=<userId>

As a prerequisite, you should be logged into Skalli and provide your user ID.

The response will look similar to:

<?xml version="1.0" encoding="UTF-8" ?> 
user xmlns="http://www.eclipse.org/skalli/2010/API" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.eclipse.org/skalli/2010/API http://<your-host>/schemas/user.xsd" apiVersion="1.0">
  <link rel="self" href="https://<your-host>/api/user/<userId>" /> 
  <userId>...</userId> 
  <firstname>...</firstname> 
  <lastname>...</lastname> 
  <email>...</email> 
  <phone>...</phone> 
  <sip>...</sip> 
  <company>...</company> 
  <department>...</department> 
  <location>...</location> 
  <room>...</room> 
</user>

Admin Tasks

List of Bundles

To get the statuses for all referenced bundles issue a GET request to /api/admin/status

GET https://<your-host>/api/admin/status

The response will contain a list of bundles:

<bundles>
 <bundle>
      <name>org.eclipse.skalli.common</name>
      <version>0.1.0.qualifier</version>
      <state>Active</state>
    </bundle>
  <bundle>...</bundle>
 </bundles>

with their names, versions and states (ACTIVE, INSTALLED, UNINSTALLED, STARTING, STOPPING, RESOLVED)

Statistics

To see the information about the usage of your application issue a GET request to /api/admin/statistics

GET https://<your-host>/api/admin/statistics

The response provides you with statistics from the last start of the application and contains such info as the amount of users, their IDs, locations, which browsers and URLs they used, which search strings, etc.:

<?xml version="1.0" encoding="UTF-8" ?>
<statistics xmlns="http://www.eclipse.org/skalli/2010/API/Admin" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.eclipse.org/skalli/2010/API/Admin http://localhost:8080/schemas/admin-statistics.xsd" apiVersion="1.0">
  <info>
    <started>01.06.2011 16:07:02</started>
    <snapshot>03.06.2011 16:34:47</snapshot>
    <duration>02 days 00:27:45</duration>
  </info>
  <users>
    <count>0</count>
    <userIds/>
    <locations/>
    <departments/>
  </users>
  <browsers/>
  <referers>
    <referer count="12">admin</referer>
  </referers>
  <usages/>
  <searches/>
</statistics>

Backup Resources

To backup the project data use the following request:

GET https://<your-host>/api/admin/backup?referer=<userId>

This returns a ZIP file containing the storage folder.

Nexus Connection

If the nexus connection is set the MavenResolver determine the MavenCoordinate Versions from the nexus. The last version is displayed in the Maven Project Information-Extenstion.

An HTTP-Request is used to get the needed information about the current available versions.

The Url looks like: [nexus.url]+ "service/local/data_index/" + [nexus.domain] + "/" + [nexus.target] + "/content?g=" + [groupId] + "&a=" + [artifactId] + "&from=" +[from] + "&count=" + count. (For more details have a look at the implementing class NexusUrlCalculator)

GET https://<your-host>/api/config/ext/ngp/resolver

<nexus>
    <url>http://myNexus:8081/nexus/</url>
    <domain>repositories</domain>
    <target>build.milestones</target>
</nexus>

Terms

[Skalli] Extension	All display & application logic elements needed to provide a specific functionality. You can write your own extensions and bring Skalli to visualise their information.
Info Box	A single box displaying the information of one extension to the user
Project Details Page	The main project page containing the info boxes
View Mode	The project details page without edit forms and without initially visible editing capabilities
Navigation Panel	The list of links on the left hand side (currently of the project details page)
Edit Mode	The forms page when clicking edit in the navigation panel of the project details page

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Skalli/User Guide

Contents

Getting Started

Tutorials

How to Implement Skalli Extensions

Configuration

Choosing the Storage Service

Using FileStorageService: Setting the Workdir

Using the Local User Store

Configuring Administrator Users

User Details Links

Proxy

Automatic URL Inference from SCM Location

Mappings for Eclipse Projects

Automatic URL Inference from Mailing Lists

Mappings for Eclipse Projects

Scheduling of Validation Jobs

News and Alerts

Branding

Top Links

Gerrit

REST API Usage

XML Schemas for the REST API

Common Tasks

List the Projects

Project Details

User Info

Admin Tasks

List of Bundles

Statistics

Backup Resources

Nexus Connection

Terms

Breadcrumbs

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Skalli/User Guide

Contents

Getting Started

Tutorials

How to Implement Skalli Extensions

Configuration

Choosing the Storage Service

Using FileStorageService: Setting the Workdir

Using the Local User Store

Configuring Administrator Users

User Details Links

Proxy

Automatic URL Inference from SCM Location

Mappings for Eclipse Projects

Automatic URL Inference from Mailing Lists

Mappings for Eclipse Projects

Scheduling of Validation Jobs

News and Alerts

Branding

Top Links

Gerrit

REST API Usage

XML Schemas for the REST API

Common Tasks

List the Projects

Project Details

User Info

Admin Tasks

List of Bundles

Statistics

Backup Resources

Nexus Connection

Terms