Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dash-dev] Maven wiki page and suggested repository layout
On 19 Mar 2011, at 11:14, Aaron Digulla wrote:

Am 19.03.2011 00:00, schrieb Alex Blewitt:

This would leave:

* Releases
* Maven central
* Central m1 shadow

Why mirror central? People should set up their own proxy. I'd vote that
our public Nexus server only serves Eclipse stuff.

If *we* need stuff, we should set up a second, internal Nexus server
which isn't visible to the public.

I'm tempted to agree with this. However, is it possible to restrict repository access in the open source nexus version to only allow access for some repositories based on (say) IP ranges? Failing that, a second instance on the same host but different port would probably suffice, and can be controlled on a build machine basis with an appropriate settings.xml file.

We might want to temporarily have a 'testing' repository so we can publish e.g. the trial work that Aaron has been doing.

The testing repo should be permanent but things in there should be
purged after a while (say three-six months).

And as said in the other mails, we need repos for nightly, integration
and milestone builds.

The reason why I want to separate those:

1. I don't want to mix snapshots and releases
2. I don't want to keep milestones, and I builds forever.
3. This makes it easier to weed out old/broken stuff. If something has
happened, we can delete the whole N/I/M repo and rebuild it. If we mix
stuff from several sources, cleaning up a mess will be a lot more work.
4. It allows consumers to make sure they don't pollute their projects
with unwanted stuff by accident.

So please also add

* nightly
* integration
* milestones

So are we all happy with 


Nexus is capable of segregating and aggregating individual repositories. To facilitate the management of artefacts hosted, it is proposed that the Nexus repository is configured with a number of subsidiary repositories which will hold different content, as follows:

  • /orbit - for holding Orbit approved external dependencies
  • /release - for storing final releases, e.g. Helios 3.6, 3.6.1, 3.6.2
  • /milestone - for storing milestone releases (for the latest build only?) e.g. 3.7M1, 3.7M2
  • /integration - for storing -SNAPSHOT equivalents of integration (I) builds; to be purged frequently (weekly?)
  • /nightly - for storing -SNAPSHOT equivalents of nightly (N) builds; to be purged frequently (nightly?)


It is proposed that the release entries are permanently available, whilst milestones may be cleared out after the final release, and nightly and integration builds are cleared out automatically.

In addition, for testing:

  • /testing - for storing -SNAPSHOT equivalents for testing purposes; to be purged occasionally (monthly?)

To support automated builds at Eclipse, it may make sense to proxy publicly available repositories, although these should not be publicly available.


Back to the top