Sorry, could not stand it: the deprecation data about "broken" artifacts described in metametadata : metametametadata :D
~t~ On Tue, Oct 6, 2009 at 10:22 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > metadata is data about data > metaanalysis is an analysis of other analyses > metaworry is worrying about worrying > metacognition is thinking about thinking > > metametadata is therefore data about metadata > > the jar is your artifact : data > the pom is data about the artifact : metadata > the metadata.xml is data about the pom files : metametadata > > Sent from my [rhymes with tryPod] ;-) > > On 6 Oct 2009, at 20:02, Albert Kurucz <albert.kur...@gmail.com> wrote: > > Steven, >> >> http://lmgtfy.com/?q=maven+metametadata >> Found this 1st: >> " >> So he's talking about me!? Does that make me a maven? Does mavenhood >> explain metametametadata? Does it excuse all of its self-referential >> posts? Are you sick of them yet? Is this clever? Can I ask anymore >> questions? Um, no. >> " >> From 2004! >> >> On Tue, Oct 6, 2009 at 1:06 PM, Stephen Connolly >> <stephen.alan.conno...@gmail.com> wrote: >> >>> Albert, >>> >>> I think you are confusing the metadata.XML files from the pom.XML files >>> >>> the metadata sonatype are referring to is the metametadata (ie >>> metadata.xml >>> files) and nit the artifact metadata (ie pom.xml files) >>> >>> there are places in central where the metametadata is incorrect. let's >>> get >>> those fixed >>> >>> pom's are more subjective: is log4j 1.2.14 a bad pom? it lists all the >>> dependencies with compile scope and without optional=true >>> >>> in my case, it is a bad pom because on a point release started pulling in >>> windows nt logging support, and my app breaks with that support in >>> place... >>> but it is still a valid pom and it is still a "correct" pom >>> >>> I could argue that the dependencies could be optional, others could argue >>> that instead the whole log4j should be refactored into multiple artifacts >>> pulling in each of the dependencies I think should be optional... none of >>> us >>> are correct >>> >>> I could argue that a pom which does not list a license is broken... >>> others >>> might say that code in the public domain has no license, so their pom >>> would >>> be incorrect to list a license >>> >>> I could have a closed source artifact on central, so no scm, no >>> developers, >>> no distMgnt, no build, no reporting... and that is still a valid pom >>> >>> the only metadata we can prove to be incorrect is the metametadata... and >>> thankfully that can be reconstructed from the pom files >>> >>> Sent from my [rhymes with tryPod] ;-) >>> >>> On 6 Oct 2009, at 18:30, Albert Kurucz <albert.kur...@gmail.com> wrote: >>> >>> Brian, >>>> >>>> This is why in suggestion 1) I said lets get some code to validate the >>>>> artifacts. >>>>> >>>> >>>> Reading this article I thought you already have that >>>> >>>> http://www.think88.com/resources/Maven_white_paper_june_2009.pdf >>>> " >>>> Sonatype maintains a central repository with more than 90,000 artifacts, >>>> consuming more than 60 GB of storage. In addition to the artifacts >>>> themselves, the >>>> Maven Central Repository also contains a POM-file for each of the >>>> artifacts, >>>> containing the meta data for these artifacts. To protect the integrity >>>> of >>>> the >>>> repository, Sonatype checks the meta data for correctness. If the meta >>>> data is >>>> erroneous, the artifact can’t be uploaded. >>>> " >>>> >>>> >>>> On Tue, Oct 6, 2009 at 12:19 PM, Brian Fox <bri...@infinity.nu> wrote: >>>> >>>>> >>>>> On Tue, Oct 6, 2009 at 9:30 AM, Albert Kurucz <albert.kur...@gmail.com >>>>> > >>>>> wrote: >>>>> >>>>>> >>>>>> Tamas, I cannot predict when, but once it will be done in a "machine >>>>>> way" or a mathematical/logical proof will be discovered that it is >>>>>> impossible. Agreed, it will not be easy. >>>>>> >>>>>> >>>>> This is why in suggestion 1) I said lets get some code to validate the >>>>> artifacts. Having a suite of validation rules implemented hurts noone >>>>> and then people can choose to use them or not, it's just like the >>>>> bunch of enforcer rules we already have. >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
