I think it is TOTAL important we keep the contract:
*** This is a long standing rule that we do not remove or change the
contents of central ***
Therefore a way out could be to start making deprecated tags in the
directories.
Then we could come up with a *** maven-deprected-dependency-plugin
*** that
could warn users against various bad / deprecated / moved artifacts.
Consider a director xxxx with pom.xml and other files.
adding a file called deprecated.xml could deprecate the directory /
parts of the files etc.
then running
mvn deprected-dependency:check
would list usage
This could be combined with options / tools in archiva could help too.
best regards
Anders Kristian Andersen
On 25/09/2009, at 06.11, Brian Fox wrote:
This has already been done once in history, between M1 and M2 and look
how we still have that mess to deal with all the time. Doing this
again serves no one well, making sure new data coming in is clean is
more productive for everyone. Who would _want_ to deploy their stuff
to the "old" repo? No one. The hurdle to get to the new repo would be
the same as putting the checks on the current repo for all new
artifacts.
On Thu, Sep 24, 2009 at 8:37 PM, Brett Porter <[email protected]>
wrote:
Moving over to dev...
So here's a thought - why don't we create a "new" central repository?
- a new repository with strict acceptance rules regarding POMs,
signatures,
ownership, etc.
- if there's a new metadata format needed (recently discussed),
this would
use it
- validated artifacts could be moved over and requests to the old
rewritten
(in the same way we maintained the maven1 repo)
- default Maven can ship with both repositories enabled, but a "best
practice" would be to turn old central off (or better, use a
repository
manager that doesn't access it / only access it for acceptable
artifacts)
The main issue is finding a way to overcome confusion when an
artifact is
changed - you want "old" builds to keep using the same one it
always did,
but new builds to use the new one (and cope with potential revision
of
metadata without breaking builds). This is the sort of thing that
could be
built into Maven in a new version and the new repo format only
accessible
from that version.
Thoughts?
Cheers,
Brett
On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
Jason and Brian, thanks for the explanations.
Understood, the policy of not removing anything from Maven Central
serves a purpose.
I wish there would be another publicly Maven repository, which is
maintained with rules enforced. This repo could even have a rule
(additional to the old and unenforced rules) that only Maven built
projects can enter, maybe even more restriction: only the designated
Continuous Integration server can upload to it.
This pure Maven repo would not be able to compete with Maven Central
regarding size or the number of artifacts, but some OSS developers
might prefer to use from and supply to this one instead of the big
and
ugly.
On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <[email protected]>
wrote:
On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <[email protected]
>
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.
Correct, but changing them is not an option because it will
destabilize builds. This is a long standing rule that we do not
remove
or change the contents of central.
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
