On 2009-09-24, at 3:16 PM, Albert Kurucz wrote:
Requirements for the POMs are defined as:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
I call the artifact corrupt (regarding Maven Central Compliance) if
the POM of the artifact does not fulfills the above requirements.
There are corrupt ones have made it to the Central, because the guard
was sleeping.
The growth of the central repository is a function of our initial
flexibility and, quite honestly, lack of tooling to enforce what we
now consider necessary. Hindsight is always 20/20. It's easy to look
now at all the problems in the repository with a critical eye, but the
fact of the matter is if we were extremely strict to begin with we
probably would have stunted its growth. Maven use has grown, the use
of the repository has grown and problems with metadata are now felt
globally. We are talking steps to clean this up and make it easier for
projects to do the right thing.
The fact still remains that Maven Central has always been a public
service and a point of convenience for Maven users. That was the
impetus for its creation. We have probably been a bit too lenient
insofar as letting organizations rsync directly but live and learn. We
do have the tools now in Nexus to prevent garbage from going into the
repository but its an organizational and project choice to use these
tools.
The plan going forward is to encourage projects to do the right thing.
We're not going to retroactively remove or change things from Maven
central.
I have never recommended anyone doing real development in an
organization connect directly to Maven central. It's a great way to
populate the repository you have internally but the management of the
binary dependencies is just as important as the management of your
source. People have traditionally done this in house using Apache and
having to fix things internally but these days there are tools like
Nexus, Archiva and Artifactory. There is no silver bullet to have a
healthy artifact repository that you can depend on in your
organization. It takes some work, just like anything else. Can we make
that easier for people? Sure, and we're making steps toward that goal
on a daily basis. We'll have some tools in Nexus that we're going to
make available to OSS projects with the 1.4 release which should start
relieving a lot of the pain and ensure the quality we need.
Rules are enforced or here comes the anarchy...
The severity of the damage?
The Central should be an example of good practice. Otherwise...
On Thu, Sep 24, 2009 at 4:41 PM, Brian Fox <[email protected]> wrote:
On Thu, Sep 24, 2009 at 12:04 PM, Albert Kurucz <[email protected]
> wrote:
Brian,
Probably no one ever suggested that the corrupt artifacts should be
fixed, because fixing is not even possible (every artifact must be
signed by the creator).
The question is whether you prefer the corrupt ones to be removed or
just wait until they become obsolete and no one would care about
that
they stay or not (quantity or quality has the priority?).
To take this further you must define corrupt. If something is
demonstrated truly and completely broken and/or dangerous, it will be
removed immediately. If a pom is missing a dependency, that doesn't
qualify, it's up to the project to fix and produce a new release in
that case.
The work on preventing the ugly ones from getting in I agree has the
first priority.
But will you address (and when?) this second most important task,
the
garbage collection?
We are actively working on technology to address this, expect details
in the near future. What do you mean by garbage collection?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
