Hi all, I also like the idea about deprecating artifacts, or whole directory structure. A step forward would be to create a maven-dev-approved repositories or artifacts. Imagine you are using an outside repository that is really messed up (or worse - anyone can put anything any time). What maven the team could do is setup a ground base of rules, so that if you want your repository to be maven-dev-compliant you must follow them. Later if you are using artifacts from repositories that are not maven-dev-compliant, there could be a message warning you. To me it doesn't really make sense to create a new repository without improving the process of using the repositories. Otherwise, as Brian pointed, we will end up with a new repository, which has the same data, and no one is using the old repo.
Cheers, Petar. Because without it doesn't really make sense creating new repository and 2009/9/25 Stephen Connolly <[email protected]>: > +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] > > -- Regards, Petar! Karlovo, Bulgaria. - - - - - - - - | Author @ Manning Publications. | CEO @ Phamola | BGJUG-Bulgarian Java User Group Leader. | Apache Maven Developer. | Apache Jakarta PMC member. | Jakarta Cactus Lead Developer. | Codehaus Plexus Developer | Blogger: http://weblogs.java.net/blog/paranoiabla/ - - - - - - - - Public PGP Key at: https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
