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 http://wiki.eclipse.org/Maven#Proposal 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. /central - for aggregating: /repo1 - mirror of http://repo1.maven.org /repo2 - mirror of http://repo1.maven.org /codehaus-snapshots - mirror of http://snapshots.repository.codehaus.org/ - may be needed for findbugs for tycho builds /codehaus - mirror of http://repository.codehaus.org/ /sonatype - mirror of ?
_______________________________________________ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
