For me, High quality is that:
/project/(?parent/)(groupId|artifactId|version) are valid and do not reference properties /project/dependencies is valid and if there are any properties defined they are defined within the pom or it's parents /project/name /project/description /project/url Bonus high quality is when it has /project/scm /project/issueTracking /project/developers /project/contributors and if it is a project that builds using Maven 2 -Stephen 2009/9/25 Albert Kurucz <albert.kur...@gmail.com>: > "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
