[
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
|
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)
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.
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)
That said, the de-facto storage standard is what is in use by
http://repo1.maven.org/maven2/ .
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.
[1]
http://www.jarvana.com/jarvana/info/repository_statistics
---
Joakim Erdfelt /
joakim@xxxxxxxxxxx
On Sat, Jul 18, 2009 at 7:07 AM, Jesse McConnell
<jesse.mcconnell@xxxxxxxxx> wrote:
> Whatever scheme is selected to put things in Maven should work for all
> Eclipse things (not just special cases) and likely cannot expect that
> thousands of bundles be renamed (either their BSN or their file name).
>
> That is the challenge here.
>
fwiw, I know that sonatype has worked on this issue in the past with
nexus, I believe working out a mechanic whereby a typical p2
repository can be referenced via maven convention without the forcing
of 1000's of bundle renames.
imo, once artifacts leave their maven central repository location what
they get named for their respective consumer is up to that consumer,
if they want to be named org.eclipse.foo_ver that is fine, or they
could be renamed to simply start.jar...the onus is on the comsumer to
make sure they know what is going on with things. If something like
nexus where you allow you to automatically download it in such a way
that it is named in the eclipse sanctioned way automatically, great!
the most important thing here to me is that we have eclipse bundles
available in the maven central repo with good transitive dependency
metadata in place in such a way that we can use standard build tooling
like maven or ant+ivy or buildr or whatever to access them.
preferably within the month :)
cheers,
jesse
