Re: [dash-dev] Maven wiki page and suggested repository layout

[Aaron Digulla <digulla@xxxxxxxx>]

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.


> 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

Why separate /orbit and /release? I tend to agree; Orbit contains
non-Eclipse stuff that is IP approved, so if you want to build Eclipse
clean stuff, this is good. Mixing it with /release would mix code from
Eclipse with non-Eclipse things which makes it more messy for people who
don't want Orbit artifacts (for example more entries in the "Add
Dependency" dialog).

Other options?

Btw, Maven uses "artIfacts" not "artEfacts" :-)


>     * |/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.

>     * |/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?

>     * |/nightly| - for storing -SNAPSHOT equivalents of nightly (N)
>       builds; to be purged frequently (nightly?)

Same here.

> 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?)

Yes, keep them around for voting for 30 days.

> 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?

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://blog.pdark.de/