maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Albert Kurucz <albert.kur...@gmail.com>
Subject Re: a cleaned up central repository?
Date Thu, 08 Oct 2009 13:30:39 GMT
Should we call a software, which links to other software (has
dependencies), metasoftware?

2009/10/7 Tamás Cservenák <tamas@cservenak.net>:
> 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
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message