"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
