I agree that a point system is pointless. I mostly care about whether an artifact is well-formed. I don't depend on maven central to help me make business decisions about what open source components to depend on. If I need a component, I do the research to see what exists, what has a live community, what the licenses are, etc. Finally, when I know that I want something, I go see if its on central. If it's not, then I grumble and make arrangements to get to it from my local nexus instance. All I need to know from central is whether it contains a functional, up-to-date artifact set f whatever component I've determined that I want to use.
On Sun, Sep 27, 2009 at 5:13 AM, Anders Kristian Andersen < [email protected]> wrote: > I hope I get this right > Jason here states that there should only be one central > > And yes we can ONLY have ONE central. And this is the ONE we got today !!!! > That must be the game we are playing. > The community must be able to TRUST maven / central. > Starting changing this could cause doubt, and a very easy attach zone for > competitors... > > When this is stated.... > We must acknowledge we got problems !!! > The central is full of legacy, some artifacts that even might not work, > moved etc. > > Here the solution can be to add deprecation lists or better > component-qualtiy-attributes (an xml file next to a component) > > To speak clear: pom.xml xx.jar xxx.war ... is read-only. > > But a component-quality-attribute.xml file can be maintained, and updated. > > The quality attributes can be like: > deprecated false / true .. when true + a description > runs-JVM-1.5 true/ (false + description / problem reference ) > runs-JVM-1.6 true/ (false + description / problem reference ) > runs-JVM-1.7 true/ (false + description / problem reference ) > runs-JVM-1.8 when this becomes relevant > is-moved (no) or path to new location > > osgi-compliant true / false > ivy-enabled true /false > groovy-enabled > > maven-2 enabled true / false ... most of our maven-2 artifacts > should hopefully have true here :-) > maven-3 enabled (soon..) > maven-4 enabled (when this becomes relevant) > > various PMD level compliant > > > I here by tries to state that we cannot predict the future. > What today seens perfect, might tomorrow be less usable. > > > With such attributes users can select the artifacts matching their demands. > I am not sure a point system from 1..10 will match the requirements. > > Best regards > Anders Kristian Andersen > > > > > > On 26/09/2009, at 21.15, Jason van Zyl wrote: > > >> On 2009-09-26, at 10:58 AM, Albert Kurucz wrote: >> >> Very nice idea to measure the quality. >>> But sorry Tamas, 50% corrupt or 90% corrupt does not make a difference >>> for me. >>> Especially not, when I have feeling that it is possible to maintain a >>> 100% clean repo with the right automation tools. >>> If Sonatype's goal is to sell these tools only for paying customers I >>> don't have a bad feeling about that. Everyone has to make a living. >>> But I hope sometime similar tools and a clean repo will be available >>> for the open public. >>> I hope OSS developers will recognize the need for quality (and a high >>> quality repo). >>> >> >> Not having a super high quality central repository actually makes our >> commercial efforts a lot harder. If I was devious I would have agreed with >> Brett and would make a completely clean central repository as our plans >> require intact repositories. But we don't have a clean repository and trying >> to make a separate one would be a disaster for general use. You have to live >> with what's there and Sonatype will actually invest in cleaning up the >> generally available repository. We already have with efforts like this: >> >> http://nexus.sonatype.org/oss-repository-hosting.html >> >> It would actually cost us more in support with our clients to maintain a >> dirty Maven Central and a clean Maven Central with the confusion, >> interoperability problems and general issues of potential distrust it just >> makes no business sense. Now the information we want to add is of enormous >> value but it's predicated on generally improving the quality of Maven >> Central. I don't want Sonatype to be known as the company that stole Maven >> Central, doesn't do us any good. So trying to sequester improved metadata >> somewhere is pointless. If the base information is not good, then the whole >> system is crippled and that screws Sonatype as well as everyone else. >> >> So the information in Maven Central on a per-project basis I see >> increasing greatly with some tools that Sonatype is developing in Nexus and >> M2Eclipse and this will benefit all Maven users generally. I'm certainly >> going to leverage that improved information, but so can anyone else. >> >> >>> On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY <[email protected]> >>> wrote: >>> >>>> Le samedi 26 septembre 2009, Tamás Cservenák a écrit : >>>> >>>>> I think we all need some clarification, since we all talk about >>>>> "quality" >>>>> (we all agreed upon the basic things unanimously). >>>>> What is the "quality" of a maven repository (in general)? Can we >>>>> measure >>>>> it? Can we define it? >>>>> >>>>> A wiki page with piled up (even personal) opinions would be good -- >>>>> >>>> don't hesitate to start one on MAVENUSER Wiki [1] >>>> >>>> whatever they are -- and later we should cherry-pick the most relevant >>>>> ones >>>>> to build some tooling to build these metric. And then, we could >>>>> "measure" >>>>> the quality of different reposes (like central) and have a list of >>>>> reposes >>>>> that do meet certain "level of quality" and list publicly the others >>>>> that >>>>> does not. >>>>> >>>> >>>> [1] http://docs.codehaus.org/display/MAVENUSER/Home >>>> >>>> --------------------------------------------------------------------- >>>> 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] >>> >>> >> 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] > >
