The initial user interface search field is restricted due to security permissions, click on the Repositories link to browse contents manually.

Published Repositories

All repositories mentioned here are considered published and are available for access to external parties.

The moment you deploy an artefact please consider it "gone" and replicated out to all users of your library. If you must delete something please do so in close collaboration with your development list as you will need to ask each developer to delete files from ~/.m2/repository/org/locationtech

LocationTech maven repository URLs can be accessed using either "group" or the recommended "repositories". We have used "repositories" in all the following examples.

Releases Repository

The releases repository is limited to artifacts that have been through the CQ process (and thus reviewed by the IP team).

Project Specific Releases and Snapshots Repositories

Project specific repositories are available on request, perhaps used for informal collaboration between projects around beta releases, or to catch surprise transitive dependencies being added during a nightly build.

Third-party Repository

Publishing ip-approved (and potentially subsetted) artifacts to the server is a multi-step process.

One will need to have write access to the /shared directory which is attached to the LocationTech Hudson servers as well as other build servers. This will require 'shell access'; you can request this access from http://portal.eclipse.org/

Once you have shell access, you can scp the jars to a path under /shared/.

Build Considerations

CQ Management and Use of Release Profile

The publishing of artifacts (jars, source and javadocs) requires careful consideration for others. For developers integrating our content we have to very carefully avoid conflict with other development teams and follow the guidelines used for publishing artifacts to maven central.

Publishing Unmodified

Please be advised that this approach only works for *unmodified* artifacts as the maven repository system is willing to cache the first copy of the jar obtained (for example from maven central, your national mirror, or team repository).

Formally Publishing a Subset

When publishing a work that has only been approved in part buy the CQ process (described as a "subset" in Orbit) we are left with a conflict. Technically this work is a fork, with the following advice from Choosing your Coordinates:

However if the project does maintain a presence on Central, then if there's a fork you have two choices:

B1) get the original project to upload the artifacts in their own groupId (unlikely since there's a reason it was a fork)

B2) upload them under your the forked project groupId (presumably one you own and appropriate for the fork)

It is of course preferable to ask authors to fix any IP issues encountered and avoid the need for subsets.

Using this advice you may publish a "subset" using your own project co-ordinates:

Do not be surprised if your subset ends up being re-published by other repositories. This is by design, and why you have provided a unique coordinate for your fork.

Using a subset for release

One way to protect consumers of your library from managing the complexity of a formal subset it to switch between:

Deploy artifacts using unmodified dependencies: This prevents the proliferation of forks ... users of your library will fulfil these transitive dependencies from maven central rather than the LocationTech repository

Assemble releases using subset dependencies: The jars assembled for distribution are limited to those approved by the CQ process

For this approach each subset is published using the CQ number as the classifier. This allows different teams to work with alternative subsets of the same dependency.