maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamás Cservenák <ta...@cservenak.net>
Subject Re: a cleaned up central repository?
Date Wed, 07 Oct 2009 12:29:32 GMT
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.connolly@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.kurucz@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.connolly@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.kurucz@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 <brianf@infinity.nu> wrote:
>>>>
>>>>>
>>>>> On Tue, Oct 6, 2009 at 9:30 AM, Albert Kurucz <albert.kurucz@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message