+1 to adding deprecation metadata. -1 to having a plugin... the deprecation warnings should come from maven core itself... ok we can add a plugin for [2.0.x,2.2.1] support
Also if we are adding deprecation metadata, there are a number of other little bits of metadata that should be added, e.g. version comparison scheme (since OSGI rules are different from Maven 2.x rules, we will need a way to flag which rules apply... I see this as being a rule applied to a groupId or at best a groupId:artifactId... if you want to change your version comparison rule halfway through, change the groupId or the artifactId) -Stephen 2009/9/25 Anders Kristian Andersen <[email protected]>: > 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] >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
