Package nl.toolforge.karma.core.location

The location package contains classes managing location objects.

See:
Description

Interface Summary

Location

A Location describes a location aspect of a module.

Class Summary

BaseLocation	BaseLocation implements some generic Location functionality.
LocationDescriptor	Helper class to be able to read locations from an xml structure.
LocationFactory
LocationLoader	Loader class to load all gain access to Location instances.
LocationType	Enumeration for the location type.
PasswordScrambler
RemoteLocation

Exception Summary

LocationException

Exceptions relating to Locations.

Package nl.toolforge.karma.core.location Description

The location package contains classes managing location objects. Each module in a manifest has a location attached to it. A location could be a CVS repository, but also a Maven repository; it is a rather abstract definition of a place where a module is located.

Location objects are stored in XML files. The nl.toolforge.karma.core.LocalEnvironment class defines the directory on disk where location xml files are stored. Location xml files are generally company-wide and as such they could very well be managed in a version control system.

The following XML blob shows the structure of such a file:

<?xml version="1.0">
<locations>

  <location type="cvs-repository" id="cvs-local">
    <protocol>local</protocol>
    <host>localhost</host>
    <port>2401</port>
    <repository>/home/cvs</repository>
  </location>

</locations>

Each location has a type. The domain for the type attribute is defined in the Location interface. The id attribute is the unique identifier for the location. In the manifest definition, a module requires one of these ids.

Depending on the type of location, certain elements are expected. A CVS location, for instance, requires a protocol, host, port and repository.

Next to the location definition, certain types of locations require authentication data as well. Since these location definitions can be maintained in a version control repository, authentication data is stored separately. Karma knows which types of locations require authentication data and will try and read this from the configuration directory ($HOME/.karma). A file named as authenticator.xml is expected.

The following XML blob shows the structure of such an authenticator file:

<?xml version="1.0">
<authenticators>
  <authenticator id="cvs-local" username="asmedes">
  <authenticator id="sf-toolforge" username="asmedes">
</authenticators>

The snippet above has a matching id-attribute for the cvs-local location and will be used as input for the corresponding location object.

Some bits are not yet implemented in this release. The second <authenticatorgt&; element instance shows a situation, whereby only a username is configured. This would apply to configurations where a public SSH key is stored on the (remote) server, so no password should be given upon each request. Will be implemented later.