2009/9/25 Albert Kurucz <albert.kur...@gmail.com>: > The pure Maven repo should say: > We honestly don't care which Maven plugin the people build with, as > long as that plugin is already checked into here. > > And why people would prefer to use libraries from the pure Maven repo? > Quality. > > Being build-able has always been the target of OSS developments. > Finally this could be achieved. > (OK it won't come to Maven Central) > > Anyone care about having Maven Pure? >
Not me. Central is good enough if we add deprecation metadata, version comparison metadata, and if we fix a few small issues with the pom xsd. > On Fri, Sep 25, 2009 at 8:36 AM, Albert Kurucz <albert.kur...@gmail.com> > wrote: >> "We just need a high-quality POM, correct metadata, javadocs, sources, >> and signatures." >> It is debatable is what you mean on high quality. >> >> For me (totally a Maven fan!) what makes the POM high quality? >> Its ability to build the project! >> I don't really care if it is full of maven-antrun-plugin, but build it >> by running mvn ... >> >> For some developers high quality really just means that the metadata is >> correct. >> >> Because of this opposition having two separate OSS repos (serving >> different needs?) makes sense. >> >> What is the right thing to do going forward? >> One question is whether to care about build ability or not! >> >> >> On Thu, Sep 24, 2009 at 10:56 PM, Jason van Zyl <jvan...@sonatype.com> wrote: >>> >>> On 2009-09-24, at 7: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. >>> >>> What matters is a plan to improve the metadata and this can be done over >>> time. There can never be a big bang here, there is just too much content, >>> and too many people relying on the content that's there. Projects that are >>> deploying against oss.sonatype.org are subject to the procurement rules >>> which are stringent. The artifacts are placed in a staging repository, rules >>> are applied and if they all pass they get promoted otherwise they have to be >>> corrected. No promotion unless all the rules pass. >>> >>> Only allowing Maven built projects doesn't make sense. All we need it the >>> correct information. We honestly don't care if people build with Maven or >>> not. We just need a high-quality POM, correct metadata, javadocs, sources, >>> and signatures. >>> >>>> 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. >>> >>> This isn't really going to change or help anything. The existing content >>> cannot change, the content going forward needs to be improved and that's >>> what matters. Over time as the content improves the poorer quality >>> submissions will just fall into disuse. >>> >>> Nexus can now help any project that wants to deploy high quality artifacts >>> via oss.sonatype.org. The next step for us is allowing bundle submissions >>> that are normally pushed into JIRA to be also submitted into a staging >>> repository and run through the same set of rules. This will be available in >>> Nexus 1.4. The last gap to fill will be repositories that directly sync and >>> we'll provide a mechanism for that in Nexus as well. Ultimately we will >>> build up these rules and if you don't pass them, by whatever gate you pass >>> through, then your artifacts get rejected. We'll provide this in an easy to >>> use form with Nexus but ultimately it doesn't matter how these rules are >>> enforced as long as they are enforced. This is the only strategy that will >>> work long-term. >>> >>> What's done has been done. What matters now helping projects do the right >>> thing going forward. >>> >>>> >>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <bri...@infinity.nu> wrote: >>>>> >>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <albert.kur...@gmail.com> >>>>> 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-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: users-h...@maven.apache.org >>>> >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> ---------------------------------------------------------- >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
