Skip to main content

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.

Jump to: navigation, search

Skalli/User Guide

< Skalli
Revision as of 12:42, 16 May 2011 by Michael.ochmann.sap.com (Talk | contribs) (Added configuration of proxies and SCM mappings)

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.

The Workdir

The working directory of Skalli is the place where all data is stored.

In the subdirectory storage Skalli persists information about projects, favorites, issues, users etc. Customization settings are stored in the subdirectory customization.

The workdir can be specified

  1. by defining a property workdir in the configuration file /skalli.properties (value is the absolute path of the working directory)
  2. by defining the system property workdir=<path-to-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.

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 about the source code repository, the continous integration build (e.g. on a Hudson/Jenkins server), the 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 location of the source repository of a project (in Maven SCM notation) to web sites for browsing, reviewing, activity monitoring 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 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 [1].

Notes:

  • The purpose of a mapping defines fior 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) and activity (for a link to information about the commit activity of a project). However, plugins 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 labe lthat Skalli should render for mapped links in the Development Infrastructure info box.


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

Back to the top