No because metasoftware would be software about software (which makes no sense)
2009/10/8 Albert Kurucz <[email protected]> > Should we call a software, which links to other software (has > dependencies), metasoftware? > > 2009/10/7 Tamás Cservenák <[email protected]>: > > 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 < > > [email protected]> 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 <[email protected]> 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 > >>> <[email protected]> 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 <[email protected]> > 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 <[email protected]> > wrote: > >>>>> > >>>>>> > >>>>>> On Tue, Oct 6, 2009 at 9:30 AM, Albert Kurucz < > [email protected] > >>>>>> > > >>>>>> 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: [email protected] > >>>>>> For additional commands, e-mail: [email protected] > >>>>>> > >>>>>> > >>>>>> > >>>>> --------------------------------------------------------------------- > >>>>> 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] > >>>> > >>>> > >>>> > >>> --------------------------------------------------------------------- > >>> 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] > >> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
