Return-Path: Delivered-To: apmail-maven-dev-archive@www.apache.org Received: (qmail 20542 invoked from network); 2 Oct 2009 12:57:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Oct 2009 12:57:55 -0000 Received: (qmail 78149 invoked by uid 500); 2 Oct 2009 12:57:55 -0000 Delivered-To: apmail-maven-dev-archive@maven.apache.org Received: (qmail 78027 invoked by uid 500); 2 Oct 2009 12:57:54 -0000 Mailing-List: contact dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Developers List" Reply-To: "Maven Developers List" Delivered-To: mailing list dev@maven.apache.org Received: (qmail 78017 invoked by uid 99); 2 Oct 2009 12:57:54 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Oct 2009 12:57:54 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of pgier@redhat.com designates 209.132.183.28 as permitted sender) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Oct 2009 12:57:42 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n92CvJEA030632 for ; Fri, 2 Oct 2009 08:57:19 -0400 Received: from pgier.redhat.com (vpn-225-150.phx2.redhat.com [10.3.225.150]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n92CvIOI010177; Fri, 2 Oct 2009 08:57:19 -0400 Message-ID: <4AC5F8CB.90303@redhat.com> Date: Fri, 02 Oct 2009 07:57:47 -0500 From: Paul Gier User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Maven Developers List Subject: Re: a cleaned up central repository? References: <6766C815-831C-4EAE-9D47-3787775B0ED9@apache.org> <88c1b40909250258w44d511c9jc6dff24b71b515@mail.gmail.com> <4AC4E94A.10901@redhat.com> <76953253-63B7-4689-9A87-7F35DD0BB4F3@gmail.com> In-Reply-To: <76953253-63B7-4689-9A87-7F35DD0BB4F3@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Virus-Checked: Checked by ClamAV on apache.org Why would everyone need to use both repos? If the legacy repository is done correctly, the vast majority of users would never need to hit it, or even know about it at all. Note that this idea is different than creating a new clean repository. This would be a new repository just for the garbage. Most artifacts would stay where they are. Just as an example, in the jboss repo I found someone had mixed up the main jar with the javadoc jar. So Maven was trying to use the javadocs on the classpath. Stuff like this is unusable, and should be removed from the repository IMO. Stephen Connolly 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 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 : >>>>> +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 >>>>> : >>>>>> 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 >>>>>>> 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 >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On Thu, Sep 24, 2009 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. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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: users-unsubscribe@maven.apache.org >>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org >>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org >>>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >>>>> For additional commands, e-mail: dev-help@maven.apache.org >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> 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: dev-unsubscribe@maven.apache.org >>>> For additional commands, e-mail: dev-help@maven.apache.org >>>> >>> Thanks, >>> Jason >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> ---------------------------------------------------------- >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >>> For additional commands, e-mail: dev-help@maven.apache.org >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >> For additional commands, e-mail: dev-help@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org > For additional commands, e-mail: dev-help@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org