On 19 Mar 2011, at 11:55, Aaron Digulla <digu...@hepe.com> wrote: > Am 19.03.2011 12:36, 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. > > Why restrict access? It only causes us more work and if people want a > "single hand serves all", they can add our thirdparty and releases to > their POMs and they are done - everything we serve will work out of the box.
We don't want (either intentionally or unintentionally) to end up being a public proxy for either central or the other sites. Otherwise people might just point solely to the Eclipse site for consuming not only Eclipse stuff, but also non-eclipse stuff. Having a mirror to optimise internal builds is a nice to have but we don't need to expose it publicly. > Btw, Maven uses "artIfacts" not "artEfacts" :-) I think this is an American English vs British thing. Will try and remember but auto correct sometimes gets the better of me. > >> * |/milestone| - for storing milestone releases (for the latest >> build only?) e.g. 3.7M1, 3.7M2 > > I'd support the current release train - since the next M1 doesn't start > with the official release of the previous train, there is some overlap > so people have several weeks(?) to update their POMs. What I was thinking is we'd keep 3.7Mx until 3.7 was in release build. Come to think of it, I don't know how we'd easily figure out what is in "this" build. Perhaps we should have: /milestone/helios /milestone/indigo /milestone/juno|jupiter|jason That way, we keep milestone/helios around until after Helios ships and then can drop it en masse. We can create a grouped repository /milestone so people can consume but would need to adjust publishers when the new release train was revved. > >> * |/integration| - for storing -SNAPSHOT equivalents of integration >> (I) builds; to be purged frequently (weekly?) > > Weekly sounds pretty short. I'd keep the last 5 versions. > > What options does Nexus offer for purging? Can I purge on a count basis > or only on a time basis? I'm pretty sure you can do both. Last five should be doable but we might want to round that down if storage becomes an issue. >> 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: >> o |/repo1| - mirror of http://repo1.maven.org >> <http://repo1.maven.org/> >> o |/repo2| - mirror of http://repo1.maven.org >> <http://repo1.maven.org/> > > Those two entries have the same URL - what's the difference between > repo1 and repo2? > Ah - the URL should have repo2 as well. They're the same but prevents failure if repo1 goes down, like it did briefly a couple of weeks back. Also allow us to hook up regional mirrors easily without changing the /central alias. Alex _______________________________________________ dash-dev mailing list dash-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/dash-dev
