[
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:55, Aaron Digulla <digulla@xxxxxxxx> 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
