http://www.mail-archive.com/[email protected]/msg102285.html According to current policies, fixing corruptions on Central is not an option. Change policies is not an option. (Change-able policy is not a policy). Option1: Hide the corruption (through added metadata) Option2: Build a new Central which is clean
On Thu, Oct 1, 2009 at 1:20 PM, Stephen Connolly <[email protected]> wrote: > if we have a second repo at all that means that anyone not using a > repository manager will hit both repos for every artifact (which is bad) > > IMHO, central is what it is, all we can do is add metadata to help paint > over the crayon scribbles on the wall from when the children were growing up > ;-) > > -Stephen > > Sent from my [rhymes with tryPod] ;-) > > On 1 Oct 2009, at 18:39, Paul Gier <[email protected]> wrote: > >> What about creating a new legacy repository for deprecated artifacts? >> Stuff that we don't want in the main repository could be moved to a new >> legacy repo. This way we effectively deprecate these artifacts, but it does >> not require any POM or metadata changes. Anyone that needs to use the >> deprecated artifacts, could then just add the legacy repo to their repo >> manager or a profile in settings.xml. >> >> Jason van Zyl wrote: >>> >>> On 2009-09-25, at 5:13 AM, Petar Tahchiev wrote: >>>> >>>> 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. >>> >>> Exactly, this is all part of providing better information over time. >>> There is no big bang cleanup that makes it all better. That is just a pipe >>> dream. We just have to incrementally and diligently clean up what we have. >>> Maven Central is a great resource and it needs some TLC but not cleansing. >>>> >>>> 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] >>>> >>> 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] >> >> >> --------------------------------------------------------------------- >> 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]
