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]
