[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rt-pmc] Re: [jetty-dev] jetty dependency's and 'releasing' within eclipse
|
Note: We should probably start considering changing the venue of this
discussion to something liek the Architecture council mailing list or
bug or something. I fear that others will have similar questions and
we'll end up repeating information.
On 20-Jul-09, at 12:43 PM, Joakim Erdfelt wrote:
Speaking as a developer of a Maven Repository server (Apache
Archiva) ...
The repository is only to be considered a database of artifacts, the
structure, naming, and organization within the repository is only
such to prevent conflicts. That's it. (CPAN operates on the same
philosophy)
This is great and makes complete sense. Does it follow that producers
choose what to call their artifacts and groups as long as the combo is
unique. That is, if Eclipse "owns" the org.eclipse group then it can
choose how to structure it no? Simiarly, if a producer publishes an
artifact as foo_1.0.0.bar.jar it should, at least natively, come back
with the same name for consumers? Otherwise it would seem that
somehow the repo/database, is changing things and having external
effects.
Anything other assumptions about what a maven repository is, and
what its used for, and any other deeper meaning into the naming and
whatnot is irrelevant.
I agree. That is why the relationship outlined earlier between group/
artifact id and the BSN is IMHO problematic. Its good as a guideline
if no one says otherwise but if the artifact is already a bundle and
already has a filename then producers should be able to publish it can
consumers retrieve it as such. Perhaps I have misunderstood. To
clarify, would it be acceptable for the eclipse community to publish
their artifacts in maven central as
org.eclipse.foo:org.eclipse.foo.bar.fred:1.0.0.v2090719
If we did so, would the natural/default consequence for consumers be
that they would get an artifact called
org.eclipse.foo.bar.fred_1.0.0.v20090719.jar
The client mechanisms that downloads the artifacts for use elsewhere
is responsible for managing the names themselves. (ant/ivy, maven,
rake, hudson, intellij, netbeans, jruby, debian-build, jam, jide,
etc... all manage the downloaded artifacts in different ways)
In general how do these mechanisms recover the original name of the
artifact? Conversely, what is the typical approach to uniquifying
files on disk if for example there are two artifacts called "logging"
with version 1.0? I am curious as this is a direction/approach that
we have not used so I'd like to learn how it works.
And that repo now has 161,000 jars on it now[1], with many newer
languages embracing the central repository concept (ruby, groovy,
scala, python, etc ...).
The central maven repository has a *huge* community built around it,
it would be a shame if eclipse is not participating in this
extremely robust developer community.
The central repo idea is grand. There's never been any dispute about
that. We have a few thousand bundles in Galileo. If we put all of
them in maven central and tell the community that all the bundles are
there, go use them, will everything continue to work? Will all the
bundles suddenly have different file names, will the eclipse
infrastructure / tooling continue to work? what about all the
existing documentation and people using scripts and whatever to do
whatever? will people have to change their builds and deployment
strategies?
I am sure that assumptions have been made in both communities. These
need to be surfaced and addressed.
My ONLY point here is that while such a direction is likely of great
benefit, for the good of all, it needs to be set in the larger context
and thought through to ensure the promise can actually be achieved.
Jeff
