Mr. Zyl, Please don't mistake me. I'm on your side of this debate. I am no more arguing against basic cleanup than I am arguing for trying to get into the business of arbitrating and publishing elaborate metadata about what is inside or behind the artifacts.
Central should be as clean as possible in a functional sense: the artifacts in it should contain what they claim to contain, have accurate dependencies, etc. A scheme to hang red flags on historical items that have problems is great. --benson On Sun, Sep 27, 2009 at 2:17 PM, Jason van Zyl <[email protected]> wrote: > This is exactly what all sane users do, but we will still try extremely > hard to clean everything up and make it easier for open source projects to > get their artifacts to central. > > > On 2009-09-27, at 10:41 AM, Benson Margulies wrote: > > 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] >>> >>> >>> > 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] > >
