You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Albert Kurucz <al...@gmail.com> on 2009/09/24 16:40:26 UTC
Maven Central Repository - Cleanup Efforts
According to 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.
"
There are some artifacts on the Maven Central Repo, with corrupt meta data.
Is there an issue tracker where such corrupt artifacts could be reported?
What is the policy of Sonatype handling this issue?
1. Will corrupt artifacts be removed (causing a chain reaction,
because Central hosted dependents will loose their dependencies, which
are required to be also on Central)?
2. Or is it in Sonatype's plan to start a new Central Repo, which is
now better scanned?
3. Or ignorance?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
Garbage collection?
Identify corrupted ones and remove.
On Thu, Sep 24, 2009 at 4:41 PM, Brian Fox <br...@infinity.nu> wrote:
> On Thu, Sep 24, 2009 at 12:04 PM, Albert Kurucz <al...@gmail.com> wrote:
>> Brian,
>> Probably no one ever suggested that the corrupt artifacts should be
>> fixed, because fixing is not even possible (every artifact must be
>> signed by the creator).
>> The question is whether you prefer the corrupt ones to be removed or
>> just wait until they become obsolete and no one would care about that
>> they stay or not (quantity or quality has the priority?).
>
> To take this further you must define corrupt. If something is
> demonstrated truly and completely broken and/or dangerous, it will be
> removed immediately. If a pom is missing a dependency, that doesn't
> qualify, it's up to the project to fix and produce a new release in
> that case.
>
>> The work on preventing the ugly ones from getting in I agree has the
>> first priority.
>> But will you address (and when?) this second most important task, the
>> garbage collection?
>
> We are actively working on technology to address this, expect details
> in the near future. What do you mean by garbage collection?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Jason van Zyl <jv...@sonatype.com>.
On 2009-09-24, at 3:16 PM, Albert Kurucz wrote:
> Requirements for the POMs are defined as:
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> I call the artifact corrupt (regarding Maven Central Compliance) if
> the POM of the artifact does not fulfills the above requirements.
> There are corrupt ones have made it to the Central, because the guard
> was sleeping.
>
The growth of the central repository is a function of our initial
flexibility and, quite honestly, lack of tooling to enforce what we
now consider necessary. Hindsight is always 20/20. It's easy to look
now at all the problems in the repository with a critical eye, but the
fact of the matter is if we were extremely strict to begin with we
probably would have stunted its growth. Maven use has grown, the use
of the repository has grown and problems with metadata are now felt
globally. We are talking steps to clean this up and make it easier for
projects to do the right thing.
The fact still remains that Maven Central has always been a public
service and a point of convenience for Maven users. That was the
impetus for its creation. We have probably been a bit too lenient
insofar as letting organizations rsync directly but live and learn. We
do have the tools now in Nexus to prevent garbage from going into the
repository but its an organizational and project choice to use these
tools.
The plan going forward is to encourage projects to do the right thing.
We're not going to retroactively remove or change things from Maven
central.
I have never recommended anyone doing real development in an
organization connect directly to Maven central. It's a great way to
populate the repository you have internally but the management of the
binary dependencies is just as important as the management of your
source. People have traditionally done this in house using Apache and
having to fix things internally but these days there are tools like
Nexus, Archiva and Artifactory. There is no silver bullet to have a
healthy artifact repository that you can depend on in your
organization. It takes some work, just like anything else. Can we make
that easier for people? Sure, and we're making steps toward that goal
on a daily basis. We'll have some tools in Nexus that we're going to
make available to OSS projects with the 1.4 release which should start
relieving a lot of the pain and ensure the quality we need.
> Rules are enforced or here comes the anarchy...
>
> The severity of the damage?
> The Central should be an example of good practice. Otherwise...
>
>
>
> On Thu, Sep 24, 2009 at 4:41 PM, Brian Fox <br...@infinity.nu> wrote:
>> On Thu, Sep 24, 2009 at 12:04 PM, Albert Kurucz <albert.kurucz@gmail.com
>> > wrote:
>>> Brian,
>>> Probably no one ever suggested that the corrupt artifacts should be
>>> fixed, because fixing is not even possible (every artifact must be
>>> signed by the creator).
>>> The question is whether you prefer the corrupt ones to be removed or
>>> just wait until they become obsolete and no one would care about
>>> that
>>> they stay or not (quantity or quality has the priority?).
>>
>> To take this further you must define corrupt. If something is
>> demonstrated truly and completely broken and/or dangerous, it will be
>> removed immediately. If a pom is missing a dependency, that doesn't
>> qualify, it's up to the project to fix and produce a new release in
>> that case.
>>
>>> The work on preventing the ugly ones from getting in I agree has the
>>> first priority.
>>> But will you address (and when?) this second most important task,
>>> the
>>> garbage collection?
>>
>> We are actively working on technology to address this, expect details
>> in the near future. What do you mean by garbage collection?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Stephen Connolly <st...@gmail.com>.
2009/9/25 Hervé BOUTEMY <he...@free.fr>:
> Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
>> For me,
>>
>> High quality is that:
>>
>> /project/(?parent/)(groupId|artifactId|version) are valid and do not
>> reference properties
>>
>> /project/dependencies is valid and if there are any properties defined
>> they are defined within the pom or it's parents
>>
>> /project/name
>> /project/description
>> /project/url
> +1
>
>>
>> Bonus high quality is when it has
>>
>> /project/scm
>> /project/issueTracking
>> /project/developers
>> /project/contributors
> +1
>
>>
>> and if it is a project that builds using Maven 2
> -1 on this one
> you can build your artifact the way you like, this doesn't change anything on
> the quality of the artifact itself and of its metadata = what counts for an
> artifact repository
> building with Maven, Ant+Maven Ant Tasks, or Ant + Ivy, Buildr, or any other
> tool doesn't change anything
>
No the tool does not change anything... but it's a bonus if it's built
with maven ;-)
> Hervé
>
>>
>> -Stephen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Hervé BOUTEMY <he...@free.fr>.
Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
> For me,
>
> High quality is that:
>
> /project/(?parent/)(groupId|artifactId|version) are valid and do not
> reference properties
>
> /project/dependencies is valid and if there are any properties defined
> they are defined within the pom or it's parents
>
> /project/name
> /project/description
> /project/url
+1
>
> Bonus high quality is when it has
>
> /project/scm
> /project/issueTracking
> /project/developers
> /project/contributors
+1
>
> and if it is a project that builds using Maven 2
-1 on this one
you can build your artifact the way you like, this doesn't change anything on
the quality of the artifact itself and of its metadata = what counts for an
artifact repository
building with Maven, Ant+Maven Ant Tasks, or Ant + Ivy, Buildr, or any other
tool doesn't change anything
Hervé
>
> -Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Daniel Kulp <dk...@apache.org>.
On Fri September 25 2009 12:07:09 pm Stephen Connolly wrote:
> For me,
>
> High quality is that:
>
> /project/(?parent/)(groupId|artifactId|version) are valid and do not
> reference properties
>
> /project/dependencies is valid and if there are any properties defined
> they are defined within the pom or it's parents
>
> /project/name
> /project/description
> /project/url
And I would add:
/project/licenses
as that's very important to know if I can use the artifact or not.
> Bonus high quality is when it has
>
> /project/scm
> /project/issueTracking
> /project/developers
> /project/contributors
I would add
/project/organization
here as well.
Dan
>
> and if it is a project that builds using Maven 2
>
> -Stephen
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Stephen Connolly <st...@gmail.com>.
if you start measuring artifact quality, it makes sense to break down
the stats by groupId
at least that way if I see that java.net has 100% quality for
com.stvconsultants.easygloss I can configure my repository manager to
allow that group I'd through, but leave org.glassfish out as its
quality is only 70%
although I do see assessing quality as requiring at least some human
intervention.
but in response to Albert, a 50% score for quality does not translate
to everything being crap, only that lots of non-deprecated artifacts
have "poor" pom.xml files. there will still be zones of sanity in a
poor repo, just as there are zones of insanity in a mostly good
repository
Sent from my [rhymes with tryPod] ;-)
On 26 Sep 2009, at 18:58, Albert Kurucz <al...@gmail.com> wrote:
> Very nice idea to measure the quality.
> But sorry Tamas, 50% corrupt or 90% corrupt does not make a
> difference for me.
> Especially not, when I have feeling that it is possible to maintain a
> 100% clean repo with the right automation tools.
> If Sonatype's goal is to sell these tools only for paying customers I
> don't have a bad feeling about that. Everyone has to make a living.
> But I hope sometime similar tools and a clean repo will be available
> for the open public.
> I hope OSS developers will recognize the need for quality (and a high
> quality repo).
>
> On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY <herve.boutemy@free.
> fr> wrote:
>> Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
>>> I think we all need some clarification, since we all talk about
>>> "quality"
>>> (we all agreed upon the basic things unanimously).
>>> What is the "quality" of a maven repository (in general)? Can we
>>> measure
>>> it? Can we define it?
>>>
>>> A wiki page with piled up (even personal) opinions would be good --
>> don't hesitate to start one on MAVENUSER Wiki [1]
>>
>>> whatever they are -- and later we should cherry-pick the most
>>> relevant ones
>>> to build some tooling to build these metric. And then, we could
>>> "measure"
>>> the quality of different reposes (like central) and have a list of
>>> reposes
>>> that do meet certain "level of quality" and list publicly the
>>> others that
>>> does not.
>>
>> [1] http://docs.codehaus.org/display/MAVENUSER/Home
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Brian Fox <br...@infinity.nu>.
Please see my response on the maven-dev list for how this problem is
best approached. For everyone's sanity, lets keep the discussion
thread on the dev list.
On Thu, Oct 1, 2009 at 2:41 PM, Albert Kurucz <al...@gmail.com> wrote:
>> Then make your own repository. See how useful that is.
>
> Jason, you are probably right.
> http://xircles.codehaus.org/projects/pinin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
> Then make your own repository. See how useful that is.
Jason, you are probably right.
http://xircles.codehaus.org/projects/pinin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Jason van Zyl <jv...@sonatype.com>.
On 2009-09-26, at 12:11 PM, Albert Kurucz wrote:
> I don't want anyone to miss any of the numerous "ok" arifacts.
> Those could still be housed by the "Good enough" Central repo.
> I would like to have a setting in my Maven with 3 options:
> -Good enough
> -Good (verified meta)
> -Best (verified buildable)
> which selects which of the 3 maintained repo will be used.
>
Then make your own repository. See how useful that is.
>
> On Sat, Sep 26, 2009 at 1:41 PM, Stephen Connolly
> <st...@gmail.com> wrote:
>>
>>
>> Sent from my [rhymes with tryPod] ;-)
>>
>> On 26 Sep 2009, at 18:58, Albert Kurucz <al...@gmail.com>
>> wrote:
>>
>>> Very nice idea to measure the quality.
>>> But sorry Tamas, 50% corrupt or 90% corrupt does not make a
>>> difference for
>>> me.
>>> Especially not, when I have feeling that it is possible to
>>> maintain a
>>> 100% clean repo with the right automation tools.
>>
>> yes this is possible, but it will be missing so many of the "ok"
>> artifacts
>> that everyone needs as to make it useful. if you set the bar too
>> high,
>> nobody will try to jump it.
>>
>> let's start by setting the bar a little higher than it currently
>> is, and
>> with deprecation metadata we can start flagging those artifacts
>> which would
>> not make it over the bar at its new height
>>
>> central it just too useful... it has gathered critical mass whereby
>> it is
>> nearly a right of passage for new java projects to get hosted on
>> central...
>> hosting on central becomes one of those things projects are asked
>> to do...
>> if we move the goalposts too far or too fast we will kill the
>> critical mass
>> we have now, and the whole thing will end up a dead duck
>>
>>> If Sonatype's goal is to sell these tools only for paying
>>> customers I
>>> don't have a bad feeling about that.
>>
>> I don't get that impression
>>
>> I get the impression that paying customers will get the features
>> first, but,
>> the impression I have is that Jason feels good artifacts in central
>> help
>> sonatype make money more than providing commercial tools to try and
>> filter
>> out the bad from central ever could
>>
>>
>>> Everyone has to make a living.
>>> But I hope sometime similar tools and a clean repo will be available
>>> for the open public.
>>> I hope OSS developers will recognize the need for quality (and a
>>> high
>>> quality repo).
>>>
>>> On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY <herve.boutemy@free.fr
>>> >
>>> wrote:
>>>>
>>>> Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
>>>>>
>>>>> I think we all need some clarification, since we all talk about
>>>>> "quality"
>>>>> (we all agreed upon the basic things unanimously).
>>>>> What is the "quality" of a maven repository (in general)? Can we
>>>>> measure
>>>>> it? Can we define it?
>>>>>
>>>>> A wiki page with piled up (even personal) opinions would be good
>>>>> --
>>>>
>>>> don't hesitate to start one on MAVENUSER Wiki [1]
>>>>
>>>>> whatever they are -- and later we should cherry-pick the most
>>>>> relevant
>>>>> ones
>>>>> to build some tooling to build these metric. And then, we could
>>>>> "measure"
>>>>> the quality of different reposes (like central) and have a list of
>>>>> reposes
>>>>> that do meet certain "level of quality" and list publicly the
>>>>> others
>>>>> that
>>>>> does not.
>>>>
>>>> [1] http://docs.codehaus.org/display/MAVENUSER/Home
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Brian Fox <br...@infinity.nu>.
On Sat, Sep 26, 2009 at 12:11 PM, Albert Kurucz <al...@gmail.com> wrote:
> I don't want anyone to miss any of the numerous "ok" arifacts.
> Those could still be housed by the "Good enough" Central repo.
> I would like to have a setting in my Maven with 3 options:
> -Good enough
> -Good (verified meta)
> -Best (verified buildable)
> which selects which of the 3 maintained repo will be used.
>
It's not that simple. What you really want to say is if the best is
there, take it. If there is no best then use good etc, but frankly
it's not going to exist that you have best, good and good enough
existing all at the same time for the same version. Selecting a whole
repo based on some arbitrary criteria makes no sense unless every
single artifact you need exists at that level.
If you really want to filter things out based on definable criteria,
then perhaps you want the Procurement support in Nexus Pro. I just
don't see how selecting a whole repo makes any sense.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
I don't want anyone to miss any of the numerous "ok" arifacts.
Those could still be housed by the "Good enough" Central repo.
I would like to have a setting in my Maven with 3 options:
-Good enough
-Good (verified meta)
-Best (verified buildable)
which selects which of the 3 maintained repo will be used.
On Sat, Sep 26, 2009 at 1:41 PM, Stephen Connolly
<st...@gmail.com> wrote:
>
>
> Sent from my [rhymes with tryPod] ;-)
>
> On 26 Sep 2009, at 18:58, Albert Kurucz <al...@gmail.com> wrote:
>
>> Very nice idea to measure the quality.
>> But sorry Tamas, 50% corrupt or 90% corrupt does not make a difference for
>> me.
>> Especially not, when I have feeling that it is possible to maintain a
>> 100% clean repo with the right automation tools.
>
> yes this is possible, but it will be missing so many of the "ok" artifacts
> that everyone needs as to make it useful. if you set the bar too high,
> nobody will try to jump it.
>
> let's start by setting the bar a little higher than it currently is, and
> with deprecation metadata we can start flagging those artifacts which would
> not make it over the bar at its new height
>
> central it just too useful... it has gathered critical mass whereby it is
> nearly a right of passage for new java projects to get hosted on central...
> hosting on central becomes one of those things projects are asked to do...
> if we move the goalposts too far or too fast we will kill the critical mass
> we have now, and the whole thing will end up a dead duck
>
>> If Sonatype's goal is to sell these tools only for paying customers I
>> don't have a bad feeling about that.
>
> I don't get that impression
>
> I get the impression that paying customers will get the features first, but,
> the impression I have is that Jason feels good artifacts in central help
> sonatype make money more than providing commercial tools to try and filter
> out the bad from central ever could
>
>
>> Everyone has to make a living.
>> But I hope sometime similar tools and a clean repo will be available
>> for the open public.
>> I hope OSS developers will recognize the need for quality (and a high
>> quality repo).
>>
>> On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY <he...@free.fr>
>> wrote:
>>>
>>> Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
>>>>
>>>> I think we all need some clarification, since we all talk about
>>>> "quality"
>>>> (we all agreed upon the basic things unanimously).
>>>> What is the "quality" of a maven repository (in general)? Can we measure
>>>> it? Can we define it?
>>>>
>>>> A wiki page with piled up (even personal) opinions would be good --
>>>
>>> don't hesitate to start one on MAVENUSER Wiki [1]
>>>
>>>> whatever they are -- and later we should cherry-pick the most relevant
>>>> ones
>>>> to build some tooling to build these metric. And then, we could
>>>> "measure"
>>>> the quality of different reposes (like central) and have a list of
>>>> reposes
>>>> that do meet certain "level of quality" and list publicly the others
>>>> that
>>>> does not.
>>>
>>> [1] http://docs.codehaus.org/display/MAVENUSER/Home
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Brian Fox <br...@infinity.nu>.
> central it just too useful... it has gathered critical mass whereby it is
> nearly a right of passage for new java projects to get hosted on central...
> hosting on central becomes one of those things projects are asked to do...
> if we move the goalposts too far or too fast we will kill the critical mass
> we have now, and the whole thing will end up a dead duck
bingo. We are doing this now by requiring valid signatures for
anything that comes via oss.sonatype.org or anything i personally
approve when i manually process either an upload or a sync request. If
it's no good, it don't enable it. We want to automate this so the
standard applies regardless of who processes the request...and
eventually automate the processing as well.
>
>> If Sonatype's goal is to sell these tools only for paying customers I
>> don't have a bad feeling about that.
>
> I don't get that impression
Also correct. We want to fix the core data in central for everyone,
but as I've said before: "fix" means improve the quality of incoming
data, it does not mean go back and rewrite old poms etc because this
just screws up existing builds.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Stephen Connolly <st...@gmail.com>.
Sent from my [rhymes with tryPod] ;-)
On 26 Sep 2009, at 18:58, Albert Kurucz <al...@gmail.com> wrote:
> Very nice idea to measure the quality.
> But sorry Tamas, 50% corrupt or 90% corrupt does not make a
> difference for me.
> Especially not, when I have feeling that it is possible to maintain a
> 100% clean repo with the right automation tools.
yes this is possible, but it will be missing so many of the "ok"
artifacts that everyone needs as to make it useful. if you set the
bar too high, nobody will try to jump it.
let's start by setting the bar a little higher than it currently is,
and with deprecation metadata we can start flagging those artifacts
which would not make it over the bar at its new height
central it just too useful... it has gathered critical mass whereby it
is nearly a right of passage for new java projects to get hosted on
central... hosting on central becomes one of those things projects are
asked to do... if we move the goalposts too far or too fast we will
kill the critical mass we have now, and the whole thing will end up a
dead duck
> If Sonatype's goal is to sell these tools only for paying customers I
> don't have a bad feeling about that.
I don't get that impression
I get the impression that paying customers will get the features
first, but, the impression I have is that Jason feels good artifacts
in central help sonatype make money more than providing commercial
tools to try and filter out the bad from central ever could
> Everyone has to make a living.
> But I hope sometime similar tools and a clean repo will be available
> for the open public.
> I hope OSS developers will recognize the need for quality (and a high
> quality repo).
>
> On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY <herve.boutemy@free.
> fr> wrote:
>> Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
>>> I think we all need some clarification, since we all talk about
>>> "quality"
>>> (we all agreed upon the basic things unanimously).
>>> What is the "quality" of a maven repository (in general)? Can we
>>> measure
>>> it? Can we define it?
>>>
>>> A wiki page with piled up (even personal) opinions would be good --
>> don't hesitate to start one on MAVENUSER Wiki [1]
>>
>>> whatever they are -- and later we should cherry-pick the most
>>> relevant ones
>>> to build some tooling to build these metric. And then, we could
>>> "measure"
>>> the quality of different reposes (like central) and have a list of
>>> reposes
>>> that do meet certain "level of quality" and list publicly the
>>> others that
>>> does not.
>>
>> [1] http://docs.codehaus.org/display/MAVENUSER/Home
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Tamás Cservenák <ta...@cservenak.net>.
You got the point. But that "quality information" (whatever it's form would
be), could do things like:
- describe the overall quality of repo (let's name it the MRQ score)
- the list (or only the count) of "rules"/"tests" ran (so, a repo of MRQ
score 5 with 5 tests would be "less good" than a repo with MRQ score 5 but
checked with 15 tests), to be able to compare reposes between each other (if
for example the MRQ would be defined as "mean value of tests ran against it
or something like that). Or something much more sophisticated... but you got
the idea.
- the list of "problematic" or simply "unusable" or "less then qualifiable"
parts/GAVs/trees of repo itself. Tresholds could be wired in the tooling and
make them universal (minimal compliance set, good to have compliance set,
superb compliance set)
- etc
Sci Fiction part: You could have a simple maven plugin, that would try to
read these informations from reposes participating in your build (i know
this would have some issues in 2.2.x, but i believe maven3 would be able to
cope with this) on initialize phase of your build, and spit you huge
warnings about "problematic reposes are in your build", or better, if you
pull an artifact from "problematic" set/tree have an option to fail the
build/throw huge warning, etc
But one problem here is the "grouping feature" of almost all MRMs: and maven
simply looses the information from where came an artifact...
~t~
On Sat, Sep 26, 2009 at 7:58 PM, Albert Kurucz <al...@gmail.com>wrote:
> Very nice idea to measure the quality.
> But sorry Tamas, 50% corrupt or 90% corrupt does not make a difference for
> me.
> Especially not, when I have feeling that it is possible to maintain a
> 100% clean repo with the right automation tools.
> If Sonatype's goal is to sell these tools only for paying customers I
> don't have a bad feeling about that. Everyone has to make a living.
> But I hope sometime similar tools and a clean repo will be available
> for the open public.
> I hope OSS developers will recognize the need for quality (and a high
> quality repo).
>
> On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY <he...@free.fr>
> wrote:
> > Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
> >> I think we all need some clarification, since we all talk about
> "quality"
> >> (we all agreed upon the basic things unanimously).
> >> What is the "quality" of a maven repository (in general)? Can we measure
> >> it? Can we define it?
> >>
> >> A wiki page with piled up (even personal) opinions would be good --
> > don't hesitate to start one on MAVENUSER Wiki [1]
> >
> >> whatever they are -- and later we should cherry-pick the most relevant
> ones
> >> to build some tooling to build these metric. And then, we could
> "measure"
> >> the quality of different reposes (like central) and have a list of
> reposes
> >> that do meet certain "level of quality" and list publicly the others
> that
> >> does not.
> >
> > [1] http://docs.codehaus.org/display/MAVENUSER/Home
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
One "unwritten?" rule of Maven good practice is that you change the
undefined dependency version definitions to fixed versions before
release. If you have done that, resolution will not be effected by
certlist on or off status.
The value (benefit) what certlist would provide to a Maven user, is
that the user will not need to evaluate many artifact, which are not
worth to spend time on looking at. This could result to saving our
valuable spare time which we spend on contributing to different open
source projects.
On Mon, Sep 28, 2009 at 11:32 AM, Brian Fox <br...@infinity.nu> wrote:
> On Mon, Sep 28, 2009 at 9:02 AM, Albert Kurucz <al...@gmail.com> wrote:
>> Any other flaws?
>>
>>> A build then becomes dependent on the certlist in order for it to function.
>> The project's build will not become dependent of the certlist.
>> If it was able to build with certlist feature turned on, it will
>> certainly build without the certlist.
>
> If the build at all depends on the cert list for proper resolution,
> then yes it is a defacto dependency of the build. In other words, if
> the resolution is at all different without the certlist than it is
> with it, then the build is dependent on it for proper resolution. If
> the certlist isn't required, then what value does it provide?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Brian Fox <br...@infinity.nu>.
On Mon, Sep 28, 2009 at 9:02 AM, Albert Kurucz <al...@gmail.com> wrote:
> Any other flaws?
>
>> A build then becomes dependent on the certlist in order for it to function.
> The project's build will not become dependent of the certlist.
> If it was able to build with certlist feature turned on, it will
> certainly build without the certlist.
If the build at all depends on the cert list for proper resolution,
then yes it is a defacto dependency of the build. In other words, if
the resolution is at all different without the certlist than it is
with it, then the build is dependent on it for proper resolution. If
the certlist isn't required, then what value does it provide?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
Any other flaws?
> A build then becomes dependent on the certlist in order for it to function.
The project's build will not become dependent of the certlist.
If it was able to build with certlist feature turned on, it will
certainly build without the certlist.
> We do not allow <repository> definitions in pom files for a good reason.
Repository definitions and certlist select would go to settings file,
not to the pom.
> By all means I see repository managers being able to use certlists...
Managers of different repositories will not need to become managers of
certlists.
> but
> these would be applied at the repository manager level and not at the
> "settings.xml" or at the "pom.xml" level.
No, these two tasks (maintaining a repo vs maintaining a certlist)
should be separated.
> If you need a specific certlist in order to build correctly,
You may need a specific certlist in order to maintain certain
qualities of your development process.
But you don't need a certlist for performing any builds.
> I do not
> think we should allow your new artifacts into central..
No new artifacts needed on central.
All what is needed, a Maven client which respects my filter settings.
> and now certlists
> are a dead duck
Give me a good reason why!
On Mon, Sep 28, 2009 at 10:34 AM, Stephen Connolly
<st...@gmail.com> wrote:
> Yes it would hurt.
>
>
> In such a way, a cert list becomes directly equivalent to a <repository>
> definition in a pom.xml file.
>
> We do not allow <repository> definitions in pom files for a good reason.
>
> certlists is just another name for the same thing.
>
> By all means I see repository managers being able to use certlists... but
> these would be applied at the repository manager level and not at the
> "settings.xml" or at the "pom.xml" level.
>
> If you need a specific certlist in order to build correctly, then I do not
> think we should allow your new artifacts into central... and now certlists
> are a dead duck
>
> Just my opinion,
>
> Stephen
>
> 2009/9/28 Albert Kurucz <al...@gmail.com>
>
>> Filtering is already used for another Maven feature.
>> To avoid ambiguity, we should better call the one what I defined:
>> repository-skinning or repository-certification.
>> Do you think this new feature would hurt the repo or any Maven user?
>>
>> On Sun, Sep 27, 2009 at 11:27 PM, Albert Kurucz <al...@gmail.com>
>> wrote:
>> > It is not necessary to create a new repo and it is not necessary to
>> > modify anything on Central or the policies how it is managed. Mess
>> > could be cleaned up virtually if I could attach a filter.
>> >
>> > In the ~/.m2/settings.xml for example, I should be able to add a list
>> > of repository addresses and for each of this repositories (which list
>> > could include the Central repo) I should be able to setup a URL of the
>> > filter which I would wanna use.
>> >
>> > Filter format could be for example the nexus repository index format.
>> > One example is here:
>> > http://repository.codehaus.org/.index/
>> >
>> > My Maven client software should effectively hide artifacts from
>> > repositories (not only from Central) which artifacts have no reference
>> > on my selected filter index.
>> >
>> > Maven users have different needs, so they would sign up to different
>> > filters. Users would never loose faith of Central repo for its
>> > content. Only the index providers could be blamed for the garbage or
>> > for the missing artifacts, but this is highly unlikely, because they
>> > will maintain their index files by automated processes.
>> >
>> > It would be courteous from the current Maven Central maintainers if
>> > they provide a filter, which reflects the requirements what was
>> > originally made to get into Central:
>> > http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>> > (but lots of things got in, which do not comply to this).
>> >
>> >
>> >
>> >
>> > On Sun, Sep 27, 2009 at 6:45 PM, Brett Porter <br...@apache.org> wrote:
>> >>
>> >> On 27/09/2009, at 5:15 AM, Jason van Zyl wrote:
>> >>
>> >>> Not having a super high quality central repository actually makes our
>> >>> commercial efforts a lot harder. If I was devious I would have agreed
>> with
>> >>> Brett and would make a completely clean central repository as our plans
>> >>> require intact repositories. But we don't have a clean repository and
>> trying
>> >>> to make a separate one would be a disaster for general use. You have to
>> live
>> >>> with what's there and Sonatype will actually invest in cleaning up the
>> >>> generally available repository. We already have with efforts like this:
>> >>>
>> >>> http://nexus.sonatype.org/oss-repository-hosting.html
>> >>
>> >> Given this comment, I think you might have misunderstood my post on dev@
>> ...
>> >> I was of the opinion that clean going forward makes sense, past stuff is
>> >> still available, but working on ways to make Maven understand metadata
>> >> changes so that you can actually fix things that go wrong. Some related
>> >> themes have come up in this thread over the weekend, but I'll try and
>> follow
>> >> up on dev@ later with something more concrete.
>> >>
>> >> - Brett
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re : Maven Central Repository - Cleanup Efforts
Posted by Julien HENRY <he...@yahoo.fr>.
----- Message d'origine ----
> De : Albert Kurucz <al...@gmail.com>
> À : Maven Users List <us...@maven.apache.org>
> Envoyé le : Lundi, 28 Septembre 2009, 19h39mn 00s
> Objet : Re: Maven Central Repository - Cleanup Efforts
>
> Tamas, could explain "MRMs + grouping + mirrorOf" or send a link?
http://www.sonatype.com/books/nexus-book/reference/maven-sect-single-group.html
>
> 2009/9/28 Tamás Cservenák :
> > Sorry for thread hijack, but was not able to resist...
> >
> > Another thing to think about, since it's adoption:
> >
> > On Mon, Sep 28, 2009 at 5:34 PM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> >> We do not allow definitions in pom files for a good reason.
> >>
> >>
> > This seemed as a good idea, but.... think about it.
> >
> > Why would you _not_ put reposes in POMs? Because they will be _burned_ in to
> > your POMs forever and your URLs may change down the road?
> >
> > Why is this better:
> >
> > * having repository defs in POMs, thus providing at least some usable info
> > that a developer may use as starting point and google it up/search/look for
> > it (where it went, what it was, etc)
> >
> > then:
> >
> > * providing _no_ useful information in POMs for future generations? Having
> > no trace in your _build_ about needed reposes...
> >
> > Ah yes, _both_ cases are easily handled by MRMs + grouping + mirrorOf, but
> > in 2nd case, the one building may only shoot in the dark, you did not
> > provide _any_ information from what did you build your stuff.
> >
> > Think about it.
> > ~t~
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
Tamas, could explain "MRMs + grouping + mirrorOf" or send a link?
2009/9/28 Tamás Cservenák <ta...@cservenak.net>:
> Sorry for thread hijack, but was not able to resist...
>
> Another thing to think about, since it's adoption:
>
> On Mon, Sep 28, 2009 at 5:34 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> We do not allow <repository> definitions in pom files for a good reason.
>>
>>
> This seemed as a good idea, but.... think about it.
>
> Why would you _not_ put reposes in POMs? Because they will be _burned_ in to
> your POMs forever and your URLs may change down the road?
>
> Why is this better:
>
> * having repository defs in POMs, thus providing at least some usable info
> that a developer may use as starting point and google it up/search/look for
> it (where it went, what it was, etc)
>
> then:
>
> * providing _no_ useful information in POMs for future generations? Having
> no trace in your _build_ about needed reposes...
>
> Ah yes, _both_ cases are easily handled by MRMs + grouping + mirrorOf, but
> in 2nd case, the one building may only shoot in the dark, you did not
> provide _any_ information from what did you build your stuff.
>
> Think about it.
> ~t~
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Tamás Cservenák <ta...@cservenak.net>.
Sorry for thread hijack, but was not able to resist...
Another thing to think about, since it's adoption:
On Mon, Sep 28, 2009 at 5:34 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> We do not allow <repository> definitions in pom files for a good reason.
>
>
This seemed as a good idea, but.... think about it.
Why would you _not_ put reposes in POMs? Because they will be _burned_ in to
your POMs forever and your URLs may change down the road?
Why is this better:
* having repository defs in POMs, thus providing at least some usable info
that a developer may use as starting point and google it up/search/look for
it (where it went, what it was, etc)
then:
* providing _no_ useful information in POMs for future generations? Having
no trace in your _build_ about needed reposes...
Ah yes, _both_ cases are easily handled by MRMs + grouping + mirrorOf, but
in 2nd case, the one building may only shoot in the dark, you did not
provide _any_ information from what did you build your stuff.
Think about it.
~t~
Re: Maven Central Repository - Cleanup Efforts
Posted by Stephen Connolly <st...@gmail.com>.
Yes it would hurt.
A build then becomes dependent on the certlist in order for it to function.
In such a way, a cert list becomes directly equivalent to a <repository>
definition in a pom.xml file.
We do not allow <repository> definitions in pom files for a good reason.
certlists is just another name for the same thing.
By all means I see repository managers being able to use certlists... but
these would be applied at the repository manager level and not at the
"settings.xml" or at the "pom.xml" level.
If you need a specific certlist in order to build correctly, then I do not
think we should allow your new artifacts into central... and now certlists
are a dead duck
Just my opinion,
Stephen
2009/9/28 Albert Kurucz <al...@gmail.com>
> Filtering is already used for another Maven feature.
> To avoid ambiguity, we should better call the one what I defined:
> repository-skinning or repository-certification.
> Do you think this new feature would hurt the repo or any Maven user?
>
> On Sun, Sep 27, 2009 at 11:27 PM, Albert Kurucz <al...@gmail.com>
> wrote:
> > It is not necessary to create a new repo and it is not necessary to
> > modify anything on Central or the policies how it is managed. Mess
> > could be cleaned up virtually if I could attach a filter.
> >
> > In the ~/.m2/settings.xml for example, I should be able to add a list
> > of repository addresses and for each of this repositories (which list
> > could include the Central repo) I should be able to setup a URL of the
> > filter which I would wanna use.
> >
> > Filter format could be for example the nexus repository index format.
> > One example is here:
> > http://repository.codehaus.org/.index/
> >
> > My Maven client software should effectively hide artifacts from
> > repositories (not only from Central) which artifacts have no reference
> > on my selected filter index.
> >
> > Maven users have different needs, so they would sign up to different
> > filters. Users would never loose faith of Central repo for its
> > content. Only the index providers could be blamed for the garbage or
> > for the missing artifacts, but this is highly unlikely, because they
> > will maintain their index files by automated processes.
> >
> > It would be courteous from the current Maven Central maintainers if
> > they provide a filter, which reflects the requirements what was
> > originally made to get into Central:
> > http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> > (but lots of things got in, which do not comply to this).
> >
> >
> >
> >
> > On Sun, Sep 27, 2009 at 6:45 PM, Brett Porter <br...@apache.org> wrote:
> >>
> >> On 27/09/2009, at 5:15 AM, Jason van Zyl wrote:
> >>
> >>> Not having a super high quality central repository actually makes our
> >>> commercial efforts a lot harder. If I was devious I would have agreed
> with
> >>> Brett and would make a completely clean central repository as our plans
> >>> require intact repositories. But we don't have a clean repository and
> trying
> >>> to make a separate one would be a disaster for general use. You have to
> live
> >>> with what's there and Sonatype will actually invest in cleaning up the
> >>> generally available repository. We already have with efforts like this:
> >>>
> >>> http://nexus.sonatype.org/oss-repository-hosting.html
> >>
> >> Given this comment, I think you might have misunderstood my post on dev@
> ...
> >> I was of the opinion that clean going forward makes sense, past stuff is
> >> still available, but working on ways to make Maven understand metadata
> >> changes so that you can actually fix things that go wrong. Some related
> >> themes have come up in this thread over the weekend, but I'll try and
> follow
> >> up on dev@ later with something more concrete.
> >>
> >> - Brett
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
Filtering is already used for another Maven feature.
To avoid ambiguity, we should better call the one what I defined:
repository-skinning or repository-certification.
Do you think this new feature would hurt the repo or any Maven user?
On Sun, Sep 27, 2009 at 11:27 PM, Albert Kurucz <al...@gmail.com> wrote:
> It is not necessary to create a new repo and it is not necessary to
> modify anything on Central or the policies how it is managed. Mess
> could be cleaned up virtually if I could attach a filter.
>
> In the ~/.m2/settings.xml for example, I should be able to add a list
> of repository addresses and for each of this repositories (which list
> could include the Central repo) I should be able to setup a URL of the
> filter which I would wanna use.
>
> Filter format could be for example the nexus repository index format.
> One example is here:
> http://repository.codehaus.org/.index/
>
> My Maven client software should effectively hide artifacts from
> repositories (not only from Central) which artifacts have no reference
> on my selected filter index.
>
> Maven users have different needs, so they would sign up to different
> filters. Users would never loose faith of Central repo for its
> content. Only the index providers could be blamed for the garbage or
> for the missing artifacts, but this is highly unlikely, because they
> will maintain their index files by automated processes.
>
> It would be courteous from the current Maven Central maintainers if
> they provide a filter, which reflects the requirements what was
> originally made to get into Central:
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> (but lots of things got in, which do not comply to this).
>
>
>
>
> On Sun, Sep 27, 2009 at 6:45 PM, Brett Porter <br...@apache.org> wrote:
>>
>> On 27/09/2009, at 5:15 AM, Jason van Zyl wrote:
>>
>>> Not having a super high quality central repository actually makes our
>>> commercial efforts a lot harder. If I was devious I would have agreed with
>>> Brett and would make a completely clean central repository as our plans
>>> require intact repositories. But we don't have a clean repository and trying
>>> to make a separate one would be a disaster for general use. You have to live
>>> with what's there and Sonatype will actually invest in cleaning up the
>>> generally available repository. We already have with efforts like this:
>>>
>>> http://nexus.sonatype.org/oss-repository-hosting.html
>>
>> Given this comment, I think you might have misunderstood my post on dev@...
>> I was of the opinion that clean going forward makes sense, past stuff is
>> still available, but working on ways to make Maven understand metadata
>> changes so that you can actually fix things that go wrong. Some related
>> themes have come up in this thread over the weekend, but I'll try and follow
>> up on dev@ later with something more concrete.
>>
>> - Brett
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
It is not necessary to create a new repo and it is not necessary to
modify anything on Central or the policies how it is managed. Mess
could be cleaned up virtually if I could attach a filter.
In the ~/.m2/settings.xml for example, I should be able to add a list
of repository addresses and for each of this repositories (which list
could include the Central repo) I should be able to setup a URL of the
filter which I would wanna use.
Filter format could be for example the nexus repository index format.
One example is here:
http://repository.codehaus.org/.index/
My Maven client software should effectively hide artifacts from
repositories (not only from Central) which artifacts have no reference
on my selected filter index.
Maven users have different needs, so they would sign up to different
filters. Users would never loose faith of Central repo for its
content. Only the index providers could be blamed for the garbage or
for the missing artifacts, but this is highly unlikely, because they
will maintain their index files by automated processes.
It would be courteous from the current Maven Central maintainers if
they provide a filter, which reflects the requirements what was
originally made to get into Central:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
(but lots of things got in, which do not comply to this).
On Sun, Sep 27, 2009 at 6:45 PM, Brett Porter <br...@apache.org> wrote:
>
> On 27/09/2009, at 5:15 AM, Jason van Zyl wrote:
>
>> Not having a super high quality central repository actually makes our
>> commercial efforts a lot harder. If I was devious I would have agreed with
>> Brett and would make a completely clean central repository as our plans
>> require intact repositories. But we don't have a clean repository and trying
>> to make a separate one would be a disaster for general use. You have to live
>> with what's there and Sonatype will actually invest in cleaning up the
>> generally available repository. We already have with efforts like this:
>>
>> http://nexus.sonatype.org/oss-repository-hosting.html
>
> Given this comment, I think you might have misunderstood my post on dev@...
> I was of the opinion that clean going forward makes sense, past stuff is
> still available, but working on ways to make Maven understand metadata
> changes so that you can actually fix things that go wrong. Some related
> themes have come up in this thread over the weekend, but I'll try and follow
> up on dev@ later with something more concrete.
>
> - Brett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Brett Porter <br...@apache.org>.
On 27/09/2009, at 5:15 AM, Jason van Zyl wrote:
> Not having a super high quality central repository actually makes
> our commercial efforts a lot harder. If I was devious I would have
> agreed with Brett and would make a completely clean central
> repository as our plans require intact repositories. But we don't
> have a clean repository and trying to make a separate one would be a
> disaster for general use. You have to live with what's there and
> Sonatype will actually invest in cleaning up the generally available
> repository. We already have with efforts like this:
>
> http://nexus.sonatype.org/oss-repository-hosting.html
Given this comment, I think you might have misunderstood my post on
dev@... I was of the opinion that clean going forward makes sense,
past stuff is still available, but working on ways to make Maven
understand metadata changes so that you can actually fix things that
go wrong. Some related themes have come up in this thread over the
weekend, but I'll try and follow up on dev@ later with something more
concrete.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Tamás Cservenák <ta...@cservenak.net>.
I did not propose point system to "describe the quality" of repository
alone, I thought of it just to be able to compare two different
repositories... (ie. you find same thing in two of them, decide which one
will you want to use, etc). But now I understand that this would provide a
lot less value that I thought initially.
The other item in my list was "the list of \"problematic\" or simply
\"unusable\" or \"less then qualifiable\" _parts/GAVs/trees_ of repo
itself".... and this sounds more like the deprecation someone proposed...
~t~
On Sun, Sep 27, 2009 at 7:41 PM, Benson Margulies <bi...@gmail.com>wrote:
> I agree that a point system is pointless.
>
>
Re: Maven Central Repository - Cleanup Efforts
Posted by Jason van Zyl <jv...@sonatype.com>.
Only pointing out that's what people typically do.
On 2009-09-27, at 11:27 AM, Benson Margulies wrote:
> Mr. Zyl,
>
> Please don't mistake me. I'm on your side of this debate. I am no more
> arguing against basic cleanup than I am arguing for trying to get
> into the
> business of arbitrating and publishing elaborate metadata about what
> is
> inside or behind the artifacts.
>
> Central should be as clean as possible in a functional sense: the
> artifacts
> in it should contain what they claim to contain, have accurate
> dependencies,
> etc. A scheme to hang red flags on historical items that have
> problems is
> great.
>
> --benson
>
>
> On Sun, Sep 27, 2009 at 2:17 PM, Jason van Zyl
> <jv...@sonatype.com> wrote:
>
>> This is exactly what all sane users do, but we will still try
>> extremely
>> hard to clean everything up and make it easier for open source
>> projects to
>> get their artifacts to central.
>>
>>
>> On 2009-09-27, at 10:41 AM, Benson Margulies wrote:
>>
>> I agree that a point system is pointless.
>>>
>>> I mostly care about whether an artifact is well-formed. I don't
>>> depend on
>>> maven central to help me make business decisions about what open
>>> source
>>> components to depend on. If I need a component, I do the research
>>> to see
>>> what exists, what has a live community, what the licenses are, etc.
>>> Finally,
>>> when I know that I want something, I go see if its on central. If
>>> it's
>>> not,
>>> then I grumble and make arrangements to get to it from my local
>>> nexus
>>> instance. All I need to know from central is whether it contains a
>>> functional, up-to-date artifact set f whatever component I've
>>> determined
>>> that I want to use.
>>>
>>>
>>> On Sun, Sep 27, 2009 at 5:13 AM, Anders Kristian Andersen <
>>> anders.kristian.andersen@gmail.com> wrote:
>>>
>>> I hope I get this right
>>>> Jason here states that there should only be one central
>>>>
>>>> And yes we can ONLY have ONE central. And this is the ONE we got
>>>> today
>>>> !!!!
>>>> That must be the game we are playing.
>>>> The community must be able to TRUST maven / central.
>>>> Starting changing this could cause doubt, and a very easy attach
>>>> zone for
>>>> competitors...
>>>>
>>>> When this is stated....
>>>> We must acknowledge we got problems !!!
>>>> The central is full of legacy, some artifacts that even might not
>>>> work,
>>>> moved etc.
>>>>
>>>> Here the solution can be to add deprecation lists or better
>>>> component-qualtiy-attributes (an xml file next to a component)
>>>>
>>>> To speak clear: pom.xml xx.jar xxx.war ... is read-only.
>>>>
>>>> But a component-quality-attribute.xml file can be maintained, and
>>>> updated.
>>>>
>>>> The quality attributes can be like:
>>>> deprecated false / true .. when true + a description
>>>> runs-JVM-1.5 true/ (false + description / problem reference )
>>>> runs-JVM-1.6 true/ (false + description / problem
>>>> reference )
>>>> runs-JVM-1.7 true/ (false + description / problem reference )
>>>> runs-JVM-1.8 when this becomes relevant
>>>> is-moved (no) or path to new location
>>>>
>>>> osgi-compliant true / false
>>>> ivy-enabled true /false
>>>> groovy-enabled
>>>>
>>>> maven-2 enabled true / false ... most of our maven-2
>>>> artifacts
>>>> should hopefully have true here :-)
>>>> maven-3 enabled (soon..)
>>>> maven-4 enabled (when this becomes relevant)
>>>>
>>>> various PMD level compliant
>>>>
>>>>
>>>> I here by tries to state that we cannot predict the future.
>>>> What today seens perfect, might tomorrow be less usable.
>>>>
>>>>
>>>> With such attributes users can select the artifacts matching their
>>>> demands.
>>>> I am not sure a point system from 1..10 will match the
>>>> requirements.
>>>>
>>>> Best regards
>>>> Anders Kristian Andersen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 26/09/2009, at 21.15, Jason van Zyl wrote:
>>>>
>>>>
>>>> On 2009-09-26, at 10:58 AM, Albert Kurucz wrote:
>>>>>
>>>>> Very nice idea to measure the quality.
>>>>>
>>>>>> But sorry Tamas, 50% corrupt or 90% corrupt does not make a
>>>>>> difference
>>>>>> for me.
>>>>>> Especially not, when I have feeling that it is possible to
>>>>>> maintain a
>>>>>> 100% clean repo with the right automation tools.
>>>>>> If Sonatype's goal is to sell these tools only for paying
>>>>>> customers I
>>>>>> don't have a bad feeling about that. Everyone has to make a
>>>>>> living.
>>>>>> But I hope sometime similar tools and a clean repo will be
>>>>>> available
>>>>>> for the open public.
>>>>>> I hope OSS developers will recognize the need for quality (and
>>>>>> a high
>>>>>> quality repo).
>>>>>>
>>>>>>
>>>>> Not having a super high quality central repository actually
>>>>> makes our
>>>>> commercial efforts a lot harder. If I was devious I would have
>>>>> agreed
>>>>> with
>>>>> Brett and would make a completely clean central repository as
>>>>> our plans
>>>>> require intact repositories. But we don't have a clean
>>>>> repository and
>>>>> trying
>>>>> to make a separate one would be a disaster for general use. You
>>>>> have to
>>>>> live
>>>>> with what's there and Sonatype will actually invest in cleaning
>>>>> up the
>>>>> generally available repository. We already have with efforts
>>>>> like this:
>>>>>
>>>>> http://nexus.sonatype.org/oss-repository-hosting.html
>>>>>
>>>>> It would actually cost us more in support with our clients to
>>>>> maintain a
>>>>> dirty Maven Central and a clean Maven Central with the confusion,
>>>>> interoperability problems and general issues of potential
>>>>> distrust it
>>>>> just
>>>>> makes no business sense. Now the information we want to add is of
>>>>> enormous
>>>>> value but it's predicated on generally improving the quality of
>>>>> Maven
>>>>> Central. I don't want Sonatype to be known as the company that
>>>>> stole
>>>>> Maven
>>>>> Central, doesn't do us any good. So trying to sequester improved
>>>>> metadata
>>>>> somewhere is pointless. If the base information is not good,
>>>>> then the
>>>>> whole
>>>>> system is crippled and that screws Sonatype as well as everyone
>>>>> else.
>>>>>
>>>>> So the information in Maven Central on a per-project basis I see
>>>>> increasing greatly with some tools that Sonatype is developing
>>>>> in Nexus
>>>>> and
>>>>> M2Eclipse and this will benefit all Maven users generally. I'm
>>>>> certainly
>>>>> going to leverage that improved information, but so can anyone
>>>>> else.
>>>>>
>>>>>
>>>>> On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY <herve.boutemy@free.fr
>>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
>>>>>>>
>>>>>>> I think we all need some clarification, since we all talk about
>>>>>>>> "quality"
>>>>>>>> (we all agreed upon the basic things unanimously).
>>>>>>>> What is the "quality" of a maven repository (in general)? Can
>>>>>>>> we
>>>>>>>> measure
>>>>>>>> it? Can we define it?
>>>>>>>>
>>>>>>>> A wiki page with piled up (even personal) opinions would be
>>>>>>>> good --
>>>>>>>>
>>>>>>>> don't hesitate to start one on MAVENUSER Wiki [1]
>>>>>>>
>>>>>>> whatever they are -- and later we should cherry-pick the most
>>>>>>> relevant
>>>>>>>
>>>>>>>> ones
>>>>>>>> to build some tooling to build these metric. And then, we could
>>>>>>>> "measure"
>>>>>>>> the quality of different reposes (like central) and have a
>>>>>>>> list of
>>>>>>>> reposes
>>>>>>>> that do meet certain "level of quality" and list publicly the
>>>>>>>> others
>>>>>>>> that
>>>>>>>> does not.
>>>>>>>>
>>>>>>>>
>>>>>>> [1] http://docs.codehaus.org/display/MAVENUSER/Home
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>
>>>>> Jason
>>>>>
>>>>> ----------------------------------------------------------
>>>>> Jason van Zyl
>>>>> Founder, Apache Maven
>>>>> http://twitter.com/jvanzyl
>>>>> ----------------------------------------------------------
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Benson Margulies <bi...@gmail.com>.
Mr. Zyl,
Please don't mistake me. I'm on your side of this debate. I am no more
arguing against basic cleanup than I am arguing for trying to get into the
business of arbitrating and publishing elaborate metadata about what is
inside or behind the artifacts.
Central should be as clean as possible in a functional sense: the artifacts
in it should contain what they claim to contain, have accurate dependencies,
etc. A scheme to hang red flags on historical items that have problems is
great.
--benson
On Sun, Sep 27, 2009 at 2:17 PM, Jason van Zyl <jv...@sonatype.com> wrote:
> This is exactly what all sane users do, but we will still try extremely
> hard to clean everything up and make it easier for open source projects to
> get their artifacts to central.
>
>
> On 2009-09-27, at 10:41 AM, Benson Margulies wrote:
>
> I agree that a point system is pointless.
>>
>> I mostly care about whether an artifact is well-formed. I don't depend on
>> maven central to help me make business decisions about what open source
>> components to depend on. If I need a component, I do the research to see
>> what exists, what has a live community, what the licenses are, etc.
>> Finally,
>> when I know that I want something, I go see if its on central. If it's
>> not,
>> then I grumble and make arrangements to get to it from my local nexus
>> instance. All I need to know from central is whether it contains a
>> functional, up-to-date artifact set f whatever component I've determined
>> that I want to use.
>>
>>
>> On Sun, Sep 27, 2009 at 5:13 AM, Anders Kristian Andersen <
>> anders.kristian.andersen@gmail.com> wrote:
>>
>> I hope I get this right
>>> Jason here states that there should only be one central
>>>
>>> And yes we can ONLY have ONE central. And this is the ONE we got today
>>> !!!!
>>> That must be the game we are playing.
>>> The community must be able to TRUST maven / central.
>>> Starting changing this could cause doubt, and a very easy attach zone for
>>> competitors...
>>>
>>> When this is stated....
>>> We must acknowledge we got problems !!!
>>> The central is full of legacy, some artifacts that even might not work,
>>> moved etc.
>>>
>>> Here the solution can be to add deprecation lists or better
>>> component-qualtiy-attributes (an xml file next to a component)
>>>
>>> To speak clear: pom.xml xx.jar xxx.war ... is read-only.
>>>
>>> But a component-quality-attribute.xml file can be maintained, and
>>> updated.
>>>
>>> The quality attributes can be like:
>>> deprecated false / true .. when true + a description
>>> runs-JVM-1.5 true/ (false + description / problem reference )
>>> runs-JVM-1.6 true/ (false + description / problem reference )
>>> runs-JVM-1.7 true/ (false + description / problem reference )
>>> runs-JVM-1.8 when this becomes relevant
>>> is-moved (no) or path to new location
>>>
>>> osgi-compliant true / false
>>> ivy-enabled true /false
>>> groovy-enabled
>>>
>>> maven-2 enabled true / false ... most of our maven-2 artifacts
>>> should hopefully have true here :-)
>>> maven-3 enabled (soon..)
>>> maven-4 enabled (when this becomes relevant)
>>>
>>> various PMD level compliant
>>>
>>>
>>> I here by tries to state that we cannot predict the future.
>>> What today seens perfect, might tomorrow be less usable.
>>>
>>>
>>> With such attributes users can select the artifacts matching their
>>> demands.
>>> I am not sure a point system from 1..10 will match the requirements.
>>>
>>> Best regards
>>> Anders Kristian Andersen
>>>
>>>
>>>
>>>
>>>
>>> On 26/09/2009, at 21.15, Jason van Zyl wrote:
>>>
>>>
>>> On 2009-09-26, at 10:58 AM, Albert Kurucz wrote:
>>>>
>>>> Very nice idea to measure the quality.
>>>>
>>>>> But sorry Tamas, 50% corrupt or 90% corrupt does not make a difference
>>>>> for me.
>>>>> Especially not, when I have feeling that it is possible to maintain a
>>>>> 100% clean repo with the right automation tools.
>>>>> If Sonatype's goal is to sell these tools only for paying customers I
>>>>> don't have a bad feeling about that. Everyone has to make a living.
>>>>> But I hope sometime similar tools and a clean repo will be available
>>>>> for the open public.
>>>>> I hope OSS developers will recognize the need for quality (and a high
>>>>> quality repo).
>>>>>
>>>>>
>>>> Not having a super high quality central repository actually makes our
>>>> commercial efforts a lot harder. If I was devious I would have agreed
>>>> with
>>>> Brett and would make a completely clean central repository as our plans
>>>> require intact repositories. But we don't have a clean repository and
>>>> trying
>>>> to make a separate one would be a disaster for general use. You have to
>>>> live
>>>> with what's there and Sonatype will actually invest in cleaning up the
>>>> generally available repository. We already have with efforts like this:
>>>>
>>>> http://nexus.sonatype.org/oss-repository-hosting.html
>>>>
>>>> It would actually cost us more in support with our clients to maintain a
>>>> dirty Maven Central and a clean Maven Central with the confusion,
>>>> interoperability problems and general issues of potential distrust it
>>>> just
>>>> makes no business sense. Now the information we want to add is of
>>>> enormous
>>>> value but it's predicated on generally improving the quality of Maven
>>>> Central. I don't want Sonatype to be known as the company that stole
>>>> Maven
>>>> Central, doesn't do us any good. So trying to sequester improved
>>>> metadata
>>>> somewhere is pointless. If the base information is not good, then the
>>>> whole
>>>> system is crippled and that screws Sonatype as well as everyone else.
>>>>
>>>> So the information in Maven Central on a per-project basis I see
>>>> increasing greatly with some tools that Sonatype is developing in Nexus
>>>> and
>>>> M2Eclipse and this will benefit all Maven users generally. I'm certainly
>>>> going to leverage that improved information, but so can anyone else.
>>>>
>>>>
>>>> On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY <herve.boutemy@free.fr
>>>>> >
>>>>> wrote:
>>>>>
>>>>> Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
>>>>>>
>>>>>> I think we all need some clarification, since we all talk about
>>>>>>> "quality"
>>>>>>> (we all agreed upon the basic things unanimously).
>>>>>>> What is the "quality" of a maven repository (in general)? Can we
>>>>>>> measure
>>>>>>> it? Can we define it?
>>>>>>>
>>>>>>> A wiki page with piled up (even personal) opinions would be good --
>>>>>>>
>>>>>>> don't hesitate to start one on MAVENUSER Wiki [1]
>>>>>>
>>>>>> whatever they are -- and later we should cherry-pick the most relevant
>>>>>>
>>>>>>> ones
>>>>>>> to build some tooling to build these metric. And then, we could
>>>>>>> "measure"
>>>>>>> the quality of different reposes (like central) and have a list of
>>>>>>> reposes
>>>>>>> that do meet certain "level of quality" and list publicly the others
>>>>>>> that
>>>>>>> does not.
>>>>>>>
>>>>>>>
>>>>>> [1] http://docs.codehaus.org/display/MAVENUSER/Home
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>> Thanks,
>>>>
>>>> Jason
>>>>
>>>> ----------------------------------------------------------
>>>> Jason van Zyl
>>>> Founder, Apache Maven
>>>> http://twitter.com/jvanzyl
>>>> ----------------------------------------------------------
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Maven Central Repository - Cleanup Efforts
Posted by Jason van Zyl <jv...@sonatype.com>.
This is exactly what all sane users do, but we will still try
extremely hard to clean everything up and make it easier for open
source projects to get their artifacts to central.
On 2009-09-27, at 10:41 AM, Benson Margulies wrote:
> I agree that a point system is pointless.
>
> I mostly care about whether an artifact is well-formed. I don't
> depend on
> maven central to help me make business decisions about what open
> source
> components to depend on. If I need a component, I do the research to
> see
> what exists, what has a live community, what the licenses are, etc.
> Finally,
> when I know that I want something, I go see if its on central. If
> it's not,
> then I grumble and make arrangements to get to it from my local nexus
> instance. All I need to know from central is whether it contains a
> functional, up-to-date artifact set f whatever component I've
> determined
> that I want to use.
>
>
> On Sun, Sep 27, 2009 at 5:13 AM, Anders Kristian Andersen <
> anders.kristian.andersen@gmail.com> wrote:
>
>> I hope I get this right
>> Jason here states that there should only be one central
>>
>> And yes we can ONLY have ONE central. And this is the ONE we got
>> today !!!!
>> That must be the game we are playing.
>> The community must be able to TRUST maven / central.
>> Starting changing this could cause doubt, and a very easy attach
>> zone for
>> competitors...
>>
>> When this is stated....
>> We must acknowledge we got problems !!!
>> The central is full of legacy, some artifacts that even might not
>> work,
>> moved etc.
>>
>> Here the solution can be to add deprecation lists or better
>> component-qualtiy-attributes (an xml file next to a component)
>>
>> To speak clear: pom.xml xx.jar xxx.war ... is read-only.
>>
>> But a component-quality-attribute.xml file can be maintained, and
>> updated.
>>
>> The quality attributes can be like:
>> deprecated false / true .. when true + a description
>> runs-JVM-1.5 true/ (false + description / problem reference )
>> runs-JVM-1.6 true/ (false + description / problem
>> reference )
>> runs-JVM-1.7 true/ (false + description / problem reference )
>> runs-JVM-1.8 when this becomes relevant
>> is-moved (no) or path to new location
>>
>> osgi-compliant true / false
>> ivy-enabled true /false
>> groovy-enabled
>>
>> maven-2 enabled true / false ... most of our maven-2
>> artifacts
>> should hopefully have true here :-)
>> maven-3 enabled (soon..)
>> maven-4 enabled (when this becomes relevant)
>>
>> various PMD level compliant
>>
>>
>> I here by tries to state that we cannot predict the future.
>> What today seens perfect, might tomorrow be less usable.
>>
>>
>> With such attributes users can select the artifacts matching their
>> demands.
>> I am not sure a point system from 1..10 will match the requirements.
>>
>> Best regards
>> Anders Kristian Andersen
>>
>>
>>
>>
>>
>> On 26/09/2009, at 21.15, Jason van Zyl wrote:
>>
>>
>>> On 2009-09-26, at 10:58 AM, Albert Kurucz wrote:
>>>
>>> Very nice idea to measure the quality.
>>>> But sorry Tamas, 50% corrupt or 90% corrupt does not make a
>>>> difference
>>>> for me.
>>>> Especially not, when I have feeling that it is possible to
>>>> maintain a
>>>> 100% clean repo with the right automation tools.
>>>> If Sonatype's goal is to sell these tools only for paying
>>>> customers I
>>>> don't have a bad feeling about that. Everyone has to make a living.
>>>> But I hope sometime similar tools and a clean repo will be
>>>> available
>>>> for the open public.
>>>> I hope OSS developers will recognize the need for quality (and a
>>>> high
>>>> quality repo).
>>>>
>>>
>>> Not having a super high quality central repository actually makes
>>> our
>>> commercial efforts a lot harder. If I was devious I would have
>>> agreed with
>>> Brett and would make a completely clean central repository as our
>>> plans
>>> require intact repositories. But we don't have a clean repository
>>> and trying
>>> to make a separate one would be a disaster for general use. You
>>> have to live
>>> with what's there and Sonatype will actually invest in cleaning up
>>> the
>>> generally available repository. We already have with efforts like
>>> this:
>>>
>>> http://nexus.sonatype.org/oss-repository-hosting.html
>>>
>>> It would actually cost us more in support with our clients to
>>> maintain a
>>> dirty Maven Central and a clean Maven Central with the confusion,
>>> interoperability problems and general issues of potential distrust
>>> it just
>>> makes no business sense. Now the information we want to add is of
>>> enormous
>>> value but it's predicated on generally improving the quality of
>>> Maven
>>> Central. I don't want Sonatype to be known as the company that
>>> stole Maven
>>> Central, doesn't do us any good. So trying to sequester improved
>>> metadata
>>> somewhere is pointless. If the base information is not good, then
>>> the whole
>>> system is crippled and that screws Sonatype as well as everyone
>>> else.
>>>
>>> So the information in Maven Central on a per-project basis I see
>>> increasing greatly with some tools that Sonatype is developing in
>>> Nexus and
>>> M2Eclipse and this will benefit all Maven users generally. I'm
>>> certainly
>>> going to leverage that improved information, but so can anyone else.
>>>
>>>
>>>> On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY <herve.boutemy@free.fr
>>>> >
>>>> wrote:
>>>>
>>>>> Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
>>>>>
>>>>>> I think we all need some clarification, since we all talk about
>>>>>> "quality"
>>>>>> (we all agreed upon the basic things unanimously).
>>>>>> What is the "quality" of a maven repository (in general)? Can we
>>>>>> measure
>>>>>> it? Can we define it?
>>>>>>
>>>>>> A wiki page with piled up (even personal) opinions would be
>>>>>> good --
>>>>>>
>>>>> don't hesitate to start one on MAVENUSER Wiki [1]
>>>>>
>>>>> whatever they are -- and later we should cherry-pick the most
>>>>> relevant
>>>>>> ones
>>>>>> to build some tooling to build these metric. And then, we could
>>>>>> "measure"
>>>>>> the quality of different reposes (like central) and have a list
>>>>>> of
>>>>>> reposes
>>>>>> that do meet certain "level of quality" and list publicly the
>>>>>> others
>>>>>> that
>>>>>> does not.
>>>>>>
>>>>>
>>>>> [1] http://docs.codehaus.org/display/MAVENUSER/Home
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Benson Margulies <bi...@gmail.com>.
I agree that a point system is pointless.
I mostly care about whether an artifact is well-formed. I don't depend on
maven central to help me make business decisions about what open source
components to depend on. If I need a component, I do the research to see
what exists, what has a live community, what the licenses are, etc. Finally,
when I know that I want something, I go see if its on central. If it's not,
then I grumble and make arrangements to get to it from my local nexus
instance. All I need to know from central is whether it contains a
functional, up-to-date artifact set f whatever component I've determined
that I want to use.
On Sun, Sep 27, 2009 at 5:13 AM, Anders Kristian Andersen <
anders.kristian.andersen@gmail.com> wrote:
> I hope I get this right
> Jason here states that there should only be one central
>
> And yes we can ONLY have ONE central. And this is the ONE we got today !!!!
> That must be the game we are playing.
> The community must be able to TRUST maven / central.
> Starting changing this could cause doubt, and a very easy attach zone for
> competitors...
>
> When this is stated....
> We must acknowledge we got problems !!!
> The central is full of legacy, some artifacts that even might not work,
> moved etc.
>
> Here the solution can be to add deprecation lists or better
> component-qualtiy-attributes (an xml file next to a component)
>
> To speak clear: pom.xml xx.jar xxx.war ... is read-only.
>
> But a component-quality-attribute.xml file can be maintained, and updated.
>
> The quality attributes can be like:
> deprecated false / true .. when true + a description
> runs-JVM-1.5 true/ (false + description / problem reference )
> runs-JVM-1.6 true/ (false + description / problem reference )
> runs-JVM-1.7 true/ (false + description / problem reference )
> runs-JVM-1.8 when this becomes relevant
> is-moved (no) or path to new location
>
> osgi-compliant true / false
> ivy-enabled true /false
> groovy-enabled
>
> maven-2 enabled true / false ... most of our maven-2 artifacts
> should hopefully have true here :-)
> maven-3 enabled (soon..)
> maven-4 enabled (when this becomes relevant)
>
> various PMD level compliant
>
>
> I here by tries to state that we cannot predict the future.
> What today seens perfect, might tomorrow be less usable.
>
>
> With such attributes users can select the artifacts matching their demands.
> I am not sure a point system from 1..10 will match the requirements.
>
> Best regards
> Anders Kristian Andersen
>
>
>
>
>
> On 26/09/2009, at 21.15, Jason van Zyl wrote:
>
>
>> On 2009-09-26, at 10:58 AM, Albert Kurucz wrote:
>>
>> Very nice idea to measure the quality.
>>> But sorry Tamas, 50% corrupt or 90% corrupt does not make a difference
>>> for me.
>>> Especially not, when I have feeling that it is possible to maintain a
>>> 100% clean repo with the right automation tools.
>>> If Sonatype's goal is to sell these tools only for paying customers I
>>> don't have a bad feeling about that. Everyone has to make a living.
>>> But I hope sometime similar tools and a clean repo will be available
>>> for the open public.
>>> I hope OSS developers will recognize the need for quality (and a high
>>> quality repo).
>>>
>>
>> Not having a super high quality central repository actually makes our
>> commercial efforts a lot harder. If I was devious I would have agreed with
>> Brett and would make a completely clean central repository as our plans
>> require intact repositories. But we don't have a clean repository and trying
>> to make a separate one would be a disaster for general use. You have to live
>> with what's there and Sonatype will actually invest in cleaning up the
>> generally available repository. We already have with efforts like this:
>>
>> http://nexus.sonatype.org/oss-repository-hosting.html
>>
>> It would actually cost us more in support with our clients to maintain a
>> dirty Maven Central and a clean Maven Central with the confusion,
>> interoperability problems and general issues of potential distrust it just
>> makes no business sense. Now the information we want to add is of enormous
>> value but it's predicated on generally improving the quality of Maven
>> Central. I don't want Sonatype to be known as the company that stole Maven
>> Central, doesn't do us any good. So trying to sequester improved metadata
>> somewhere is pointless. If the base information is not good, then the whole
>> system is crippled and that screws Sonatype as well as everyone else.
>>
>> So the information in Maven Central on a per-project basis I see
>> increasing greatly with some tools that Sonatype is developing in Nexus and
>> M2Eclipse and this will benefit all Maven users generally. I'm certainly
>> going to leverage that improved information, but so can anyone else.
>>
>>
>>> On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY <he...@free.fr>
>>> wrote:
>>>
>>>> Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
>>>>
>>>>> I think we all need some clarification, since we all talk about
>>>>> "quality"
>>>>> (we all agreed upon the basic things unanimously).
>>>>> What is the "quality" of a maven repository (in general)? Can we
>>>>> measure
>>>>> it? Can we define it?
>>>>>
>>>>> A wiki page with piled up (even personal) opinions would be good --
>>>>>
>>>> don't hesitate to start one on MAVENUSER Wiki [1]
>>>>
>>>> whatever they are -- and later we should cherry-pick the most relevant
>>>>> ones
>>>>> to build some tooling to build these metric. And then, we could
>>>>> "measure"
>>>>> the quality of different reposes (like central) and have a list of
>>>>> reposes
>>>>> that do meet certain "level of quality" and list publicly the others
>>>>> that
>>>>> does not.
>>>>>
>>>>
>>>> [1] http://docs.codehaus.org/display/MAVENUSER/Home
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Maven Central Repository - Cleanup Efforts
Posted by Anders Kristian Andersen <an...@gmail.com>.
I hope I get this right
Jason here states that there should only be one central
And yes we can ONLY have ONE central. And this is the ONE we got
today !!!!
That must be the game we are playing.
The community must be able to TRUST maven / central.
Starting changing this could cause doubt, and a very easy attach zone
for competitors...
When this is stated....
We must acknowledge we got problems !!!
The central is full of legacy, some artifacts that even might not
work, moved etc.
Here the solution can be to add deprecation lists or better component-
qualtiy-attributes (an xml file next to a component)
To speak clear: pom.xml xx.jar xxx.war ... is read-only.
But a component-quality-attribute.xml file can be maintained, and
updated.
The quality attributes can be like:
deprecated false / true .. when true + a description
runs-JVM-1.5 true/ (false + description / problem reference )
runs-JVM-1.6 true/ (false + description / problem reference )
runs-JVM-1.7 true/ (false + description / problem reference )
runs-JVM-1.8 when this becomes relevant
is-moved (no) or path to new location
osgi-compliant true / false
ivy-enabled true /false
groovy-enabled
maven-2 enabled true / false ... most of our maven-2 artifacts
should hopefully have true here :-)
maven-3 enabled (soon..)
maven-4 enabled (when this becomes relevant)
various PMD level compliant
I here by tries to state that we cannot predict the future.
What today seens perfect, might tomorrow be less usable.
With such attributes users can select the artifacts matching their
demands.
I am not sure a point system from 1..10 will match the requirements.
Best regards
Anders Kristian Andersen
On 26/09/2009, at 21.15, Jason van Zyl wrote:
>
> On 2009-09-26, at 10:58 AM, Albert Kurucz wrote:
>
>> Very nice idea to measure the quality.
>> But sorry Tamas, 50% corrupt or 90% corrupt does not make a
>> difference for me.
>> Especially not, when I have feeling that it is possible to maintain a
>> 100% clean repo with the right automation tools.
>> If Sonatype's goal is to sell these tools only for paying customers I
>> don't have a bad feeling about that. Everyone has to make a living.
>> But I hope sometime similar tools and a clean repo will be available
>> for the open public.
>> I hope OSS developers will recognize the need for quality (and a high
>> quality repo).
>
> Not having a super high quality central repository actually makes
> our commercial efforts a lot harder. If I was devious I would have
> agreed with Brett and would make a completely clean central
> repository as our plans require intact repositories. But we don't
> have a clean repository and trying to make a separate one would be a
> disaster for general use. You have to live with what's there and
> Sonatype will actually invest in cleaning up the generally available
> repository. We already have with efforts like this:
>
> http://nexus.sonatype.org/oss-repository-hosting.html
>
> It would actually cost us more in support with our clients to
> maintain a dirty Maven Central and a clean Maven Central with the
> confusion, interoperability problems and general issues of potential
> distrust it just makes no business sense. Now the information we
> want to add is of enormous value but it's predicated on generally
> improving the quality of Maven Central. I don't want Sonatype to be
> known as the company that stole Maven Central, doesn't do us any
> good. So trying to sequester improved metadata somewhere is
> pointless. If the base information is not good, then the whole
> system is crippled and that screws Sonatype as well as everyone else.
>
> So the information in Maven Central on a per-project basis I see
> increasing greatly with some tools that Sonatype is developing in
> Nexus and M2Eclipse and this will benefit all Maven users generally.
> I'm certainly going to leverage that improved information, but so
> can anyone else.
>
>>
>> On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY <herve.boutemy@free.fr
>> > wrote:
>>> Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
>>>> I think we all need some clarification, since we all talk about
>>>> "quality"
>>>> (we all agreed upon the basic things unanimously).
>>>> What is the "quality" of a maven repository (in general)? Can we
>>>> measure
>>>> it? Can we define it?
>>>>
>>>> A wiki page with piled up (even personal) opinions would be good --
>>> don't hesitate to start one on MAVENUSER Wiki [1]
>>>
>>>> whatever they are -- and later we should cherry-pick the most
>>>> relevant ones
>>>> to build some tooling to build these metric. And then, we could
>>>> "measure"
>>>> the quality of different reposes (like central) and have a list
>>>> of reposes
>>>> that do meet certain "level of quality" and list publicly the
>>>> others that
>>>> does not.
>>>
>>> [1] http://docs.codehaus.org/display/MAVENUSER/Home
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Jason van Zyl <jv...@sonatype.com>.
On 2009-09-26, at 10:58 AM, Albert Kurucz wrote:
> Very nice idea to measure the quality.
> But sorry Tamas, 50% corrupt or 90% corrupt does not make a
> difference for me.
> Especially not, when I have feeling that it is possible to maintain a
> 100% clean repo with the right automation tools.
> If Sonatype's goal is to sell these tools only for paying customers I
> don't have a bad feeling about that. Everyone has to make a living.
> But I hope sometime similar tools and a clean repo will be available
> for the open public.
> I hope OSS developers will recognize the need for quality (and a high
> quality repo).
Not having a super high quality central repository actually makes our
commercial efforts a lot harder. If I was devious I would have agreed
with Brett and would make a completely clean central repository as our
plans require intact repositories. But we don't have a clean
repository and trying to make a separate one would be a disaster for
general use. You have to live with what's there and Sonatype will
actually invest in cleaning up the generally available repository. We
already have with efforts like this:
http://nexus.sonatype.org/oss-repository-hosting.html
It would actually cost us more in support with our clients to maintain
a dirty Maven Central and a clean Maven Central with the confusion,
interoperability problems and general issues of potential distrust it
just makes no business sense. Now the information we want to add is of
enormous value but it's predicated on generally improving the quality
of Maven Central. I don't want Sonatype to be known as the company
that stole Maven Central, doesn't do us any good. So trying to
sequester improved metadata somewhere is pointless. If the base
information is not good, then the whole system is crippled and that
screws Sonatype as well as everyone else.
So the information in Maven Central on a per-project basis I see
increasing greatly with some tools that Sonatype is developing in
Nexus and M2Eclipse and this will benefit all Maven users generally.
I'm certainly going to leverage that improved information, but so can
anyone else.
>
> On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY
> <he...@free.fr> wrote:
>> Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
>>> I think we all need some clarification, since we all talk about
>>> "quality"
>>> (we all agreed upon the basic things unanimously).
>>> What is the "quality" of a maven repository (in general)? Can we
>>> measure
>>> it? Can we define it?
>>>
>>> A wiki page with piled up (even personal) opinions would be good --
>> don't hesitate to start one on MAVENUSER Wiki [1]
>>
>>> whatever they are -- and later we should cherry-pick the most
>>> relevant ones
>>> to build some tooling to build these metric. And then, we could
>>> "measure"
>>> the quality of different reposes (like central) and have a list of
>>> reposes
>>> that do meet certain "level of quality" and list publicly the
>>> others that
>>> does not.
>>
>> [1] http://docs.codehaus.org/display/MAVENUSER/Home
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
Very nice idea to measure the quality.
But sorry Tamas, 50% corrupt or 90% corrupt does not make a difference for me.
Especially not, when I have feeling that it is possible to maintain a
100% clean repo with the right automation tools.
If Sonatype's goal is to sell these tools only for paying customers I
don't have a bad feeling about that. Everyone has to make a living.
But I hope sometime similar tools and a clean repo will be available
for the open public.
I hope OSS developers will recognize the need for quality (and a high
quality repo).
On Sat, Sep 26, 2009 at 11:22 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
>> I think we all need some clarification, since we all talk about "quality"
>> (we all agreed upon the basic things unanimously).
>> What is the "quality" of a maven repository (in general)? Can we measure
>> it? Can we define it?
>>
>> A wiki page with piled up (even personal) opinions would be good --
> don't hesitate to start one on MAVENUSER Wiki [1]
>
>> whatever they are -- and later we should cherry-pick the most relevant ones
>> to build some tooling to build these metric. And then, we could "measure"
>> the quality of different reposes (like central) and have a list of reposes
>> that do meet certain "level of quality" and list publicly the others that
>> does not.
>
> [1] http://docs.codehaus.org/display/MAVENUSER/Home
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Hervé BOUTEMY <he...@free.fr>.
Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
> I think we all need some clarification, since we all talk about "quality"
> (we all agreed upon the basic things unanimously).
> What is the "quality" of a maven repository (in general)? Can we measure
> it? Can we define it?
>
> A wiki page with piled up (even personal) opinions would be good --
don't hesitate to start one on MAVENUSER Wiki [1]
> whatever they are -- and later we should cherry-pick the most relevant ones
> to build some tooling to build these metric. And then, we could "measure"
> the quality of different reposes (like central) and have a list of reposes
> that do meet certain "level of quality" and list publicly the others that
> does not.
[1] http://docs.codehaus.org/display/MAVENUSER/Home
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Tamás Cservenák <ta...@cservenak.net>.
I think we all need some clarification, since we all talk about "quality"
(we all agreed upon the basic things unanimously).
What is the "quality" of a maven repository (in general)? Can we measure it?
Can we define it?
A wiki page with piled up (even personal) opinions would be good -- whatever
they are -- and later we should cherry-pick the most relevant ones to build
some tooling to build these metric. And then, we could "measure" the quality
of different reposes (like central) and have a list of reposes that do meet
certain "level of quality" and list publicly the others that does not.
We could ask repo maintainers -- just like we did with Nexus indexes --
simply to publish these "meta information" (metrics) information in their
reposes, and repo consumers could decide: "do I want or not a repo of 3.14
MRQ* to participate in my build or not".
Of course, persons or organizations would be able to raise MRQ just by
letting it thru (and "fixing"/improving) the repo in question over some
tools (MRMs are at once the 1st thing becoming obvious choice).
*MRQ = Maven Repo Quality index, for example a scalar number with range 0-10
(if the "quality" is representable as such)
Thanks,
~t~
PS: I am really interested, if once done, what score would central get ;)
On Sat, Sep 26, 2009 at 3:14 PM, Hervé BOUTEMY <he...@free.fr>wrote:
> I need some clarifications to be sure that we are all speaking of the same
> thing.
>
>
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
Somebody just gave me an idea what would be an excellent tool to crawl
through a repository and create an index of the artifacts, which pass
some kind of acceptance criteria:
http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer
// get NexusIndexer component from Plexus
PlexusContainer plexus = embedder.getPlexusContainer();
NexusIndexer indexer = (NexusIndexer) plexus.lookup(NexusIndexer.class);
IndexUpdater updater = (IndexUpdater) plexus.lookup(IndexUpdater.class);
// add indexing context (stateful), should be done once for lifetime
if(CONDITION)
{
indexer.addIndexingContext(
indexId, // index id (usually the same as repository id)
repositoryId, // repository id
directory, // Lucene directory where index is stored
repositoryDir, // local repository dir or null for remote repo
repositoryUrl, // repository url, used by index updater
indexUpdateUrl, // index update url or null if derived from repositoryUrl
false, false);
}
What should be the CONDITION?
On Tue, Sep 29, 2009 at 12:02 PM, Albert Kurucz <al...@gmail.com> wrote:
> For some start-ups, this could mean a business opportunity!
> Nobody said, that the quality info should be given away free.
>
> On Tue, Sep 29, 2009 at 7:21 AM, Albert Kurucz <al...@gmail.com> wrote:
>>> Do you really mean that you would like to enforce such -source-release.zip
>>> artefacts to be published?
>> Not any qualities of the code should be enforced.
>> But I very much want to be able to find those gems from the big pile of ...
>>
>> Therefore the artifacts on Central should be search-able and filter-able.
>> Some people want to add more metadata to support this.
>> My opinion is that this approach will not work, it just opens the door
>> for more corruption.
>>
>> There should be independent software quality certifications agencies,
>> which issue issue their lists certifying that artifacts on that list
>> fulfill certain well specified minimum quality measures.
>>
>> Maven should be able to use the output from these agencies (for
>> filtering or search).
>> I hope agencies will maintain high quality of their database, because
>> credibility can be lost only once.
>>
>> On Sat, Sep 26, 2009 at 8:14 AM, Hervé BOUTEMY <he...@free.fr> wrote:
>>> Le samedi 26 septembre 2009, Albert Kurucz a écrit :
>>>> For the additional requirement, getting into the pure Maven repo (The
>>>> best), I really meant: build-able.
>>>>
>>>> Me too, I don't really care what tool you use to build it as long as
>>>> the tool is already checked in and you only use the attached metadata
>>>> and the attached sources.
>>> I need some clarifications to be sure that we are all speaking of the same
>>> thing.
>>>
>>> -sources.jar artefacts usually attached to the main artefact are not meant to
>>> be buildable, but used for IDEs. You can't build with that, since it's only a
>>> part of the sources, and does not honour directories expected in pom.xml.
>>>
>>> Since a few months, -source-release.zip artefacts were added to latest
>>> Apache's artefacts (at least Maven's ones) to provide buildable source.
>>> See [1] for example.
>>>
>>> Do you really mean that you would like to enforce such -source-release.zip
>>> artefacts to be published?
>>>
>>> [1] http://repo2.maven.org/maven2/org/apache/maven/plugins/maven-invoker-
>>> plugin/1.4/
>>>
>>>> But a tool like this, in my eyes is just another Maven plugin.
>>>>
>>>> Why care about being build-able?
>>>> "Non-buildable source is fine as a gesture of goodwill, but I think if the
>>>> public source isn't buildable, we're gonna end up with egg on our faces."
>>>> Quote from:
>>>> http://mail.opensolaris.org/pipermail/opensolaris-discuss/2005-February/002
>>>>170.html
>>>>
>>>> On Fri, Sep 25, 2009 at 4:31 PM, Brian Fox <br...@infinity.nu> wrote:
>>>> > On Fri, Sep 25, 2009 at 12:44 PM, Albert Kurucz <al...@gmail.com>
>>> wrote:
>>>> >> Technically it is possible to manage 3 different OSS Maven repos.
>>>> >>
>>>> >> 1. The good enough
>>>> >> This is the current "Maven Central"
>>>> >> No rules, only "recommendations":
>>>> >> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>> >> Note: it is not a rule what is not enforced!
>>>> >
>>>> > For what purpose? Again this is effectively a dead repo.
>>>> >
>>>> >> 2. The good
>>>> >> This would be the Maven Purgatory.
>>>> >> Same rules applied as above, but rules enforced.
>>>> >> Mistakes of rule-enforcements corrected by purge.
>>>> >
>>>> > Or this is the new data in Central.
>>>> >
>>>> >> 3. The best
>>>> >> Call it the Maven Heaven
>>>> >> Same rules, but only for Maven built projects.
>>>> >
>>>> > Pretty much useless. The tool used to build is completely irrelevant.
>>>> > Such a repo would be so barren as to be hardly useful at all.
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> > For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
For some start-ups, this could mean a business opportunity!
Nobody said, that the quality info should be given away free.
On Tue, Sep 29, 2009 at 7:21 AM, Albert Kurucz <al...@gmail.com> wrote:
>> Do you really mean that you would like to enforce such -source-release.zip
>> artefacts to be published?
> Not any qualities of the code should be enforced.
> But I very much want to be able to find those gems from the big pile of ...
>
> Therefore the artifacts on Central should be search-able and filter-able.
> Some people want to add more metadata to support this.
> My opinion is that this approach will not work, it just opens the door
> for more corruption.
>
> There should be independent software quality certifications agencies,
> which issue issue their lists certifying that artifacts on that list
> fulfill certain well specified minimum quality measures.
>
> Maven should be able to use the output from these agencies (for
> filtering or search).
> I hope agencies will maintain high quality of their database, because
> credibility can be lost only once.
>
> On Sat, Sep 26, 2009 at 8:14 AM, Hervé BOUTEMY <he...@free.fr> wrote:
>> Le samedi 26 septembre 2009, Albert Kurucz a écrit :
>>> For the additional requirement, getting into the pure Maven repo (The
>>> best), I really meant: build-able.
>>>
>>> Me too, I don't really care what tool you use to build it as long as
>>> the tool is already checked in and you only use the attached metadata
>>> and the attached sources.
>> I need some clarifications to be sure that we are all speaking of the same
>> thing.
>>
>> -sources.jar artefacts usually attached to the main artefact are not meant to
>> be buildable, but used for IDEs. You can't build with that, since it's only a
>> part of the sources, and does not honour directories expected in pom.xml.
>>
>> Since a few months, -source-release.zip artefacts were added to latest
>> Apache's artefacts (at least Maven's ones) to provide buildable source.
>> See [1] for example.
>>
>> Do you really mean that you would like to enforce such -source-release.zip
>> artefacts to be published?
>>
>> [1] http://repo2.maven.org/maven2/org/apache/maven/plugins/maven-invoker-
>> plugin/1.4/
>>
>>> But a tool like this, in my eyes is just another Maven plugin.
>>>
>>> Why care about being build-able?
>>> "Non-buildable source is fine as a gesture of goodwill, but I think if the
>>> public source isn't buildable, we're gonna end up with egg on our faces."
>>> Quote from:
>>> http://mail.opensolaris.org/pipermail/opensolaris-discuss/2005-February/002
>>>170.html
>>>
>>> On Fri, Sep 25, 2009 at 4:31 PM, Brian Fox <br...@infinity.nu> wrote:
>>> > On Fri, Sep 25, 2009 at 12:44 PM, Albert Kurucz <al...@gmail.com>
>> wrote:
>>> >> Technically it is possible to manage 3 different OSS Maven repos.
>>> >>
>>> >> 1. The good enough
>>> >> This is the current "Maven Central"
>>> >> No rules, only "recommendations":
>>> >> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>> >> Note: it is not a rule what is not enforced!
>>> >
>>> > For what purpose? Again this is effectively a dead repo.
>>> >
>>> >> 2. The good
>>> >> This would be the Maven Purgatory.
>>> >> Same rules applied as above, but rules enforced.
>>> >> Mistakes of rule-enforcements corrected by purge.
>>> >
>>> > Or this is the new data in Central.
>>> >
>>> >> 3. The best
>>> >> Call it the Maven Heaven
>>> >> Same rules, but only for Maven built projects.
>>> >
>>> > Pretty much useless. The tool used to build is completely irrelevant.
>>> > Such a repo would be so barren as to be hardly useful at all.
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: users-help@maven.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
> Do you really mean that you would like to enforce such -source-release.zip
> artefacts to be published?
Not any qualities of the code should be enforced.
But I very much want to be able to find those gems from the big pile of ...
Therefore the artifacts on Central should be search-able and filter-able.
Some people want to add more metadata to support this.
My opinion is that this approach will not work, it just opens the door
for more corruption.
There should be independent software quality certifications agencies,
which issue issue their lists certifying that artifacts on that list
fulfill certain well specified minimum quality measures.
Maven should be able to use the output from these agencies (for
filtering or search).
I hope agencies will maintain high quality of their database, because
credibility can be lost only once.
On Sat, Sep 26, 2009 at 8:14 AM, Hervé BOUTEMY <he...@free.fr> wrote:
> Le samedi 26 septembre 2009, Albert Kurucz a écrit :
>> For the additional requirement, getting into the pure Maven repo (The
>> best), I really meant: build-able.
>>
>> Me too, I don't really care what tool you use to build it as long as
>> the tool is already checked in and you only use the attached metadata
>> and the attached sources.
> I need some clarifications to be sure that we are all speaking of the same
> thing.
>
> -sources.jar artefacts usually attached to the main artefact are not meant to
> be buildable, but used for IDEs. You can't build with that, since it's only a
> part of the sources, and does not honour directories expected in pom.xml.
>
> Since a few months, -source-release.zip artefacts were added to latest
> Apache's artefacts (at least Maven's ones) to provide buildable source.
> See [1] for example.
>
> Do you really mean that you would like to enforce such -source-release.zip
> artefacts to be published?
>
> [1] http://repo2.maven.org/maven2/org/apache/maven/plugins/maven-invoker-
> plugin/1.4/
>
>> But a tool like this, in my eyes is just another Maven plugin.
>>
>> Why care about being build-able?
>> "Non-buildable source is fine as a gesture of goodwill, but I think if the
>> public source isn't buildable, we're gonna end up with egg on our faces."
>> Quote from:
>> http://mail.opensolaris.org/pipermail/opensolaris-discuss/2005-February/002
>>170.html
>>
>> On Fri, Sep 25, 2009 at 4:31 PM, Brian Fox <br...@infinity.nu> wrote:
>> > On Fri, Sep 25, 2009 at 12:44 PM, Albert Kurucz <al...@gmail.com>
> wrote:
>> >> Technically it is possible to manage 3 different OSS Maven repos.
>> >>
>> >> 1. The good enough
>> >> This is the current "Maven Central"
>> >> No rules, only "recommendations":
>> >> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>> >> Note: it is not a rule what is not enforced!
>> >
>> > For what purpose? Again this is effectively a dead repo.
>> >
>> >> 2. The good
>> >> This would be the Maven Purgatory.
>> >> Same rules applied as above, but rules enforced.
>> >> Mistakes of rule-enforcements corrected by purge.
>> >
>> > Or this is the new data in Central.
>> >
>> >> 3. The best
>> >> Call it the Maven Heaven
>> >> Same rules, but only for Maven built projects.
>> >
>> > Pretty much useless. The tool used to build is completely irrelevant.
>> > Such a repo would be so barren as to be hardly useful at all.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Hervé BOUTEMY <he...@free.fr>.
Le samedi 26 septembre 2009, Albert Kurucz a écrit :
> For the additional requirement, getting into the pure Maven repo (The
> best), I really meant: build-able.
>
> Me too, I don't really care what tool you use to build it as long as
> the tool is already checked in and you only use the attached metadata
> and the attached sources.
I need some clarifications to be sure that we are all speaking of the same
thing.
-sources.jar artefacts usually attached to the main artefact are not meant to
be buildable, but used for IDEs. You can't build with that, since it's only a
part of the sources, and does not honour directories expected in pom.xml.
Since a few months, -source-release.zip artefacts were added to latest
Apache's artefacts (at least Maven's ones) to provide buildable source.
See [1] for example.
Do you really mean that you would like to enforce such -source-release.zip
artefacts to be published?
[1] http://repo2.maven.org/maven2/org/apache/maven/plugins/maven-invoker-
plugin/1.4/
> But a tool like this, in my eyes is just another Maven plugin.
>
> Why care about being build-able?
> "Non-buildable source is fine as a gesture of goodwill, but I think if the
> public source isn't buildable, we're gonna end up with egg on our faces."
> Quote from:
> http://mail.opensolaris.org/pipermail/opensolaris-discuss/2005-February/002
>170.html
>
> On Fri, Sep 25, 2009 at 4:31 PM, Brian Fox <br...@infinity.nu> wrote:
> > On Fri, Sep 25, 2009 at 12:44 PM, Albert Kurucz <al...@gmail.com>
wrote:
> >> Technically it is possible to manage 3 different OSS Maven repos.
> >>
> >> 1. The good enough
> >> This is the current "Maven Central"
> >> No rules, only "recommendations":
> >> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> >> Note: it is not a rule what is not enforced!
> >
> > For what purpose? Again this is effectively a dead repo.
> >
> >> 2. The good
> >> This would be the Maven Purgatory.
> >> Same rules applied as above, but rules enforced.
> >> Mistakes of rule-enforcements corrected by purge.
> >
> > Or this is the new data in Central.
> >
> >> 3. The best
> >> Call it the Maven Heaven
> >> Same rules, but only for Maven built projects.
> >
> > Pretty much useless. The tool used to build is completely irrelevant.
> > Such a repo would be so barren as to be hardly useful at all.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Hervé BOUTEMY <he...@free.fr>.
Le samedi 26 septembre 2009, Albert Kurucz a écrit :
> For the additional requirement, getting into the pure Maven repo (The
> best), I really meant: build-able.
>
> Me too, I don't really care what tool you use to build it as long as
> the tool is already checked in and you only use the attached metadata
> and the attached sources.
I need some clarifications to be sure that we are all speaking of the same
thing.
-sources.jar artefacts usually attached to the main artefact are not meant to
be buildable, but used for IDEs. You can't build with that, since it's only a
part of the sources, and does not honour directories expected in pom.xml.
Since a few months, -source-release.zip artefacts were added to latest
Apache's artefacts (at least Maven's ones) to provide buildable source.
See [1] for example.
Do you really mean that you would like to enforce such -source-release.zip
artefacts to be published?
> But a tool like this, in my eyes is just another Maven plugin.
>
> Why care about being build-able?
> "Non-buildable source is fine as a gesture of goodwill, but I think if the
> public source isn't buildable, we're gonna end up with egg on our faces."
> Quote from:
> http://mail.opensolaris.org/pipermail/opensolaris-discuss/2005-February/002
>170.html
>
> On Fri, Sep 25, 2009 at 4:31 PM, Brian Fox <br...@infinity.nu> wrote:
> > On Fri, Sep 25, 2009 at 12:44 PM, Albert Kurucz <al...@gmail.com>
wrote:
> >> Technically it is possible to manage 3 different OSS Maven repos.
> >>
> >> 1. The good enough
> >> This is the current "Maven Central"
> >> No rules, only "recommendations":
> >> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> >> Note: it is not a rule what is not enforced!
> >
> > For what purpose? Again this is effectively a dead repo.
> >
> >> 2. The good
> >> This would be the Maven Purgatory.
> >> Same rules applied as above, but rules enforced.
> >> Mistakes of rule-enforcements corrected by purge.
> >
> > Or this is the new data in Central.
> >
> >> 3. The best
> >> Call it the Maven Heaven
> >> Same rules, but only for Maven built projects.
> >
> > Pretty much useless. The tool used to build is completely irrelevant.
> > Such a repo would be so barren as to be hardly useful at all.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Stephen Connolly <st...@gmail.com>.
IMHO, being buildable by maven is a nice to have, but to be honest, if
somebody wants to build their project with a DOS batch file and a
piece of string I don't mind as long as they publish the artifact with
a valid pom
anything else is setting the repository up for failure
Sent from my [rhymes with tryPod] ;-)
On 26 Sep 2009, at 09:22, Tamás Cservenák <ta...@cservenak.net> wrote:
> A lot of +1-es to this quote
> ~t~
>
> On Sat, Sep 26, 2009 at 4:35 AM, Albert Kurucz <albert.kurucz@gmail.com
> >wrote:
>
>> "Non-buildable source is fine as a gesture of goodwill, but I think
>> if the
>> public source isn't buildable, we're gonna end up with egg on our
>> faces."
>> Quote from:
>>
>> http://mail.opensolaris.org/pipermail/opensolaris-discuss/2005-February/002170.html
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Tamás Cservenák <ta...@cservenak.net>.
A lot of +1-es to this quote
~t~
On Sat, Sep 26, 2009 at 4:35 AM, Albert Kurucz <al...@gmail.com>wrote:
> "Non-buildable source is fine as a gesture of goodwill, but I think if the
> public source isn't buildable, we're gonna end up with egg on our faces."
> Quote from:
>
> http://mail.opensolaris.org/pipermail/opensolaris-discuss/2005-February/002170.html
>
>
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
For the additional requirement, getting into the pure Maven repo (The
best), I really meant: build-able.
Me too, I don't really care what tool you use to build it as long as
the tool is already checked in and you only use the attached metadata
and the attached sources.
But a tool like this, in my eyes is just another Maven plugin.
Why care about being build-able?
"Non-buildable source is fine as a gesture of goodwill, but I think if the
public source isn't buildable, we're gonna end up with egg on our faces."
Quote from:
http://mail.opensolaris.org/pipermail/opensolaris-discuss/2005-February/002170.html
On Fri, Sep 25, 2009 at 4:31 PM, Brian Fox <br...@infinity.nu> wrote:
> On Fri, Sep 25, 2009 at 12:44 PM, Albert Kurucz <al...@gmail.com> wrote:
>> Technically it is possible to manage 3 different OSS Maven repos.
>>
>> 1. The good enough
>> This is the current "Maven Central"
>> No rules, only "recommendations":
>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>> Note: it is not a rule what is not enforced!
>
>
> For what purpose? Again this is effectively a dead repo.
>>
>> 2. The good
>> This would be the Maven Purgatory.
>> Same rules applied as above, but rules enforced.
>> Mistakes of rule-enforcements corrected by purge.
>>
>
> Or this is the new data in Central.
>
>> 3. The best
>> Call it the Maven Heaven
>> Same rules, but only for Maven built projects.
>>
>
> Pretty much useless. The tool used to build is completely irrelevant.
> Such a repo would be so barren as to be hardly useful at all.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Brian Fox <br...@infinity.nu>.
On Fri, Sep 25, 2009 at 12:44 PM, Albert Kurucz <al...@gmail.com> wrote:
> Technically it is possible to manage 3 different OSS Maven repos.
>
> 1. The good enough
> This is the current "Maven Central"
> No rules, only "recommendations":
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> Note: it is not a rule what is not enforced!
For what purpose? Again this is effectively a dead repo.
>
> 2. The good
> This would be the Maven Purgatory.
> Same rules applied as above, but rules enforced.
> Mistakes of rule-enforcements corrected by purge.
>
Or this is the new data in Central.
> 3. The best
> Call it the Maven Heaven
> Same rules, but only for Maven built projects.
>
Pretty much useless. The tool used to build is completely irrelevant.
Such a repo would be so barren as to be hardly useful at all.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
Technically it is possible to manage 3 different OSS Maven repos.
1. The good enough
This is the current "Maven Central"
No rules, only "recommendations":
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
Note: it is not a rule what is not enforced!
2. The good
This would be the Maven Purgatory.
Same rules applied as above, but rules enforced.
Mistakes of rule-enforcements corrected by purge.
3. The best
Call it the Maven Heaven
Same rules, but only for Maven built projects.
Good dream, friends!
On Fri, Sep 25, 2009 at 12:18 PM, Stephen Connolly
<st...@gmail.com> wrote:
> 2009/9/25 Hervé BOUTEMY <he...@free.fr>:
>> Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
>>> 2009/9/25 Albert Kurucz <al...@gmail.com>:
>>> > The pure Maven repo should say:
>>> > We honestly don't care which Maven plugin the people build with, as
>>> > long as that plugin is already checked into here.
>>> >
>>> > And why people would prefer to use libraries from the pure Maven repo?
>>> > Quality.
>>> >
>>> > Being build-able has always been the target of OSS developments.
>>> > Finally this could be achieved.
>>> > (OK it won't come to Maven Central)
>>> >
>>> > Anyone care about having Maven Pure?
>>>
>>> Not me. Central is good enough if we add deprecation metadata,
>> +1
>>
>>> version comparison metadata,
>> -0: need to discuss more on this IMHO (on the dev list probably)
>
> +1 to discussing more. I'll start a thread with my thoughts next week
>
>>
>>> and if we fix a few small issues with the
>>> pom xsd.
>> need eplanations on this one
>>
>> Hervé
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Stephen Connolly <st...@gmail.com>.
2009/9/25 Hervé BOUTEMY <he...@free.fr>:
> Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
>> 2009/9/25 Albert Kurucz <al...@gmail.com>:
>> > The pure Maven repo should say:
>> > We honestly don't care which Maven plugin the people build with, as
>> > long as that plugin is already checked into here.
>> >
>> > And why people would prefer to use libraries from the pure Maven repo?
>> > Quality.
>> >
>> > Being build-able has always been the target of OSS developments.
>> > Finally this could be achieved.
>> > (OK it won't come to Maven Central)
>> >
>> > Anyone care about having Maven Pure?
>>
>> Not me. Central is good enough if we add deprecation metadata,
> +1
>
>> version comparison metadata,
> -0: need to discuss more on this IMHO (on the dev list probably)
+1 to discussing more. I'll start a thread with my thoughts next week
>
>> and if we fix a few small issues with the
>> pom xsd.
> need eplanations on this one
>
> Hervé
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Hervé BOUTEMY <he...@free.fr>.
Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
> 2009/9/25 Albert Kurucz <al...@gmail.com>:
> > The pure Maven repo should say:
> > We honestly don't care which Maven plugin the people build with, as
> > long as that plugin is already checked into here.
> >
> > And why people would prefer to use libraries from the pure Maven repo?
> > Quality.
> >
> > Being build-able has always been the target of OSS developments.
> > Finally this could be achieved.
> > (OK it won't come to Maven Central)
> >
> > Anyone care about having Maven Pure?
>
> Not me. Central is good enough if we add deprecation metadata,
+1
> version comparison metadata,
-0: need to discuss more on this IMHO (on the dev list probably)
> and if we fix a few small issues with the
> pom xsd.
need eplanations on this one
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Stephen Connolly <st...@gmail.com>.
2009/9/25 Albert Kurucz <al...@gmail.com>:
> The pure Maven repo should say:
> We honestly don't care which Maven plugin the people build with, as
> long as that plugin is already checked into here.
>
> And why people would prefer to use libraries from the pure Maven repo?
> Quality.
>
> Being build-able has always been the target of OSS developments.
> Finally this could be achieved.
> (OK it won't come to Maven Central)
>
> Anyone care about having Maven Pure?
>
Not me. Central is good enough if we add deprecation metadata,
version comparison metadata, and if we fix a few small issues with the
pom xsd.
> On Fri, Sep 25, 2009 at 8:36 AM, Albert Kurucz <al...@gmail.com> wrote:
>> "We just need a high-quality POM, correct metadata, javadocs, sources,
>> and signatures."
>> It is debatable is what you mean on high quality.
>>
>> For me (totally a Maven fan!) what makes the POM high quality?
>> Its ability to build the project!
>> I don't really care if it is full of maven-antrun-plugin, but build it
>> by running mvn ...
>>
>> For some developers high quality really just means that the metadata is correct.
>>
>> Because of this opposition having two separate OSS repos (serving
>> different needs?) makes sense.
>>
>> What is the right thing to do going forward?
>> One question is whether to care about build ability or not!
>>
>>
>> On Thu, Sep 24, 2009 at 10:56 PM, Jason van Zyl <jv...@sonatype.com> wrote:
>>>
>>> On 2009-09-24, at 7:52 PM, Albert Kurucz wrote:
>>>
>>>> Jason and Brian, thanks for the explanations.
>>>> Understood, the policy of not removing anything from Maven Central
>>>> serves a purpose.
>>>>
>>>> I wish there would be another publicly Maven repository, which is
>>>> maintained with rules enforced. This repo could even have a rule
>>>> (additional to the old and unenforced rules) that only Maven built
>>>> projects can enter, maybe even more restriction: only the designated
>>>> Continuous Integration server can upload to it.
>>>
>>> What matters is a plan to improve the metadata and this can be done over
>>> time. There can never be a big bang here, there is just too much content,
>>> and too many people relying on the content that's there. Projects that are
>>> deploying against oss.sonatype.org are subject to the procurement rules
>>> which are stringent. The artifacts are placed in a staging repository, rules
>>> are applied and if they all pass they get promoted otherwise they have to be
>>> corrected. No promotion unless all the rules pass.
>>>
>>> Only allowing Maven built projects doesn't make sense. All we need it the
>>> correct information. We honestly don't care if people build with Maven or
>>> not. We just need a high-quality POM, correct metadata, javadocs, sources,
>>> and signatures.
>>>
>>>> This pure Maven repo would not be able to compete with Maven Central
>>>> regarding size or the number of artifacts, but some OSS developers
>>>> might prefer to use from and supply to this one instead of the big and
>>>> ugly.
>>>
>>> This isn't really going to change or help anything. The existing content
>>> cannot change, the content going forward needs to be improved and that's
>>> what matters. Over time as the content improves the poorer quality
>>> submissions will just fall into disuse.
>>>
>>> Nexus can now help any project that wants to deploy high quality artifacts
>>> via oss.sonatype.org. The next step for us is allowing bundle submissions
>>> that are normally pushed into JIRA to be also submitted into a staging
>>> repository and run through the same set of rules. This will be available in
>>> Nexus 1.4. The last gap to fill will be repositories that directly sync and
>>> we'll provide a mechanism for that in Nexus as well. Ultimately we will
>>> build up these rules and if you don't pass them, by whatever gate you pass
>>> through, then your artifacts get rejected. We'll provide this in an easy to
>>> use form with Nexus but ultimately it doesn't matter how these rules are
>>> enforced as long as they are enforced. This is the only strategy that will
>>> work long-term.
>>>
>>> What's done has been done. What matters now helping projects do the right
>>> thing going forward.
>>>
>>>>
>>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu> wrote:
>>>>>
>>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <al...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Requirements for the POMs are defined as:
>>>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>>>> I call the artifact corrupt (regarding Maven Central Compliance) if
>>>>>> the POM of the artifact does not fulfills the above requirements.
>>>>>> There are corrupt ones have made it to the Central, because the guard
>>>>>> was sleeping.
>>>>>>
>>>>>
>>>>> Correct, but changing them is not an option because it will
>>>>> destabilize builds. This is a long standing rule that we do not remove
>>>>> or change the contents of central.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
The pure Maven repo should say:
We honestly don't care which Maven plugin the people build with, as
long as that plugin is already checked into here.
And why people would prefer to use libraries from the pure Maven repo?
Quality.
Being build-able has always been the target of OSS developments.
Finally this could be achieved.
(OK it won't come to Maven Central)
Anyone care about having Maven Pure?
On Fri, Sep 25, 2009 at 8:36 AM, Albert Kurucz <al...@gmail.com> wrote:
> "We just need a high-quality POM, correct metadata, javadocs, sources,
> and signatures."
> It is debatable is what you mean on high quality.
>
> For me (totally a Maven fan!) what makes the POM high quality?
> Its ability to build the project!
> I don't really care if it is full of maven-antrun-plugin, but build it
> by running mvn ...
>
> For some developers high quality really just means that the metadata is correct.
>
> Because of this opposition having two separate OSS repos (serving
> different needs?) makes sense.
>
> What is the right thing to do going forward?
> One question is whether to care about build ability or not!
>
>
> On Thu, Sep 24, 2009 at 10:56 PM, Jason van Zyl <jv...@sonatype.com> wrote:
>>
>> On 2009-09-24, at 7:52 PM, Albert Kurucz wrote:
>>
>>> Jason and Brian, thanks for the explanations.
>>> Understood, the policy of not removing anything from Maven Central
>>> serves a purpose.
>>>
>>> I wish there would be another publicly Maven repository, which is
>>> maintained with rules enforced. This repo could even have a rule
>>> (additional to the old and unenforced rules) that only Maven built
>>> projects can enter, maybe even more restriction: only the designated
>>> Continuous Integration server can upload to it.
>>
>> What matters is a plan to improve the metadata and this can be done over
>> time. There can never be a big bang here, there is just too much content,
>> and too many people relying on the content that's there. Projects that are
>> deploying against oss.sonatype.org are subject to the procurement rules
>> which are stringent. The artifacts are placed in a staging repository, rules
>> are applied and if they all pass they get promoted otherwise they have to be
>> corrected. No promotion unless all the rules pass.
>>
>> Only allowing Maven built projects doesn't make sense. All we need it the
>> correct information. We honestly don't care if people build with Maven or
>> not. We just need a high-quality POM, correct metadata, javadocs, sources,
>> and signatures.
>>
>>> This pure Maven repo would not be able to compete with Maven Central
>>> regarding size or the number of artifacts, but some OSS developers
>>> might prefer to use from and supply to this one instead of the big and
>>> ugly.
>>
>> This isn't really going to change or help anything. The existing content
>> cannot change, the content going forward needs to be improved and that's
>> what matters. Over time as the content improves the poorer quality
>> submissions will just fall into disuse.
>>
>> Nexus can now help any project that wants to deploy high quality artifacts
>> via oss.sonatype.org. The next step for us is allowing bundle submissions
>> that are normally pushed into JIRA to be also submitted into a staging
>> repository and run through the same set of rules. This will be available in
>> Nexus 1.4. The last gap to fill will be repositories that directly sync and
>> we'll provide a mechanism for that in Nexus as well. Ultimately we will
>> build up these rules and if you don't pass them, by whatever gate you pass
>> through, then your artifacts get rejected. We'll provide this in an easy to
>> use form with Nexus but ultimately it doesn't matter how these rules are
>> enforced as long as they are enforced. This is the only strategy that will
>> work long-term.
>>
>> What's done has been done. What matters now helping projects do the right
>> thing going forward.
>>
>>>
>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu> wrote:
>>>>
>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <al...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Requirements for the POMs are defined as:
>>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>>> I call the artifact corrupt (regarding Maven Central Compliance) if
>>>>> the POM of the artifact does not fulfills the above requirements.
>>>>> There are corrupt ones have made it to the Central, because the guard
>>>>> was sleeping.
>>>>>
>>>>
>>>> Correct, but changing them is not an option because it will
>>>> destabilize builds. This is a long standing rule that we do not remove
>>>> or change the contents of central.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Stephen Connolly <st...@gmail.com>.
For me,
High quality is that:
/project/(?parent/)(groupId|artifactId|version) are valid and do not
reference properties
/project/dependencies is valid and if there are any properties defined
they are defined within the pom or it's parents
/project/name
/project/description
/project/url
Bonus high quality is when it has
/project/scm
/project/issueTracking
/project/developers
/project/contributors
and if it is a project that builds using Maven 2
-Stephen
2009/9/25 Albert Kurucz <al...@gmail.com>:
> "We just need a high-quality POM, correct metadata, javadocs, sources,
> and signatures."
> It is debatable is what you mean on high quality.
>
> For me (totally a Maven fan!) what makes the POM high quality?
> Its ability to build the project!
> I don't really care if it is full of maven-antrun-plugin, but build it
> by running mvn ...
>
> For some developers high quality really just means that the metadata is correct.
>
> Because of this opposition having two separate OSS repos (serving
> different needs?) makes sense.
>
> What is the right thing to do going forward?
> One question is whether to care about build ability or not!
>
>
> On Thu, Sep 24, 2009 at 10:56 PM, Jason van Zyl <jv...@sonatype.com> wrote:
>>
>> On 2009-09-24, at 7:52 PM, Albert Kurucz wrote:
>>
>>> Jason and Brian, thanks for the explanations.
>>> Understood, the policy of not removing anything from Maven Central
>>> serves a purpose.
>>>
>>> I wish there would be another publicly Maven repository, which is
>>> maintained with rules enforced. This repo could even have a rule
>>> (additional to the old and unenforced rules) that only Maven built
>>> projects can enter, maybe even more restriction: only the designated
>>> Continuous Integration server can upload to it.
>>
>> What matters is a plan to improve the metadata and this can be done over
>> time. There can never be a big bang here, there is just too much content,
>> and too many people relying on the content that's there. Projects that are
>> deploying against oss.sonatype.org are subject to the procurement rules
>> which are stringent. The artifacts are placed in a staging repository, rules
>> are applied and if they all pass they get promoted otherwise they have to be
>> corrected. No promotion unless all the rules pass.
>>
>> Only allowing Maven built projects doesn't make sense. All we need it the
>> correct information. We honestly don't care if people build with Maven or
>> not. We just need a high-quality POM, correct metadata, javadocs, sources,
>> and signatures.
>>
>>> This pure Maven repo would not be able to compete with Maven Central
>>> regarding size or the number of artifacts, but some OSS developers
>>> might prefer to use from and supply to this one instead of the big and
>>> ugly.
>>
>> This isn't really going to change or help anything. The existing content
>> cannot change, the content going forward needs to be improved and that's
>> what matters. Over time as the content improves the poorer quality
>> submissions will just fall into disuse.
>>
>> Nexus can now help any project that wants to deploy high quality artifacts
>> via oss.sonatype.org. The next step for us is allowing bundle submissions
>> that are normally pushed into JIRA to be also submitted into a staging
>> repository and run through the same set of rules. This will be available in
>> Nexus 1.4. The last gap to fill will be repositories that directly sync and
>> we'll provide a mechanism for that in Nexus as well. Ultimately we will
>> build up these rules and if you don't pass them, by whatever gate you pass
>> through, then your artifacts get rejected. We'll provide this in an easy to
>> use form with Nexus but ultimately it doesn't matter how these rules are
>> enforced as long as they are enforced. This is the only strategy that will
>> work long-term.
>>
>> What's done has been done. What matters now helping projects do the right
>> thing going forward.
>>
>>>
>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu> wrote:
>>>>
>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <al...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Requirements for the POMs are defined as:
>>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>>> I call the artifact corrupt (regarding Maven Central Compliance) if
>>>>> the POM of the artifact does not fulfills the above requirements.
>>>>> There are corrupt ones have made it to the Central, because the guard
>>>>> was sleeping.
>>>>>
>>>>
>>>> Correct, but changing them is not an option because it will
>>>> destabilize builds. This is a long standing rule that we do not remove
>>>> or change the contents of central.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>
>> Thanks,
>>
>> Jason
>>
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
"We just need a high-quality POM, correct metadata, javadocs, sources,
and signatures."
It is debatable is what you mean on high quality.
For me (totally a Maven fan!) what makes the POM high quality?
Its ability to build the project!
I don't really care if it is full of maven-antrun-plugin, but build it
by running mvn ...
For some developers high quality really just means that the metadata is correct.
Because of this opposition having two separate OSS repos (serving
different needs?) makes sense.
What is the right thing to do going forward?
One question is whether to care about build ability or not!
On Thu, Sep 24, 2009 at 10:56 PM, Jason van Zyl <jv...@sonatype.com> wrote:
>
> On 2009-09-24, at 7:52 PM, Albert Kurucz wrote:
>
>> Jason and Brian, thanks for the explanations.
>> Understood, the policy of not removing anything from Maven Central
>> serves a purpose.
>>
>> I wish there would be another publicly Maven repository, which is
>> maintained with rules enforced. This repo could even have a rule
>> (additional to the old and unenforced rules) that only Maven built
>> projects can enter, maybe even more restriction: only the designated
>> Continuous Integration server can upload to it.
>
> What matters is a plan to improve the metadata and this can be done over
> time. There can never be a big bang here, there is just too much content,
> and too many people relying on the content that's there. Projects that are
> deploying against oss.sonatype.org are subject to the procurement rules
> which are stringent. The artifacts are placed in a staging repository, rules
> are applied and if they all pass they get promoted otherwise they have to be
> corrected. No promotion unless all the rules pass.
>
> Only allowing Maven built projects doesn't make sense. All we need it the
> correct information. We honestly don't care if people build with Maven or
> not. We just need a high-quality POM, correct metadata, javadocs, sources,
> and signatures.
>
>> This pure Maven repo would not be able to compete with Maven Central
>> regarding size or the number of artifacts, but some OSS developers
>> might prefer to use from and supply to this one instead of the big and
>> ugly.
>
> This isn't really going to change or help anything. The existing content
> cannot change, the content going forward needs to be improved and that's
> what matters. Over time as the content improves the poorer quality
> submissions will just fall into disuse.
>
> Nexus can now help any project that wants to deploy high quality artifacts
> via oss.sonatype.org. The next step for us is allowing bundle submissions
> that are normally pushed into JIRA to be also submitted into a staging
> repository and run through the same set of rules. This will be available in
> Nexus 1.4. The last gap to fill will be repositories that directly sync and
> we'll provide a mechanism for that in Nexus as well. Ultimately we will
> build up these rules and if you don't pass them, by whatever gate you pass
> through, then your artifacts get rejected. We'll provide this in an easy to
> use form with Nexus but ultimately it doesn't matter how these rules are
> enforced as long as they are enforced. This is the only strategy that will
> work long-term.
>
> What's done has been done. What matters now helping projects do the right
> thing going forward.
>
>>
>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu> wrote:
>>>
>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <al...@gmail.com>
>>> wrote:
>>>>
>>>> Requirements for the POMs are defined as:
>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>> I call the artifact corrupt (regarding Maven Central Compliance) if
>>>> the POM of the artifact does not fulfills the above requirements.
>>>> There are corrupt ones have made it to the Central, because the guard
>>>> was sleeping.
>>>>
>>>
>>> Correct, but changing them is not an option because it will
>>> destabilize builds. This is a long standing rule that we do not remove
>>> or change the contents of central.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Jason van Zyl <jv...@sonatype.com>.
On 2009-09-24, at 7:52 PM, Albert Kurucz wrote:
> Jason and Brian, thanks for the explanations.
> Understood, the policy of not removing anything from Maven Central
> serves a purpose.
>
> I wish there would be another publicly Maven repository, which is
> maintained with rules enforced. This repo could even have a rule
> (additional to the old and unenforced rules) that only Maven built
> projects can enter, maybe even more restriction: only the designated
> Continuous Integration server can upload to it.
What matters is a plan to improve the metadata and this can be done
over time. There can never be a big bang here, there is just too much
content, and too many people relying on the content that's there.
Projects that are deploying against oss.sonatype.org are subject to
the procurement rules which are stringent. The artifacts are placed in
a staging repository, rules are applied and if they all pass they get
promoted otherwise they have to be corrected. No promotion unless all
the rules pass.
Only allowing Maven built projects doesn't make sense. All we need it
the correct information. We honestly don't care if people build with
Maven or not. We just need a high-quality POM, correct metadata,
javadocs, sources, and signatures.
> This pure Maven repo would not be able to compete with Maven Central
> regarding size or the number of artifacts, but some OSS developers
> might prefer to use from and supply to this one instead of the big and
> ugly.
This isn't really going to change or help anything. The existing
content cannot change, the content going forward needs to be improved
and that's what matters. Over time as the content improves the poorer
quality submissions will just fall into disuse.
Nexus can now help any project that wants to deploy high quality
artifacts via oss.sonatype.org. The next step for us is allowing
bundle submissions that are normally pushed into JIRA to be also
submitted into a staging repository and run through the same set of
rules. This will be available in Nexus 1.4. The last gap to fill will
be repositories that directly sync and we'll provide a mechanism for
that in Nexus as well. Ultimately we will build up these rules and if
you don't pass them, by whatever gate you pass through, then your
artifacts get rejected. We'll provide this in an easy to use form with
Nexus but ultimately it doesn't matter how these rules are enforced as
long as they are enforced. This is the only strategy that will work
long-term.
What's done has been done. What matters now helping projects do the
right thing going forward.
>
> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu> wrote:
>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <albert.kurucz@gmail.com
>> > wrote:
>>> Requirements for the POMs are defined as:
>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>> I call the artifact corrupt (regarding Maven Central Compliance) if
>>> the POM of the artifact does not fulfills the above requirements.
>>> There are corrupt ones have made it to the Central, because the
>>> guard
>>> was sleeping.
>>>
>>
>> Correct, but changing them is not an option because it will
>> destabilize builds. This is a long standing rule that we do not
>> remove
>> or change the contents of central.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: a cleaned up central repository? (was: Maven Central Repository -
Cleanup Efforts)
Posted by Brian Fox <br...@infinity.nu>.
On Thu, Oct 1, 2009 at 2:24 PM, Albert Kurucz <al...@gmail.com> wrote:
> Wayne, Who paid Linus to create version 1.0 of the Linux Kernel?
> If somebody can create a Maven repo crawler as a hobby project, then
> somebody will.
The Nexus Indexer already runs on Central, directly on the machine.
Crawling the repository will get you banned in no time, I
unfortunately have to do this all the time as the bandwidth is
certainly not free.
See the other thread for how you can help us improve the data, and
lets keep the discussion there.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository? (was: Maven Central Repository -
Cleanup Efforts)
Posted by Albert Kurucz <al...@gmail.com>.
Wayne, Who paid Linus to create version 1.0 of the Linux Kernel?
If somebody can create a Maven repo crawler as a hobby project, then
somebody will.
The first Cert List will probably be just the result of some simple
tests, not much.
But many will follow. We will have to protect somehow our bandwidth very soon!
On Thu, Oct 1, 2009 at 4:08 PM, Wayne Fay <wa...@gmail.com> wrote:
>> I have proposed in the original thread a solution, based on multiple
>> index files, which index files would represent the output of CAs. If I
>> configure in my Maven settings file (by URL) which index file I want
>> to use, my Maven should be blind to any other artifacts on the repo.
>> Allowing AND and OR operations on this cert lists would be a bonus.
>
> Who exactly is setting up, managing, and paying for the ongoing
> operation of these CAs? You didn't address this in the original
> thread, and right now I'm not aware of any existing organizations that
> would fill this void. Especially not for free.
>
> Without address that aspect, the rest of the discussion is not worth much IMO.
>
> Wayne
>
> ---------------------------------------------------------------------
> 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
Re: a cleaned up central repository? (was: Maven Central Repository -
Cleanup Efforts)
Posted by Wayne Fay <wa...@gmail.com>.
> I have proposed in the original thread a solution, based on multiple
> index files, which index files would represent the output of CAs. If I
> configure in my Maven settings file (by URL) which index file I want
> to use, my Maven should be blind to any other artifacts on the repo.
> Allowing AND and OR operations on this cert lists would be a bonus.
Who exactly is setting up, managing, and paying for the ongoing
operation of these CAs? You didn't address this in the original
thread, and right now I'm not aware of any existing organizations that
would fill this void. Especially not for free.
Without address that aspect, the rest of the discussion is not worth much IMO.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository? (was: Maven Central Repository -
Cleanup Efforts)
Posted by Albert Kurucz <al...@gmail.com>.
> 1) defined rules for what an "acceptable" artifact is
> 2) gating central with those rules
Any time when I referred to
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
as a requirement, I always had a bad feeling.
Why? Requirement is what you can verify against, but this mini howto
is not a requirement then. Rules need to be defined in software. Could
someone write a unit test?
> 3) extensible repository metadata support in Maven (this keeps coming up for
> a variety of reasons)
Extending metadata is good as long as creating/using that metadata is
optional, like at #5.
> 4) the ability to revise metadata without impacting historical builds (SCMs
> move, people make mistakes with dependency scopes, we need to rewrite
> locations, deprecation, rules for "acceptable" change, etc).
Going back in history of multiple projects cannot be done reliable
based on SCMs.
It could be done only if attached sources are full and buildable.
This would make the repo a kind of SCM: diff only between releases,
details hidden, but OK.
> 5) a way to identify all the artifacts that are marked "acceptable" to have
> a cleaner build
How do you mark "acceptable" when it is not always means the same for everyone?
I have proposed in the original thread a solution, based on multiple
index files, which index files would represent the output of CAs. If I
configure in my Maven settings file (by URL) which index file I want
to use, my Maven should be blind to any other artifacts on the repo.
Allowing AND and OR operations on this cert lists would be a bonus.
It is interesting, that the Central itself could store these (cert
list) index files packaged in artifacts. Some index files should be
for the public some for limited use. As a client of Central give me a
choice which one I sign up to. Acceptance criteria cannot be the same
for everyone.
On Wed, Sep 30, 2009 at 12:20 AM, Brett Porter <br...@apache.org> wrote:
> Ok, I did a poor job of expressing what I was getting at.
>
> On 25/09/2009, at 2:02 PM, Jason van Zyl wrote:
>
>>
>> What's matters is improvement of the process going forward.
>
> Agreed, I see that as a pre-requisite.
>
>> As people move forward with improved submissions from projects then the
>> older submissions of dubious quality will naturally fall out of use.
>
> That may not happen in any sort of feasible timeframe. There is some very
> old stuff out there that isn't getting new releases in a hurry. As you
> traverse a dependency tree, it's nearly impossible not to hit the rough
> spots like early commons-logging releases, velocity vs velocity-dep,
> plexus:plexus-utils vs org.codehaus.plexus:plexus-utils and so on.
>
> On 25/09/2009, at 2:11 PM, Brian Fox wrote:
>
>> Who would _want_ to deploy their stuff
>> to the "old" repo? No one. The hurdle to get to the new repo would be
>> the same as putting the checks on the current repo for all new
>> artifacts.
>
> I agree - I'm not saying we allow anyone to deploy to the "old" one - but it
> would be nice to have a way in Maven to say "only use stuff that meets the
> criteria", and let that drive further clean up efforts.
>
> Maybe it's not a separate repository, but just a trigger to only accept
> artifacts "marked" in some way.
>
> But I don't think just doing new stuff is enough - we need a way to reliably
> correct existing artifacts, and prepare for the future when the bar moves
> again.
>
> This is the steps I saw towards it:
> 1) defined rules for what an "acceptable" artifact is
> 2) gating central with those rules
> 3) extensible repository metadata support in Maven (this keeps coming up for
> a variety of reasons)
> 4) the ability to revise metadata without impacting historical builds (SCMs
> move, people make mistakes with dependency scopes, we need to rewrite
> locations, deprecation, rules for "acceptable" change, etc).
> 5) a way to identify all the artifacts that are marked "acceptable" to have
> a cleaner build
>
> Does that make any sense?
>
> - Brett
>
> ---------------------------------------------------------------------
> 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
Re: a cleaned up central repository? (was: Maven Central Repository - Cleanup Efforts)
Posted by Brett Porter <br...@apache.org>.
Ok, I did a poor job of expressing what I was getting at.
On 25/09/2009, at 2:02 PM, Jason van Zyl wrote:
>
> What's matters is improvement of the process going forward.
Agreed, I see that as a pre-requisite.
> As people move forward with improved submissions from projects then
> the older submissions of dubious quality will naturally fall out of
> use.
That may not happen in any sort of feasible timeframe. There is some
very old stuff out there that isn't getting new releases in a hurry.
As you traverse a dependency tree, it's nearly impossible not to hit
the rough spots like early commons-logging releases, velocity vs
velocity-dep, plexus:plexus-utils vs org.codehaus.plexus:plexus-utils
and so on.
On 25/09/2009, at 2:11 PM, Brian Fox wrote:
> Who would _want_ to deploy their stuff
> to the "old" repo? No one. The hurdle to get to the new repo would be
> the same as putting the checks on the current repo for all new
> artifacts.
I agree - I'm not saying we allow anyone to deploy to the "old" one -
but it would be nice to have a way in Maven to say "only use stuff
that meets the criteria", and let that drive further clean up efforts.
Maybe it's not a separate repository, but just a trigger to only
accept artifacts "marked" in some way.
But I don't think just doing new stuff is enough - we need a way to
reliably correct existing artifacts, and prepare for the future when
the bar moves again.
This is the steps I saw towards it:
1) defined rules for what an "acceptable" artifact is
2) gating central with those rules
3) extensible repository metadata support in Maven (this keeps coming
up for a variety of reasons)
4) the ability to revise metadata without impacting historical builds
(SCMs move, people make mistakes with dependency scopes, we need to
rewrite locations, deprecation, rules for "acceptable" change, etc).
5) a way to identify all the artifacts that are marked "acceptable" to
have a cleaner build
Does that make any sense?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository? (was: Maven Central Repository - Cleanup Efforts)
Posted by Jason van Zyl <jv...@sonatype.com>.
On 2009-09-24, at 8:37 PM, Brett Porter wrote:
> Moving over to dev...
>
> So here's a thought - why don't we create a "new" central repository?
>
> - a new repository with strict acceptance rules regarding POMs,
> signatures, ownership, etc.
> - if there's a new metadata format needed (recently discussed), this
> would use it
> - validated artifacts could be moved over and requests to the old
> rewritten (in the same way we maintained the maven1 repo)
> - default Maven can ship with both repositories enabled, but a "best
> practice" would be to turn old central off (or better, use a
> repository manager that doesn't access it / only access it for
> acceptable artifacts)
>
> The main issue is finding a way to overcome confusion when an
> artifact is changed - you want "old" builds to keep using the same
> one it always did, but new builds to use the new one (and cope with
> potential revision of metadata without breaking builds). This is the
> sort of thing that could be built into Maven in a new version and
> the new repo format only accessible from that version.
>
> Thoughts?
>
What's matters is improvement of the process going forward. As people
move forward with improved submissions from projects then the older
submissions of dubious quality will naturally fall out of use.
Improving the process and helping projects do the right thing is
necessary. Creating another repository isn't really going change the
reality that people are going to use a mixture of old and new
submissions over a long period of time. You can't just up and change
the old content because people depend on it, and you can't just make a
rift between the old and new.
In much the same way we just have to deal with the shit that exists in
Maven 2.x and make it work in Maven 3.x we have to deal with the shit
in the repository and make it work with newer submissions that we
consciously try to improve.
> Cheers,
> Brett
>
> On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
>
>> Jason and Brian, thanks for the explanations.
>> Understood, the policy of not removing anything from Maven Central
>> serves a purpose.
>>
>> I wish there would be another publicly Maven repository, which is
>> maintained with rules enforced. This repo could even have a rule
>> (additional to the old and unenforced rules) that only Maven built
>> projects can enter, maybe even more restriction: only the designated
>> Continuous Integration server can upload to it.
>> This pure Maven repo would not be able to compete with Maven Central
>> regarding size or the number of artifacts, but some OSS developers
>> might prefer to use from and supply to this one instead of the big
>> and
>> ugly.
>>
>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu>
>> wrote:
>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <albert.kurucz@gmail.com
>>> > wrote:
>>>> Requirements for the POMs are defined as:
>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>> I call the artifact corrupt (regarding Maven Central Compliance) if
>>>> the POM of the artifact does not fulfills the above requirements.
>>>> There are corrupt ones have made it to the Central, because the
>>>> guard
>>>> was sleeping.
>>>>
>>>
>>> Correct, but changing them is not an option because it will
>>> destabilize builds. This is a long standing rule that we do not
>>> remove
>>> or change the contents of central.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
My vote is on Option2:
http://xircles.codehaus.org/projects/pinin
On Thu, Oct 1, 2009 at 2:43 PM, Albert Kurucz <al...@gmail.com> wrote:
> Isn't that funny:
> http://ask.metafilter.com/68789/Why-do-rotten-onions-smell-good
>
>
> On Thu, Oct 1, 2009 at 2:13 PM, Albert Kurucz <al...@gmail.com> wrote:
>> I would like to see some votes:
>>
>> 1. Big Rotten Onion
>> 2. Starting Over After Writing New Policies
>>
>> On Thu, Oct 1, 2009 at 2:04 PM, Albert Kurucz <al...@gmail.com> wrote:
>>> You know where Option1 will drive us?
>>> When the added metadata which hides current corruption will become
>>> corrupt, we need another layer.
>>> At the end, it will look like a big onion. :)
>>>
>>> Where will Option2 will get us?
>>> The new repo will get corrupted again.
>>> Unless the policy of repo-ing something will get rewritten, like this:
>>> only source code can be uploaded in packages to a public repo.
>>> Compile can only take place locally when you are checking out
>>> something or after (lazy checkout).
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
Changing the rules is OK. Not publishing the change of rules
(policies) is not OK, because it is like getting "undocumented
features" to the system. We cannot talk about "broken" until we define
good, and I believed once it was defined. If you redefined good,
please publish it.
On Mon, Oct 5, 2009 at 7:28 PM, Brian Fox <br...@infinity.nu> wrote:
> On Mon, Oct 5, 2009 at 4:36 PM, Albert Kurucz <al...@gmail.com> wrote:
>> Brian,
>>
>> If you start maintaining a list of violators I have zero motivation to
>> contribute to your list, because this kind of list is useless for me.
>> If you start maintaining a list of compliant artifacts (what many
>> still believe Central is) that is a totally different case.
>
> Again, this list is meant to provide examples of what you think is
> broken, but i'm not particularly interested in listing all the poms
> missing the things like description, etc. Rather I think identifying
> totally bad poms, broken checksums, bad dependencies is a more useful
> place to start.
>
> ---------------------------------------------------------------------
> 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
Re: a cleaned up central repository?
Posted by Brian Fox <br...@infinity.nu>.
On Mon, Oct 5, 2009 at 4:36 PM, Albert Kurucz <al...@gmail.com> wrote:
> Brian,
>
> If you start maintaining a list of violators I have zero motivation to
> contribute to your list, because this kind of list is useless for me.
> If you start maintaining a list of compliant artifacts (what many
> still believe Central is) that is a totally different case.
Again, this list is meant to provide examples of what you think is
broken, but i'm not particularly interested in listing all the poms
missing the things like description, etc. Rather I think identifying
totally bad poms, broken checksums, bad dependencies is a more useful
place to start.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
Brian,
If you start maintaining a list of violators I have zero motivation to
contribute to your list, because this kind of list is useless for me.
If you start maintaining a list of compliant artifacts (what many
still believe Central is) that is a totally different case.
On Mon, Oct 5, 2009 at 2:16 PM, Albert Kurucz <al...@gmail.com> wrote:
> Brian,
>
>> Ok then, I assert they are all fine. Now you can provide a list and
>> refute me ;-).
> In this case (if they were all fine) here is your list:
> http://repo2.maven.org/maven2/.index/
> (But unfortunately they are not all fine.)
>
>> Seriously, the definition of "broken" depends on the observer.
> True. This is why maybe there should be different "Good lists" and
> users should be allowed to choose, depending on their taste.
>
>> Before we can
>> "fix" anything "broken" we need to start by defining what you think is
>> broken and why.
>
> One of the possible Definitions of "Good list", which I would like
> call "Maven Central Compliance" is defined here:
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> If artifacts are on Central which are not on this list (which list
> should really be realized soon), I don't mind, as long as I could
> search or filter by this list.
> You cannot objectively define what is "broken" only if you specify
> which Lists you are talking about. Do you mean, the "Maven Central
> Compliance" list?
>
>
>
>
> On Mon, Oct 5, 2009 at 12:38 PM, Brian Fox <br...@infinity.nu> wrote:
>>>
>>> 2.
>>>> Provide a detailed list of artifacts and metadata you consider broken.
>>> I think this approach will not work.
>>> You should really work on providing list of artifacts which are not
>>> broken (Certified good list), and having a Maven client which is able
>>> to use this list (or multiple lists) for filtering and searching.
>>
>> Ok then, I assert they are all fine. Now you can provide a list and
>> refute me ;-).
>>
>> Seriously, the definition of "broken" depends on the observer. A pom
>> that doesn't mark something as optional only appears broken to users
>> who don't otherwise need that dependency for example. Before we can
>> "fix" anything "broken" we need to start by defining what you think is
>> broken and why.
>>
>>>
>>> 3.
>>>> When these artifacts are identified, work with the teams producing
>>>> these poms to educate them on the proper pom constructs to eliminate
>>>> them.
>>> If you have a list (or multiple lists which classify them by testing
>>> different qualities) of good artifacts, teams will try to deliver
>>> their artifacts to these lists by educating themselves.
>>> Trying to police these teams, you will just receive resistance.
>>
>> Not true from experience, again this is subject to the definition of broken.
>>
>>>
>>>
>>>
>>> Regards,
>>> Albert
>>>
>>>
>>>
>>>
>>> On Thu, Oct 1, 2009 at 6:51 PM, Brian Fox <br...@infinity.nu> wrote:
>>>> Albert,
>>>> Clearly you seem to have plenty of enthusiasm for helping to provide
>>>> better metadata, and I don't want to discourage that.
>>>>
>>>> Providing and hosting a repository containing 90 thousand files that
>>>> serves greater than 12TB of data a month is not as easy as you might
>>>> imagine. Starting over with a new repository is not the answer here.
>>>>
>>>> Getting 90k artifacts vetted and cleaned is a significant undertaking.
>>>> Frankly many of the artifacts in there are old, underused versions and
>>>> spending effort on those will have much less immediate impact than
>>>> stopping new artifacts getting in that have bad (or missing) data. We
>>>> have chosen to attack this problem by raising the barrier to entry for
>>>> new artifacts. This work started months ago and we'll be able to put
>>>> something in place in the next few weeks.
>>>>
>>>> This will be done in an automated fashion, starting with artifacts
>>>> that are uploaded manually. Then we will apply the same rules
>>>> (automatically) to anything coming in via rsync. Besides improving and
>>>> vetting the data coming in, this more automated process is designed at
>>>> drastically improving the turnaround time to get new artifacts and
>>>> sync's configured.
>>>>
>>>> If you really want to assist here, I can see several ways you
>>>> personally can assist this process:
>>>>
>>>> 1) Contribute _code_ that validates the various conditions you think
>>>> are important to validate. We already have an interface developed that
>>>> I can point you at if you're interested. These rules will help in many
>>>> ways because it will help check new artifacts, check old artifacts,
>>>> and allow people to use them with their repository manager internally
>>>> if they choose.
>>>>
>>>> 2) Provide a detailed list of artifacts and metadata you consider
>>>> broken. We can sit around and theorize about how things could be
>>>> better, but first having a concrete list of broken poms and other data
>>>> will help us focus on the most prominent problems first. The MEV
>>>> project in Jira is where we collect these. I don't care much if you
>>>> produce one jira or a jira with a huge list, it's the gathering of the
>>>> list that is most important.
>>>>
>>>> 3) When these artifacts are identified, work with the teams producing
>>>> these poms to educate them on the proper pom constructs to eliminate
>>>> them. Generally the teams don't produce bad data on purpose so some
>>>> education is required.
>>>>
>>>> 4) Assuming we have identified a significant number of the problems
>>>> from work done in #2, we would then need concrete proposals for how to
>>>> fix this without breaking people's builds. Proposals can be posted on
>>>> the MAVENUSER wiki space for futher discussion and refinement.
>>>>
>>>> 5) Assuming the proposals gather momentum, someone would need to code
>>>> the proposals
>>>>
>>>> 6) Then assistance would be needed to actually cleanup the metadata in
>>>> the context of the implementation.
>>>>
>>>> Things get done around here by people actually stepping in to get them
>>>> done. You're enthusiastic and we'd be glad to accept help in the areas
>>>> above. I think further theorizing at this point is going to get
>>>> diminishing returns, and I personally think attempting to fork an
>>>> entire repository is not going to help the users as much as even
>>>> items #1,2,3 above.
>>>>
>>>> Brian Fox
>>>> Apache Maven PMC Chair-Elect
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Oct 1, 2009 at 12:13 PM, Albert Kurucz <al...@gmail.com> wrote:
>>>>> I would like to see some votes:
>>>>>
>>>>> 1. Big Rotten Onion
>>>>> 2. Starting Over After Writing New Policies
>>>>>
>>>>> On Thu, Oct 1, 2009 at 2:04 PM, Albert Kurucz <al...@gmail.com> wrote:
>>>>>> You know where Option1 will drive us?
>>>>>> When the added metadata which hides current corruption will become
>>>>>> corrupt, we need another layer.
>>>>>> At the end, it will look like a big onion. :)
>>>>>>
>>>>>> Where will Option2 will get us?
>>>>>> The new repo will get corrupted again.
>>>>>> Unless the policy of repo-ing something will get rewritten, like this:
>>>>>> only source code can be uploaded in packages to a public repo.
>>>>>> Compile can only take place locally when you are checking out
>>>>>> something or after (lazy checkout).
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
Re: a cleaned up central repository?
Posted by Brett Porter <br...@apache.org>.
As fun as this discussion is, I think perhaps it has outlived not only
the subject line, but this list :)
- Brett
On 09/10/2009, at 2:32 AM, Albert Kurucz wrote:
> If you don't like the term metasoftware, why would you like the
> metadata?
> Data has software dependencies (or data dependencies) just like
> software.
> Data is software. More about this:
> http://www.dans.knaw.nl/nl/over_dans/factsheets/mixed_future_proof/
>
> If it looks like a duck...
>
> 2009/10/8 Tamás Cservenák <ta...@cservenak.net>:
>> Modello? Or any source/code generator?
>> :D
>>
>> ~t~
>>
>> On Thu, Oct 8, 2009 at 5:05 PM, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> wrote:
>>
>>> UML is a diagram about software
>>>
>>> 2009/10/8 Jörg Schaible <jo...@gmx.de>
>>>
>>>> Stephen Connolly wrote at Donnerstag, 8. Oktober 2009 15:56:
>>>>
>>>>> No because metasoftware would be software about software (which
>>>>> makes
>>> no
>>>>> sense)
>>>>
>>>> Actually it does, it's called UML :))
>>>>
>>>> - Jörg
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
If you don't like the term metasoftware, why would you like the metadata?
Data has software dependencies (or data dependencies) just like software.
Data is software. More about this:
http://www.dans.knaw.nl/nl/over_dans/factsheets/mixed_future_proof/
If it looks like a duck...
2009/10/8 Tamás Cservenák <ta...@cservenak.net>:
> Modello? Or any source/code generator?
> :D
>
> ~t~
>
> On Thu, Oct 8, 2009 at 5:05 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
>> UML is a diagram about software
>>
>> 2009/10/8 Jörg Schaible <jo...@gmx.de>
>>
>> > Stephen Connolly wrote at Donnerstag, 8. Oktober 2009 15:56:
>> >
>> > > No because metasoftware would be software about software (which makes
>> no
>> > > sense)
>> >
>> > Actually it does, it's called UML :))
>> >
>> > - Jörg
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
Re: a cleaned up central repository?
Posted by Tamás Cservenák <ta...@cservenak.net>.
Modello? Or any source/code generator?
:D
~t~
On Thu, Oct 8, 2009 at 5:05 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> UML is a diagram about software
>
> 2009/10/8 Jörg Schaible <jo...@gmx.de>
>
> > Stephen Connolly wrote at Donnerstag, 8. Oktober 2009 15:56:
> >
> > > No because metasoftware would be software about software (which makes
> no
> > > sense)
> >
> > Actually it does, it's called UML :))
> >
> > - Jörg
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: a cleaned up central repository?
Posted by Stephen Connolly <st...@gmail.com>.
UML is a diagram about software
2009/10/8 Jörg Schaible <jo...@gmx.de>
> Stephen Connolly wrote at Donnerstag, 8. Oktober 2009 15:56:
>
> > No because metasoftware would be software about software (which makes no
> > sense)
>
> Actually it does, it's called UML :))
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: a cleaned up central repository?
Posted by Jörg Schaible <jo...@gmx.de>.
Stephen Connolly wrote at Donnerstag, 8. Oktober 2009 15:56:
> No because metasoftware would be software about software (which makes no
> sense)
Actually it does, it's called UML :))
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Stephen Connolly <st...@gmail.com>.
No because metasoftware would be software about software (which makes no
sense)
2009/10/8 Albert Kurucz <al...@gmail.com>
> Should we call a software, which links to other software (has
> dependencies), metasoftware?
>
> 2009/10/7 Tamás Cservenák <ta...@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 <al...@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
> >>> <st...@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 <al...@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 <br...@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
>
>
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
Should we call a software, which links to other software (has
dependencies), metasoftware?
2009/10/7 Tamás Cservenák <ta...@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 <al...@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
>>> <st...@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 <al...@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 <br...@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
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
Steven,
It is absolute necessary to sit down and brainstorm.
Thanks for the ideas!
I mean it. :-)
On Tue, Oct 6, 2009 at 3:22 PM, Stephen Connolly
<st...@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 <al...@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
>> <st...@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 <al...@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 <br...@infinity.nu> wrote:
>>>>>
>>>>> On Tue, Oct 6, 2009 at 9:30 AM, Albert Kurucz <al...@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
Re: a cleaned up central repository?
Posted by Tamás Cservenák <ta...@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 <al...@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
>> <st...@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 <al...@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 <br...@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
>
>
Re: a cleaned up central repository?
Posted by Stephen Connolly <st...@gmail.com>.
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 <al...@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
> <st...@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 <al...@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 <br...@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
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
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
<st...@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 <al...@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 <br...@infinity.nu> wrote:
>>>
>>> On Tue, Oct 6, 2009 at 9:30 AM, Albert Kurucz <al...@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
Re: a cleaned up central repository?
Posted by Stephen Connolly <st...@gmail.com>.
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 <al...@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 <br...@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
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
Brian,
This is a Stalemate!
I go to sleep() until that code arrives to you.
If I had the time, I promise I would code it for you.
On Tue, Oct 6, 2009 at 12:30 PM, Albert Kurucz <al...@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 <br...@infinity.nu> wrote:
>> On Tue, Oct 6, 2009 at 9:30 AM, Albert Kurucz <al...@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
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
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 <br...@infinity.nu> wrote:
> On Tue, Oct 6, 2009 at 9:30 AM, Albert Kurucz <al...@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
Re: a cleaned up central repository?
Posted by Brian Fox <br...@infinity.nu>.
On Tue, Oct 6, 2009 at 9:30 AM, Albert Kurucz <al...@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
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
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.
2009/10/6 Tamás Cservenák <ta...@cservenak.net>:
> Not to mention that these below are "formal" requirements only. Their
> _presence_ is required, but nothing is said about their _content_.I can
> publish a POM that will _have_ dependencies section, but how do we know that
> the dependencies section is _correct_?
>
> Also: license in POM. What license "name" is allowed? Are they keyed by by
> license URL? Etc...
>
> Many of these are pretty hard to determine in "machine way"....
>
> ~t~
>
> On Tue, Oct 6, 2009 at 2:26 AM, Brian Fox <br...@infinity.nu> wrote:
>
>> On Mon, Oct 5, 2009 at 3:16 PM, Albert Kurucz <al...@gmail.com>
>> wrote:
>> > Brian,
>> >
>> >> Ok then, I assert they are all fine. Now you can provide a list and
>> >> refute me ;-).
>> > In this case (if they were all fine) here is your list:
>> > http://repo2.maven.org/maven2/.index/
>> > (But unfortunately they are not all fine.)
>> >
>> >> Seriously, the definition of "broken" depends on the observer.
>> > True. This is why maybe there should be different "Good lists" and
>> > users should be allowed to choose, depending on their taste.
>> >
>> >> Before we can
>> >> "fix" anything "broken" we need to start by defining what you think is
>> >> broken and why.
>> >
>> > One of the possible Definitions of "Good list", which I would like
>> > call "Maven Central Compliance" is defined here:
>> > http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>> > If artifacts are on Central which are not on this list (which list
>> > should really be realized soon), I don't mind, as long as I could
>> > search or filter by this list.
>> > You cannot objectively define what is "broken" only if you specify
>> > which Lists you are talking about. Do you mean, the "Maven Central
>> > Compliance" list?
>>
>> I assume you mean this list of requirements?
>> There are some requirements for the minimal information in the POMs
>> that are in the central repository. At least these must be present:
>>
>> modelVersion
>> groupId
>> artifactId
>> packaging
>> name
>> version
>> description
>> url
>> licenses
>> scm url
>> dependencies
>>
>> I don't think that I would consider things broken simply because the
>> name, description, url, scm url where missing. I would be annoyed but
>> not surprised if the license wasn't populated correctly. So if you're
>> saying you want to exclude everything from your build simply because
>> one of those are missing, then I think we fundamentally disagree. Yes
>> it would be nice if those were filled in properly but none of those
>> reduce the usefulness of users to a point where they simply should be
>> treated like they don't exist.
>>
>> I consider things broken if the pom doesn't parse, the dependencies
>> are wrong (again subject to perspective in some cases), the gav isn't
>> correct, the checksums or signatures are broken. Otherwise from a
>> repository perspective they are not broken.
>>
>> If you attempt to enumerate all the things in central that match all
>> of those values above and build a repo of only those, it will be a
>> nearly useless repo.
>>
>> ---------------------------------------------------------------------
>> 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
Re: a cleaned up central repository?
Posted by Tamás Cservenák <ta...@cservenak.net>.
Not to mention that these below are "formal" requirements only. Their
_presence_ is required, but nothing is said about their _content_.I can
publish a POM that will _have_ dependencies section, but how do we know that
the dependencies section is _correct_?
Also: license in POM. What license "name" is allowed? Are they keyed by by
license URL? Etc...
Many of these are pretty hard to determine in "machine way"....
~t~
On Tue, Oct 6, 2009 at 2:26 AM, Brian Fox <br...@infinity.nu> wrote:
> On Mon, Oct 5, 2009 at 3:16 PM, Albert Kurucz <al...@gmail.com>
> wrote:
> > Brian,
> >
> >> Ok then, I assert they are all fine. Now you can provide a list and
> >> refute me ;-).
> > In this case (if they were all fine) here is your list:
> > http://repo2.maven.org/maven2/.index/
> > (But unfortunately they are not all fine.)
> >
> >> Seriously, the definition of "broken" depends on the observer.
> > True. This is why maybe there should be different "Good lists" and
> > users should be allowed to choose, depending on their taste.
> >
> >> Before we can
> >> "fix" anything "broken" we need to start by defining what you think is
> >> broken and why.
> >
> > One of the possible Definitions of "Good list", which I would like
> > call "Maven Central Compliance" is defined here:
> > http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> > If artifacts are on Central which are not on this list (which list
> > should really be realized soon), I don't mind, as long as I could
> > search or filter by this list.
> > You cannot objectively define what is "broken" only if you specify
> > which Lists you are talking about. Do you mean, the "Maven Central
> > Compliance" list?
>
> I assume you mean this list of requirements?
> There are some requirements for the minimal information in the POMs
> that are in the central repository. At least these must be present:
>
> modelVersion
> groupId
> artifactId
> packaging
> name
> version
> description
> url
> licenses
> scm url
> dependencies
>
> I don't think that I would consider things broken simply because the
> name, description, url, scm url where missing. I would be annoyed but
> not surprised if the license wasn't populated correctly. So if you're
> saying you want to exclude everything from your build simply because
> one of those are missing, then I think we fundamentally disagree. Yes
> it would be nice if those were filled in properly but none of those
> reduce the usefulness of users to a point where they simply should be
> treated like they don't exist.
>
> I consider things broken if the pom doesn't parse, the dependencies
> are wrong (again subject to perspective in some cases), the gav isn't
> correct, the checksums or signatures are broken. Otherwise from a
> repository perspective they are not broken.
>
> If you attempt to enumerate all the things in central that match all
> of those values above and build a repo of only those, it will be a
> nearly useless repo.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: a cleaned up central repository?
Posted by Brian Fox <br...@infinity.nu>.
On Mon, Oct 5, 2009 at 3:16 PM, Albert Kurucz <al...@gmail.com> wrote:
> Brian,
>
>> Ok then, I assert they are all fine. Now you can provide a list and
>> refute me ;-).
> In this case (if they were all fine) here is your list:
> http://repo2.maven.org/maven2/.index/
> (But unfortunately they are not all fine.)
>
>> Seriously, the definition of "broken" depends on the observer.
> True. This is why maybe there should be different "Good lists" and
> users should be allowed to choose, depending on their taste.
>
>> Before we can
>> "fix" anything "broken" we need to start by defining what you think is
>> broken and why.
>
> One of the possible Definitions of "Good list", which I would like
> call "Maven Central Compliance" is defined here:
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> If artifacts are on Central which are not on this list (which list
> should really be realized soon), I don't mind, as long as I could
> search or filter by this list.
> You cannot objectively define what is "broken" only if you specify
> which Lists you are talking about. Do you mean, the "Maven Central
> Compliance" list?
I assume you mean this list of requirements?
There are some requirements for the minimal information in the POMs
that are in the central repository. At least these must be present:
modelVersion
groupId
artifactId
packaging
name
version
description
url
licenses
scm url
dependencies
I don't think that I would consider things broken simply because the
name, description, url, scm url where missing. I would be annoyed but
not surprised if the license wasn't populated correctly. So if you're
saying you want to exclude everything from your build simply because
one of those are missing, then I think we fundamentally disagree. Yes
it would be nice if those were filled in properly but none of those
reduce the usefulness of users to a point where they simply should be
treated like they don't exist.
I consider things broken if the pom doesn't parse, the dependencies
are wrong (again subject to perspective in some cases), the gav isn't
correct, the checksums or signatures are broken. Otherwise from a
repository perspective they are not broken.
If you attempt to enumerate all the things in central that match all
of those values above and build a repo of only those, it will be a
nearly useless repo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
Brian,
> Ok then, I assert they are all fine. Now you can provide a list and
> refute me ;-).
In this case (if they were all fine) here is your list:
http://repo2.maven.org/maven2/.index/
(But unfortunately they are not all fine.)
> Seriously, the definition of "broken" depends on the observer.
True. This is why maybe there should be different "Good lists" and
users should be allowed to choose, depending on their taste.
> Before we can
> "fix" anything "broken" we need to start by defining what you think is
> broken and why.
One of the possible Definitions of "Good list", which I would like
call "Maven Central Compliance" is defined here:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
If artifacts are on Central which are not on this list (which list
should really be realized soon), I don't mind, as long as I could
search or filter by this list.
You cannot objectively define what is "broken" only if you specify
which Lists you are talking about. Do you mean, the "Maven Central
Compliance" list?
On Mon, Oct 5, 2009 at 12:38 PM, Brian Fox <br...@infinity.nu> wrote:
>>
>> 2.
>>> Provide a detailed list of artifacts and metadata you consider broken.
>> I think this approach will not work.
>> You should really work on providing list of artifacts which are not
>> broken (Certified good list), and having a Maven client which is able
>> to use this list (or multiple lists) for filtering and searching.
>
> Ok then, I assert they are all fine. Now you can provide a list and
> refute me ;-).
>
> Seriously, the definition of "broken" depends on the observer. A pom
> that doesn't mark something as optional only appears broken to users
> who don't otherwise need that dependency for example. Before we can
> "fix" anything "broken" we need to start by defining what you think is
> broken and why.
>
>>
>> 3.
>>> When these artifacts are identified, work with the teams producing
>>> these poms to educate them on the proper pom constructs to eliminate
>>> them.
>> If you have a list (or multiple lists which classify them by testing
>> different qualities) of good artifacts, teams will try to deliver
>> their artifacts to these lists by educating themselves.
>> Trying to police these teams, you will just receive resistance.
>
> Not true from experience, again this is subject to the definition of broken.
>
>>
>>
>>
>> Regards,
>> Albert
>>
>>
>>
>>
>> On Thu, Oct 1, 2009 at 6:51 PM, Brian Fox <br...@infinity.nu> wrote:
>>> Albert,
>>> Clearly you seem to have plenty of enthusiasm for helping to provide
>>> better metadata, and I don't want to discourage that.
>>>
>>> Providing and hosting a repository containing 90 thousand files that
>>> serves greater than 12TB of data a month is not as easy as you might
>>> imagine. Starting over with a new repository is not the answer here.
>>>
>>> Getting 90k artifacts vetted and cleaned is a significant undertaking.
>>> Frankly many of the artifacts in there are old, underused versions and
>>> spending effort on those will have much less immediate impact than
>>> stopping new artifacts getting in that have bad (or missing) data. We
>>> have chosen to attack this problem by raising the barrier to entry for
>>> new artifacts. This work started months ago and we'll be able to put
>>> something in place in the next few weeks.
>>>
>>> This will be done in an automated fashion, starting with artifacts
>>> that are uploaded manually. Then we will apply the same rules
>>> (automatically) to anything coming in via rsync. Besides improving and
>>> vetting the data coming in, this more automated process is designed at
>>> drastically improving the turnaround time to get new artifacts and
>>> sync's configured.
>>>
>>> If you really want to assist here, I can see several ways you
>>> personally can assist this process:
>>>
>>> 1) Contribute _code_ that validates the various conditions you think
>>> are important to validate. We already have an interface developed that
>>> I can point you at if you're interested. These rules will help in many
>>> ways because it will help check new artifacts, check old artifacts,
>>> and allow people to use them with their repository manager internally
>>> if they choose.
>>>
>>> 2) Provide a detailed list of artifacts and metadata you consider
>>> broken. We can sit around and theorize about how things could be
>>> better, but first having a concrete list of broken poms and other data
>>> will help us focus on the most prominent problems first. The MEV
>>> project in Jira is where we collect these. I don't care much if you
>>> produce one jira or a jira with a huge list, it's the gathering of the
>>> list that is most important.
>>>
>>> 3) When these artifacts are identified, work with the teams producing
>>> these poms to educate them on the proper pom constructs to eliminate
>>> them. Generally the teams don't produce bad data on purpose so some
>>> education is required.
>>>
>>> 4) Assuming we have identified a significant number of the problems
>>> from work done in #2, we would then need concrete proposals for how to
>>> fix this without breaking people's builds. Proposals can be posted on
>>> the MAVENUSER wiki space for futher discussion and refinement.
>>>
>>> 5) Assuming the proposals gather momentum, someone would need to code
>>> the proposals
>>>
>>> 6) Then assistance would be needed to actually cleanup the metadata in
>>> the context of the implementation.
>>>
>>> Things get done around here by people actually stepping in to get them
>>> done. You're enthusiastic and we'd be glad to accept help in the areas
>>> above. I think further theorizing at this point is going to get
>>> diminishing returns, and I personally think attempting to fork an
>>> entire repository is not going to help the users as much as even
>>> items #1,2,3 above.
>>>
>>> Brian Fox
>>> Apache Maven PMC Chair-Elect
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Oct 1, 2009 at 12:13 PM, Albert Kurucz <al...@gmail.com> wrote:
>>>> I would like to see some votes:
>>>>
>>>> 1. Big Rotten Onion
>>>> 2. Starting Over After Writing New Policies
>>>>
>>>> On Thu, Oct 1, 2009 at 2:04 PM, Albert Kurucz <al...@gmail.com> wrote:
>>>>> You know where Option1 will drive us?
>>>>> When the added metadata which hides current corruption will become
>>>>> corrupt, we need another layer.
>>>>> At the end, it will look like a big onion. :)
>>>>>
>>>>> Where will Option2 will get us?
>>>>> The new repo will get corrupted again.
>>>>> Unless the policy of repo-ing something will get rewritten, like this:
>>>>> only source code can be uploaded in packages to a public repo.
>>>>> Compile can only take place locally when you are checking out
>>>>> something or after (lazy checkout).
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
Re: a cleaned up central repository?
Posted by Brian Fox <br...@infinity.nu>.
>
> 2.
>> Provide a detailed list of artifacts and metadata you consider broken.
> I think this approach will not work.
> You should really work on providing list of artifacts which are not
> broken (Certified good list), and having a Maven client which is able
> to use this list (or multiple lists) for filtering and searching.
Ok then, I assert they are all fine. Now you can provide a list and
refute me ;-).
Seriously, the definition of "broken" depends on the observer. A pom
that doesn't mark something as optional only appears broken to users
who don't otherwise need that dependency for example. Before we can
"fix" anything "broken" we need to start by defining what you think is
broken and why.
>
> 3.
>> When these artifacts are identified, work with the teams producing
>> these poms to educate them on the proper pom constructs to eliminate
>> them.
> If you have a list (or multiple lists which classify them by testing
> different qualities) of good artifacts, teams will try to deliver
> their artifacts to these lists by educating themselves.
> Trying to police these teams, you will just receive resistance.
Not true from experience, again this is subject to the definition of broken.
>
>
>
> Regards,
> Albert
>
>
>
>
> On Thu, Oct 1, 2009 at 6:51 PM, Brian Fox <br...@infinity.nu> wrote:
>> Albert,
>> Clearly you seem to have plenty of enthusiasm for helping to provide
>> better metadata, and I don't want to discourage that.
>>
>> Providing and hosting a repository containing 90 thousand files that
>> serves greater than 12TB of data a month is not as easy as you might
>> imagine. Starting over with a new repository is not the answer here.
>>
>> Getting 90k artifacts vetted and cleaned is a significant undertaking.
>> Frankly many of the artifacts in there are old, underused versions and
>> spending effort on those will have much less immediate impact than
>> stopping new artifacts getting in that have bad (or missing) data. We
>> have chosen to attack this problem by raising the barrier to entry for
>> new artifacts. This work started months ago and we'll be able to put
>> something in place in the next few weeks.
>>
>> This will be done in an automated fashion, starting with artifacts
>> that are uploaded manually. Then we will apply the same rules
>> (automatically) to anything coming in via rsync. Besides improving and
>> vetting the data coming in, this more automated process is designed at
>> drastically improving the turnaround time to get new artifacts and
>> sync's configured.
>>
>> If you really want to assist here, I can see several ways you
>> personally can assist this process:
>>
>> 1) Contribute _code_ that validates the various conditions you think
>> are important to validate. We already have an interface developed that
>> I can point you at if you're interested. These rules will help in many
>> ways because it will help check new artifacts, check old artifacts,
>> and allow people to use them with their repository manager internally
>> if they choose.
>>
>> 2) Provide a detailed list of artifacts and metadata you consider
>> broken. We can sit around and theorize about how things could be
>> better, but first having a concrete list of broken poms and other data
>> will help us focus on the most prominent problems first. The MEV
>> project in Jira is where we collect these. I don't care much if you
>> produce one jira or a jira with a huge list, it's the gathering of the
>> list that is most important.
>>
>> 3) When these artifacts are identified, work with the teams producing
>> these poms to educate them on the proper pom constructs to eliminate
>> them. Generally the teams don't produce bad data on purpose so some
>> education is required.
>>
>> 4) Assuming we have identified a significant number of the problems
>> from work done in #2, we would then need concrete proposals for how to
>> fix this without breaking people's builds. Proposals can be posted on
>> the MAVENUSER wiki space for futher discussion and refinement.
>>
>> 5) Assuming the proposals gather momentum, someone would need to code
>> the proposals
>>
>> 6) Then assistance would be needed to actually cleanup the metadata in
>> the context of the implementation.
>>
>> Things get done around here by people actually stepping in to get them
>> done. You're enthusiastic and we'd be glad to accept help in the areas
>> above. I think further theorizing at this point is going to get
>> diminishing returns, and I personally think attempting to fork an
>> entire repository is not going to help the users as much as even
>> items #1,2,3 above.
>>
>> Brian Fox
>> Apache Maven PMC Chair-Elect
>>
>>
>>
>>
>>
>> On Thu, Oct 1, 2009 at 12:13 PM, Albert Kurucz <al...@gmail.com> wrote:
>>> I would like to see some votes:
>>>
>>> 1. Big Rotten Onion
>>> 2. Starting Over After Writing New Policies
>>>
>>> On Thu, Oct 1, 2009 at 2:04 PM, Albert Kurucz <al...@gmail.com> wrote:
>>>> You know where Option1 will drive us?
>>>> When the added metadata which hides current corruption will become
>>>> corrupt, we need another layer.
>>>> At the end, it will look like a big onion. :)
>>>>
>>>> Where will Option2 will get us?
>>>> The new repo will get corrupted again.
>>>> Unless the policy of repo-ing something will get rewritten, like this:
>>>> only source code can be uploaded in packages to a public repo.
>>>> Compile can only take place locally when you are checking out
>>>> something or after (lazy checkout).
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
Brian,
1.
Thanks for your invitation to contribute.
I would like to do that, but within my limited free time I can promise
to contribute my thought to MEV, after crystallizing them a bit. I am
working on it.
2.
> Provide a detailed list of artifacts and metadata you consider broken.
I think this approach will not work.
You should really work on providing list of artifacts which are not
broken (Certified good list), and having a Maven client which is able
to use this list (or multiple lists) for filtering and searching.
3.
> When these artifacts are identified, work with the teams producing
> these poms to educate them on the proper pom constructs to eliminate
> them.
If you have a list (or multiple lists which classify them by testing
different qualities) of good artifacts, teams will try to deliver
their artifacts to these lists by educating themselves.
Trying to police these teams, you will just receive resistance.
Regards,
Albert
On Thu, Oct 1, 2009 at 6:51 PM, Brian Fox <br...@infinity.nu> wrote:
> Albert,
> Clearly you seem to have plenty of enthusiasm for helping to provide
> better metadata, and I don't want to discourage that.
>
> Providing and hosting a repository containing 90 thousand files that
> serves greater than 12TB of data a month is not as easy as you might
> imagine. Starting over with a new repository is not the answer here.
>
> Getting 90k artifacts vetted and cleaned is a significant undertaking.
> Frankly many of the artifacts in there are old, underused versions and
> spending effort on those will have much less immediate impact than
> stopping new artifacts getting in that have bad (or missing) data. We
> have chosen to attack this problem by raising the barrier to entry for
> new artifacts. This work started months ago and we'll be able to put
> something in place in the next few weeks.
>
> This will be done in an automated fashion, starting with artifacts
> that are uploaded manually. Then we will apply the same rules
> (automatically) to anything coming in via rsync. Besides improving and
> vetting the data coming in, this more automated process is designed at
> drastically improving the turnaround time to get new artifacts and
> sync's configured.
>
> If you really want to assist here, I can see several ways you
> personally can assist this process:
>
> 1) Contribute _code_ that validates the various conditions you think
> are important to validate. We already have an interface developed that
> I can point you at if you're interested. These rules will help in many
> ways because it will help check new artifacts, check old artifacts,
> and allow people to use them with their repository manager internally
> if they choose.
>
> 2) Provide a detailed list of artifacts and metadata you consider
> broken. We can sit around and theorize about how things could be
> better, but first having a concrete list of broken poms and other data
> will help us focus on the most prominent problems first. The MEV
> project in Jira is where we collect these. I don't care much if you
> produce one jira or a jira with a huge list, it's the gathering of the
> list that is most important.
>
> 3) When these artifacts are identified, work with the teams producing
> these poms to educate them on the proper pom constructs to eliminate
> them. Generally the teams don't produce bad data on purpose so some
> education is required.
>
> 4) Assuming we have identified a significant number of the problems
> from work done in #2, we would then need concrete proposals for how to
> fix this without breaking people's builds. Proposals can be posted on
> the MAVENUSER wiki space for futher discussion and refinement.
>
> 5) Assuming the proposals gather momentum, someone would need to code
> the proposals
>
> 6) Then assistance would be needed to actually cleanup the metadata in
> the context of the implementation.
>
> Things get done around here by people actually stepping in to get them
> done. You're enthusiastic and we'd be glad to accept help in the areas
> above. I think further theorizing at this point is going to get
> diminishing returns, and I personally think attempting to fork an
> entire repository is not going to help the users as much as even
> items #1,2,3 above.
>
> Brian Fox
> Apache Maven PMC Chair-Elect
>
>
>
>
>
> On Thu, Oct 1, 2009 at 12:13 PM, Albert Kurucz <al...@gmail.com> wrote:
>> I would like to see some votes:
>>
>> 1. Big Rotten Onion
>> 2. Starting Over After Writing New Policies
>>
>> On Thu, Oct 1, 2009 at 2:04 PM, Albert Kurucz <al...@gmail.com> wrote:
>>> You know where Option1 will drive us?
>>> When the added metadata which hides current corruption will become
>>> corrupt, we need another layer.
>>> At the end, it will look like a big onion. :)
>>>
>>> Where will Option2 will get us?
>>> The new repo will get corrupted again.
>>> Unless the policy of repo-ing something will get rewritten, like this:
>>> only source code can be uploaded in packages to a public repo.
>>> Compile can only take place locally when you are checking out
>>> something or after (lazy checkout).
>>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
Isn't that funny:
http://ask.metafilter.com/68789/Why-do-rotten-onions-smell-good
On Thu, Oct 1, 2009 at 2:13 PM, Albert Kurucz <al...@gmail.com> wrote:
> I would like to see some votes:
>
> 1. Big Rotten Onion
> 2. Starting Over After Writing New Policies
>
> On Thu, Oct 1, 2009 at 2:04 PM, Albert Kurucz <al...@gmail.com> wrote:
>> You know where Option1 will drive us?
>> When the added metadata which hides current corruption will become
>> corrupt, we need another layer.
>> At the end, it will look like a big onion. :)
>>
>> Where will Option2 will get us?
>> The new repo will get corrupted again.
>> Unless the policy of repo-ing something will get rewritten, like this:
>> only source code can be uploaded in packages to a public repo.
>> Compile can only take place locally when you are checking out
>> something or after (lazy checkout).
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Brian Fox <br...@infinity.nu>.
>
> Brian, do you want expand on this for the rest of us? What are the rules,
> how will it work, and how can we use it?
>
The details belong in another thread, but we'll be able to implement
these rules for projects using repository.apache.org and
oss.sonatype.org. This isn't really new information, we discussed this
many months ago, it was affectionately referred to as the "wendy"
plugin. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Brett Porter <br...@apache.org>.
On 02/10/2009, at 9:51 AM, Brian Fox wrote:
> We
> have chosen to attack this problem by raising the barrier to entry for
> new artifacts. This work started months ago and we'll be able to put
> something in place in the next few weeks.
>
> This will be done in an automated fashion, starting with artifacts
> that are uploaded manually. Then we will apply the same rules
> (automatically) to anything coming in via rsync. Besides improving and
> vetting the data coming in, this more automated process is designed at
> drastically improving the turnaround time to get new artifacts and
> sync's configured.
Brian, do you want expand on this for the rest of us? What are the
rules, how will it work, and how can we use it?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Brian Fox <br...@infinity.nu>.
Albert,
Clearly you seem to have plenty of enthusiasm for helping to provide
better metadata, and I don't want to discourage that.
Providing and hosting a repository containing 90 thousand files that
serves greater than 12TB of data a month is not as easy as you might
imagine. Starting over with a new repository is not the answer here.
Getting 90k artifacts vetted and cleaned is a significant undertaking.
Frankly many of the artifacts in there are old, underused versions and
spending effort on those will have much less immediate impact than
stopping new artifacts getting in that have bad (or missing) data. We
have chosen to attack this problem by raising the barrier to entry for
new artifacts. This work started months ago and we'll be able to put
something in place in the next few weeks.
This will be done in an automated fashion, starting with artifacts
that are uploaded manually. Then we will apply the same rules
(automatically) to anything coming in via rsync. Besides improving and
vetting the data coming in, this more automated process is designed at
drastically improving the turnaround time to get new artifacts and
sync's configured.
If you really want to assist here, I can see several ways you
personally can assist this process:
1) Contribute _code_ that validates the various conditions you think
are important to validate. We already have an interface developed that
I can point you at if you're interested. These rules will help in many
ways because it will help check new artifacts, check old artifacts,
and allow people to use them with their repository manager internally
if they choose.
2) Provide a detailed list of artifacts and metadata you consider
broken. We can sit around and theorize about how things could be
better, but first having a concrete list of broken poms and other data
will help us focus on the most prominent problems first. The MEV
project in Jira is where we collect these. I don't care much if you
produce one jira or a jira with a huge list, it's the gathering of the
list that is most important.
3) When these artifacts are identified, work with the teams producing
these poms to educate them on the proper pom constructs to eliminate
them. Generally the teams don't produce bad data on purpose so some
education is required.
4) Assuming we have identified a significant number of the problems
from work done in #2, we would then need concrete proposals for how to
fix this without breaking people's builds. Proposals can be posted on
the MAVENUSER wiki space for futher discussion and refinement.
5) Assuming the proposals gather momentum, someone would need to code
the proposals
6) Then assistance would be needed to actually cleanup the metadata in
the context of the implementation.
Things get done around here by people actually stepping in to get them
done. You're enthusiastic and we'd be glad to accept help in the areas
above. I think further theorizing at this point is going to get
diminishing returns, and I personally think attempting to fork an
entire repository is not going to help the users as much as even
items #1,2,3 above.
Brian Fox
Apache Maven PMC Chair-Elect
On Thu, Oct 1, 2009 at 12:13 PM, Albert Kurucz <al...@gmail.com> wrote:
> I would like to see some votes:
>
> 1. Big Rotten Onion
> 2. Starting Over After Writing New Policies
>
> On Thu, Oct 1, 2009 at 2:04 PM, Albert Kurucz <al...@gmail.com> wrote:
>> You know where Option1 will drive us?
>> When the added metadata which hides current corruption will become
>> corrupt, we need another layer.
>> At the end, it will look like a big onion. :)
>>
>> Where will Option2 will get us?
>> The new repo will get corrupted again.
>> Unless the policy of repo-ing something will get rewritten, like this:
>> only source code can be uploaded in packages to a public repo.
>> Compile can only take place locally when you are checking out
>> something or after (lazy checkout).
>>
>
> ---------------------------------------------------------------------
> 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
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
I would like to see some votes:
1. Big Rotten Onion
2. Starting Over After Writing New Policies
On Thu, Oct 1, 2009 at 2:04 PM, Albert Kurucz <al...@gmail.com> wrote:
> You know where Option1 will drive us?
> When the added metadata which hides current corruption will become
> corrupt, we need another layer.
> At the end, it will look like a big onion. :)
>
> Where will Option2 will get us?
> The new repo will get corrupted again.
> Unless the policy of repo-ing something will get rewritten, like this:
> only source code can be uploaded in packages to a public repo.
> Compile can only take place locally when you are checking out
> something or after (lazy checkout).
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
You know where Option1 will drive us?
When the added metadata which hides current corruption will become
corrupt, we need another layer.
At the end, it will look like a big onion. :)
Where will Option2 will get us?
The new repo will get corrupted again.
Unless the policy of repo-ing something will get rewritten, like this:
only source code can be uploaded in packages to a public repo.
Compile can only take place locally when you are checking out
something or after (lazy checkout).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Albert Kurucz <al...@gmail.com>.
http://www.mail-archive.com/users@maven.apache.org/msg102285.html
According to current policies, fixing corruptions on Central is not an option.
Change policies is not an option. (Change-able policy is not a policy).
Option1: Hide the corruption (through added metadata)
Option2: Build a new Central which is clean
On Thu, Oct 1, 2009 at 1:20 PM, Stephen Connolly
<st...@gmail.com> wrote:
> if we have a second repo at all that means that anyone not using a
> repository manager will hit both repos for every artifact (which is bad)
>
> IMHO, central is what it is, all we can do is add metadata to help paint
> over the crayon scribbles on the wall from when the children were growing up
> ;-)
>
> -Stephen
>
> Sent from my [rhymes with tryPod] ;-)
>
> On 1 Oct 2009, at 18:39, Paul Gier <pg...@redhat.com> wrote:
>
>> What about creating a new legacy repository for deprecated artifacts?
>> Stuff that we don't want in the main repository could be moved to a new
>> legacy repo. This way we effectively deprecate these artifacts, but it does
>> not require any POM or metadata changes. Anyone that needs to use the
>> deprecated artifacts, could then just add the legacy repo to their repo
>> manager or a profile in settings.xml.
>>
>> Jason van Zyl wrote:
>>>
>>> On 2009-09-25, at 5:13 AM, Petar Tahchiev wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I also like the idea about deprecating artifacts, or whole directory
>>>> structure.
>>>> A step forward would be to create a maven-dev-approved repositories or
>>>> artifacts.
>>>
>>> Exactly, this is all part of providing better information over time.
>>> There is no big bang cleanup that makes it all better. That is just a pipe
>>> dream. We just have to incrementally and diligently clean up what we have.
>>> Maven Central is a great resource and it needs some TLC but not cleansing.
>>>>
>>>> Imagine you are using an outside repository that is really messed up
>>>> (or worse - anyone can put anything any time).
>>>> What maven the team could do is setup a ground base of rules, so that
>>>> if you want your repository to be
>>>> maven-dev-compliant you must follow them. Later if you are using
>>>> artifacts from repositories that are not
>>>> maven-dev-compliant, there could be a message warning you.
>>>> To me it doesn't really make sense to create a new repository without
>>>> improving the process of using the repositories.
>>>> Otherwise, as Brian pointed, we will end up with a new repository,
>>>> which has the same data, and no one is using the old repo.
>>>>
>>>> Cheers, Petar.
>>>>
>>>> Because without it doesn't really make
>>>> sense creating new repository and
>>>>
>>>> 2009/9/25 Stephen Connolly <st...@gmail.com>:
>>>>>
>>>>> +1 to adding deprecation metadata.
>>>>>
>>>>> -1 to having a plugin... the deprecation warnings should come from
>>>>> maven core itself... ok we can add a plugin for [2.0.x,2.2.1] support
>>>>>
>>>>> Also if we are adding deprecation metadata, there are a number of
>>>>> other little bits of metadata that should be added, e.g. version
>>>>> comparison scheme (since OSGI rules are different from Maven 2.x
>>>>> rules, we will need a way to flag which rules apply... I see this as
>>>>> being a rule applied to a groupId or at best a groupId:artifactId...
>>>>> if you want to change your version comparison rule halfway through,
>>>>> change the groupId or the artifactId)
>>>>>
>>>>> -Stephen
>>>>>
>>>>> 2009/9/25 Anders Kristian Andersen
>>>>> <an...@gmail.com>:
>>>>>>
>>>>>> I think it is TOTAL important we keep the contract:
>>>>>> *** This is a long standing rule that we do not remove or change the
>>>>>> contents of central ***
>>>>>>
>>>>>> Therefore a way out could be to start making deprecated tags in the
>>>>>> directories.
>>>>>> Then we could come up with a *** maven-deprected-dependency-plugin
>>>>>> *** that
>>>>>> could warn users against various bad / deprecated / moved artifacts.
>>>>>>
>>>>>> Consider a director xxxx with pom.xml and other files.
>>>>>>
>>>>>> adding a file called deprecated.xml could deprecate the directory /
>>>>>> parts of
>>>>>> the files etc.
>>>>>>
>>>>>> then running
>>>>>>
>>>>>> mvn deprected-dependency:check
>>>>>> would list usage
>>>>>>
>>>>>> This could be combined with options / tools in archiva could help too.
>>>>>>
>>>>>> best regards
>>>>>> Anders Kristian Andersen
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 25/09/2009, at 06.11, Brian Fox wrote:
>>>>>>
>>>>>>> This has already been done once in history, between M1 and M2 and
>>>>>>> look
>>>>>>> how we still have that mess to deal with all the time. Doing this
>>>>>>> again serves no one well, making sure new data coming in is clean is
>>>>>>> more productive for everyone. Who would _want_ to deploy their stuff
>>>>>>> to the "old" repo? No one. The hurdle to get to the new repo would be
>>>>>>> the same as putting the checks on the current repo for all new
>>>>>>> artifacts.
>>>>>>>
>>>>>>> On Thu, Sep 24, 2009 at 8:37 PM, Brett Porter <br...@apache.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Moving over to dev...
>>>>>>>>
>>>>>>>> So here's a thought - why don't we create a "new" central
>>>>>>>> repository?
>>>>>>>>
>>>>>>>> - a new repository with strict acceptance rules regarding POMs,
>>>>>>>> signatures,
>>>>>>>> ownership, etc.
>>>>>>>> - if there's a new metadata format needed (recently discussed), this
>>>>>>>> would
>>>>>>>> use it
>>>>>>>> - validated artifacts could be moved over and requests to the old
>>>>>>>> rewritten
>>>>>>>> (in the same way we maintained the maven1 repo)
>>>>>>>> - default Maven can ship with both repositories enabled, but a "best
>>>>>>>> practice" would be to turn old central off (or better, use a
>>>>>>>> repository
>>>>>>>> manager that doesn't access it / only access it for acceptable
>>>>>>>> artifacts)
>>>>>>>>
>>>>>>>> The main issue is finding a way to overcome confusion when an
>>>>>>>> artifact is
>>>>>>>> changed - you want "old" builds to keep using the same one it always
>>>>>>>> did,
>>>>>>>> but new builds to use the new one (and cope with potential revision
>>>>>>>> of
>>>>>>>> metadata without breaking builds). This is the sort of thing that
>>>>>>>> could
>>>>>>>> be
>>>>>>>> built into Maven in a new version and the new repo format only
>>>>>>>> accessible
>>>>>>>> from that version.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Brett
>>>>>>>>
>>>>>>>> On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
>>>>>>>>
>>>>>>>>> Jason and Brian, thanks for the explanations.
>>>>>>>>> Understood, the policy of not removing anything from Maven Central
>>>>>>>>> serves a purpose.
>>>>>>>>>
>>>>>>>>> I wish there would be another publicly Maven repository, which is
>>>>>>>>> maintained with rules enforced. This repo could even have a rule
>>>>>>>>> (additional to the old and unenforced rules) that only Maven built
>>>>>>>>> projects can enter, maybe even more restriction: only the
>>>>>>>>> designated
>>>>>>>>> Continuous Integration server can upload to it.
>>>>>>>>> This pure Maven repo would not be able to compete with Maven
>>>>>>>>> Central
>>>>>>>>> regarding size or the number of artifacts, but some OSS developers
>>>>>>>>> might prefer to use from and supply to this one instead of the big
>>>>>>>>> and
>>>>>>>>> ugly.
>>>>>>>>>
>>>>>>>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz
>>>>>>>>>> <al...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Requirements for the POMs are defined as:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>>>>>>>>> I call the artifact corrupt (regarding Maven Central Compliance)
>>>>>>>>>>> if
>>>>>>>>>>> the POM of the artifact does not fulfills the above requirements.
>>>>>>>>>>> There are corrupt ones have made it to the Central, because the
>>>>>>>>>>> guard
>>>>>>>>>>> was sleeping.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Correct, but changing them is not an option because it will
>>>>>>>>>> destabilize builds. This is a long standing rule that we do not
>>>>>>>>>> remove
>>>>>>>>>> or change the contents of central.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: users-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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards, Petar!
>>>> Karlovo, Bulgaria.
>>>> - - - - - - - -
>>>> | Author @ Manning Publications.
>>>> | CEO @ Phamola
>>>> | BGJUG-Bulgarian Java User Group Leader.
>>>> | Apache Maven Developer.
>>>> | Apache Jakarta PMC member.
>>>> | Jakarta Cactus Lead Developer.
>>>> | Codehaus Plexus Developer
>>>> | Blogger: http://weblogs.java.net/blog/paranoiabla/
>>>> - - - - - - - -
>>>> Public PGP Key at:
>>>>
>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>> Thanks,
>>> Jason
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> 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
Re: a cleaned up central repository?
Posted by Jason van Zyl <ja...@sonatype.com>.
On 2009-10-02, at 6:35 AM, Paul Gier wrote:
> Brian Fox wrote:
>> On Fri, Oct 2, 2009 at 5:57 AM, Paul Gier <pg...@redhat.com> wrote:
>>> Why would everyone need to use both repos? If the legacy
>>> repository is done
>>> correctly, the vast majority of users would never need to hit it,
>>> or even
>>> know about it at all.
>>>
>>> Note that this idea is different than creating a new clean
>>> repository. This
>>> would be a new repository just for the garbage. Most artifacts
>>> would stay
>>> where they are.
>>>
>>> Just as an example, in the jboss repo I found someone had mixed up
>>> the main
>>> jar with the javadoc jar. So Maven was trying to use the javadocs
>>> on the
>>> classpath. Stuff like this is unusable, and should be removed
>>> from the
>>> repository IMO.
>>>
>> Something like that likely would, but we don't control the jboss
>> repo.
>
> I removed that one from the JBoss repo already. I was just using it
> as an example. My point is that there is stuff in central that
> isn't being used and could safely be moved to a legacy repository as
> part of the cleanup effort.
>
> I agree with Brian's other comment though that the most improvement
> will probably be gained from preventing new bad stuff going in.
>
That is simply the only way it will work without wreaking havoc.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Paul Gier <pg...@redhat.com>.
Brian Fox wrote:
> On Fri, Oct 2, 2009 at 5:57 AM, Paul Gier <pg...@redhat.com> wrote:
>> Why would everyone need to use both repos? If the legacy repository is done
>> correctly, the vast majority of users would never need to hit it, or even
>> know about it at all.
>>
>> Note that this idea is different than creating a new clean repository. This
>> would be a new repository just for the garbage. Most artifacts would stay
>> where they are.
>>
>> Just as an example, in the jboss repo I found someone had mixed up the main
>> jar with the javadoc jar. So Maven was trying to use the javadocs on the
>> classpath. Stuff like this is unusable, and should be removed from the
>> repository IMO.
>>
> Something like that likely would, but we don't control the jboss repo.
>
I removed that one from the JBoss repo already. I was just using it as an
example. My point is that there is stuff in central that isn't being used and
could safely be moved to a legacy repository as part of the cleanup effort.
I agree with Brian's other comment though that the most improvement will
probably be gained from preventing new bad stuff going in.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Brian Fox <br...@infinity.nu>.
On Fri, Oct 2, 2009 at 5:57 AM, Paul Gier <pg...@redhat.com> wrote:
> Why would everyone need to use both repos? If the legacy repository is done
> correctly, the vast majority of users would never need to hit it, or even
> know about it at all.
>
> Note that this idea is different than creating a new clean repository. This
> would be a new repository just for the garbage. Most artifacts would stay
> where they are.
>
> Just as an example, in the jboss repo I found someone had mixed up the main
> jar with the javadoc jar. So Maven was trying to use the javadocs on the
> classpath. Stuff like this is unusable, and should be removed from the
> repository IMO.
>
Something like that likely would, but we don't control the jboss repo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository?
Posted by Paul Gier <pg...@redhat.com>.
Why would everyone need to use both repos? If the legacy repository is done
correctly, the vast majority of users would never need to hit it, or even know
about it at all.
Note that this idea is different than creating a new clean repository. This
would be a new repository just for the garbage. Most artifacts would stay where
they are.
Just as an example, in the jboss repo I found someone had mixed up the main jar
with the javadoc jar. So Maven was trying to use the javadocs on the classpath.
Stuff like this is unusable, and should be removed from the repository IMO.
Stephen Connolly wrote:
> if we have a second repo at all that means that anyone not using a
> repository manager will hit both repos for every artifact (which is bad)
>
> IMHO, central is what it is, all we can do is add metadata to help paint
> over the crayon scribbles on the wall from when the children were
> growing up ;-)
>
> -Stephen
>
> Sent from my [rhymes with tryPod] ;-)
>
> On 1 Oct 2009, at 18:39, Paul Gier <pg...@redhat.com> wrote:
>
>> What about creating a new legacy repository for deprecated artifacts?
>> Stuff that we don't want in the main repository could be moved to a
>> new legacy repo. This way we effectively deprecate these artifacts,
>> but it does not require any POM or metadata changes. Anyone that
>> needs to use the deprecated artifacts, could then just add the legacy
>> repo to their repo manager or a profile in settings.xml.
>>
>> Jason van Zyl wrote:
>>> On 2009-09-25, at 5:13 AM, Petar Tahchiev wrote:
>>>> Hi all,
>>>>
>>>> I also like the idea about deprecating artifacts, or whole directory
>>>> structure.
>>>> A step forward would be to create a maven-dev-approved repositories or
>>>> artifacts.
>>> Exactly, this is all part of providing better information over time.
>>> There is no big bang cleanup that makes it all better. That is just a
>>> pipe dream. We just have to incrementally and diligently clean up
>>> what we have. Maven Central is a great resource and it needs some TLC
>>> but not cleansing.
>>>> Imagine you are using an outside repository that is really messed up
>>>> (or worse - anyone can put anything any time).
>>>> What maven the team could do is setup a ground base of rules, so that
>>>> if you want your repository to be
>>>> maven-dev-compliant you must follow them. Later if you are using
>>>> artifacts from repositories that are not
>>>> maven-dev-compliant, there could be a message warning you.
>>>> To me it doesn't really make sense to create a new repository without
>>>> improving the process of using the repositories.
>>>> Otherwise, as Brian pointed, we will end up with a new repository,
>>>> which has the same data, and no one is using the old repo.
>>>>
>>>> Cheers, Petar.
>>>>
>>>> Because without it doesn't really make
>>>> sense creating new repository and
>>>>
>>>> 2009/9/25 Stephen Connolly <st...@gmail.com>:
>>>>> +1 to adding deprecation metadata.
>>>>>
>>>>> -1 to having a plugin... the deprecation warnings should come from
>>>>> maven core itself... ok we can add a plugin for [2.0.x,2.2.1] support
>>>>>
>>>>> Also if we are adding deprecation metadata, there are a number of
>>>>> other little bits of metadata that should be added, e.g. version
>>>>> comparison scheme (since OSGI rules are different from Maven 2.x
>>>>> rules, we will need a way to flag which rules apply... I see this as
>>>>> being a rule applied to a groupId or at best a groupId:artifactId...
>>>>> if you want to change your version comparison rule halfway through,
>>>>> change the groupId or the artifactId)
>>>>>
>>>>> -Stephen
>>>>>
>>>>> 2009/9/25 Anders Kristian Andersen
>>>>> <an...@gmail.com>:
>>>>>> I think it is TOTAL important we keep the contract:
>>>>>> *** This is a long standing rule that we do not remove or change the
>>>>>> contents of central ***
>>>>>>
>>>>>> Therefore a way out could be to start making deprecated tags in the
>>>>>> directories.
>>>>>> Then we could come up with a ***
>>>>>> maven-deprected-dependency-plugin *** that
>>>>>> could warn users against various bad / deprecated / moved artifacts.
>>>>>>
>>>>>> Consider a director xxxx with pom.xml and other files.
>>>>>>
>>>>>> adding a file called deprecated.xml could deprecate the directory
>>>>>> / parts of
>>>>>> the files etc.
>>>>>>
>>>>>> then running
>>>>>>
>>>>>> mvn deprected-dependency:check
>>>>>> would list usage
>>>>>>
>>>>>> This could be combined with options / tools in archiva could help
>>>>>> too.
>>>>>>
>>>>>> best regards
>>>>>> Anders Kristian Andersen
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 25/09/2009, at 06.11, Brian Fox wrote:
>>>>>>
>>>>>>> This has already been done once in history, between M1 and M2 and
>>>>>>> look
>>>>>>> how we still have that mess to deal with all the time. Doing this
>>>>>>> again serves no one well, making sure new data coming in is clean is
>>>>>>> more productive for everyone. Who would _want_ to deploy their stuff
>>>>>>> to the "old" repo? No one. The hurdle to get to the new repo
>>>>>>> would be
>>>>>>> the same as putting the checks on the current repo for all new
>>>>>>> artifacts.
>>>>>>>
>>>>>>> On Thu, Sep 24, 2009 at 8:37 PM, Brett Porter <br...@apache.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Moving over to dev...
>>>>>>>>
>>>>>>>> So here's a thought - why don't we create a "new" central
>>>>>>>> repository?
>>>>>>>>
>>>>>>>> - a new repository with strict acceptance rules regarding POMs,
>>>>>>>> signatures,
>>>>>>>> ownership, etc.
>>>>>>>> - if there's a new metadata format needed (recently discussed),
>>>>>>>> this
>>>>>>>> would
>>>>>>>> use it
>>>>>>>> - validated artifacts could be moved over and requests to the old
>>>>>>>> rewritten
>>>>>>>> (in the same way we maintained the maven1 repo)
>>>>>>>> - default Maven can ship with both repositories enabled, but a
>>>>>>>> "best
>>>>>>>> practice" would be to turn old central off (or better, use a
>>>>>>>> repository
>>>>>>>> manager that doesn't access it / only access it for acceptable
>>>>>>>> artifacts)
>>>>>>>>
>>>>>>>> The main issue is finding a way to overcome confusion when an
>>>>>>>> artifact is
>>>>>>>> changed - you want "old" builds to keep using the same one it
>>>>>>>> always did,
>>>>>>>> but new builds to use the new one (and cope with potential
>>>>>>>> revision of
>>>>>>>> metadata without breaking builds). This is the sort of thing
>>>>>>>> that could
>>>>>>>> be
>>>>>>>> built into Maven in a new version and the new repo format only
>>>>>>>> accessible
>>>>>>>> from that version.
>>>>>>>>
>>>>>>>> Thoughts?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Brett
>>>>>>>>
>>>>>>>> On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
>>>>>>>>
>>>>>>>>> Jason and Brian, thanks for the explanations.
>>>>>>>>> Understood, the policy of not removing anything from Maven Central
>>>>>>>>> serves a purpose.
>>>>>>>>>
>>>>>>>>> I wish there would be another publicly Maven repository, which is
>>>>>>>>> maintained with rules enforced. This repo could even have a rule
>>>>>>>>> (additional to the old and unenforced rules) that only Maven built
>>>>>>>>> projects can enter, maybe even more restriction: only the
>>>>>>>>> designated
>>>>>>>>> Continuous Integration server can upload to it.
>>>>>>>>> This pure Maven repo would not be able to compete with Maven
>>>>>>>>> Central
>>>>>>>>> regarding size or the number of artifacts, but some OSS developers
>>>>>>>>> might prefer to use from and supply to this one instead of the
>>>>>>>>> big and
>>>>>>>>> ugly.
>>>>>>>>>
>>>>>>>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz
>>>>>>>>>> <al...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Requirements for the POMs are defined as:
>>>>>>>>>>>
>>>>>>>>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>>>>>>>>>
>>>>>>>>>>> I call the artifact corrupt (regarding Maven Central
>>>>>>>>>>> Compliance) if
>>>>>>>>>>> the POM of the artifact does not fulfills the above
>>>>>>>>>>> requirements.
>>>>>>>>>>> There are corrupt ones have made it to the Central, because
>>>>>>>>>>> the guard
>>>>>>>>>>> was sleeping.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Correct, but changing them is not an option because it will
>>>>>>>>>> destabilize builds. This is a long standing rule that we do
>>>>>>>>>> not remove
>>>>>>>>>> or change the contents of central.
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: users-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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards, Petar!
>>>> Karlovo, Bulgaria.
>>>> - - - - - - - -
>>>> | Author @ Manning Publications.
>>>> | CEO @ Phamola
>>>> | BGJUG-Bulgarian Java User Group Leader.
>>>> | Apache Maven Developer.
>>>> | Apache Jakarta PMC member.
>>>> | Jakarta Cactus Lead Developer.
>>>> | Codehaus Plexus Developer
>>>> | Blogger: http://weblogs.java.net/blog/paranoiabla/
>>>> - - - - - - - -
>>>> Public PGP Key at:
>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>> Thanks,
>>> Jason
>>> ----------------------------------------------------------
>>> Jason van Zyl
>>> Founder, Apache Maven
>>> http://twitter.com/jvanzyl
>>> ----------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> 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
Re: a cleaned up central repository?
Posted by Stephen Connolly <st...@gmail.com>.
if we have a second repo at all that means that anyone not using a
repository manager will hit both repos for every artifact (which is bad)
IMHO, central is what it is, all we can do is add metadata to help
paint over the crayon scribbles on the wall from when the children
were growing up ;-)
-Stephen
Sent from my [rhymes with tryPod] ;-)
On 1 Oct 2009, at 18:39, Paul Gier <pg...@redhat.com> wrote:
> What about creating a new legacy repository for deprecated
> artifacts? Stuff that we don't want in the main repository could be
> moved to a new legacy repo. This way we effectively deprecate these
> artifacts, but it does not require any POM or metadata changes.
> Anyone that needs to use the deprecated artifacts, could then just
> add the legacy repo to their repo manager or a profile in
> settings.xml.
>
> Jason van Zyl wrote:
>> On 2009-09-25, at 5:13 AM, Petar Tahchiev wrote:
>>> Hi all,
>>>
>>> I also like the idea about deprecating artifacts, or whole
>>> directory structure.
>>> A step forward would be to create a maven-dev-approved
>>> repositories or
>>> artifacts.
>> Exactly, this is all part of providing better information over
>> time. There is no big bang cleanup that makes it all better. That
>> is just a pipe dream. We just have to incrementally and diligently
>> clean up what we have. Maven Central is a great resource and it
>> needs some TLC but not cleansing.
>>> Imagine you are using an outside repository that is really messed up
>>> (or worse - anyone can put anything any time).
>>> What maven the team could do is setup a ground base of rules, so
>>> that
>>> if you want your repository to be
>>> maven-dev-compliant you must follow them. Later if you are using
>>> artifacts from repositories that are not
>>> maven-dev-compliant, there could be a message warning you.
>>> To me it doesn't really make sense to create a new repository
>>> without
>>> improving the process of using the repositories.
>>> Otherwise, as Brian pointed, we will end up with a new repository,
>>> which has the same data, and no one is using the old repo.
>>>
>>> Cheers, Petar.
>>>
>>> Because without it doesn't really make
>>> sense creating new repository and
>>>
>>> 2009/9/25 Stephen Connolly <st...@gmail.com>:
>>>> +1 to adding deprecation metadata.
>>>>
>>>> -1 to having a plugin... the deprecation warnings should come from
>>>> maven core itself... ok we can add a plugin for [2.0.x,2.2.1]
>>>> support
>>>>
>>>> Also if we are adding deprecation metadata, there are a number of
>>>> other little bits of metadata that should be added, e.g. version
>>>> comparison scheme (since OSGI rules are different from Maven 2.x
>>>> rules, we will need a way to flag which rules apply... I see this
>>>> as
>>>> being a rule applied to a groupId or at best a
>>>> groupId:artifactId...
>>>> if you want to change your version comparison rule halfway through,
>>>> change the groupId or the artifactId)
>>>>
>>>> -Stephen
>>>>
>>>> 2009/9/25 Anders Kristian Andersen <anders.kristian.andersen@gmail.com
>>>> >:
>>>>> I think it is TOTAL important we keep the contract:
>>>>> *** This is a long standing rule that we do not remove or change
>>>>> the
>>>>> contents of central ***
>>>>>
>>>>> Therefore a way out could be to start making deprecated tags in
>>>>> the
>>>>> directories.
>>>>> Then we could come up with a *** maven-deprected-dependency-
>>>>> plugin *** that
>>>>> could warn users against various bad / deprecated / moved
>>>>> artifacts.
>>>>>
>>>>> Consider a director xxxx with pom.xml and other files.
>>>>>
>>>>> adding a file called deprecated.xml could deprecate the
>>>>> directory / parts of
>>>>> the files etc.
>>>>>
>>>>> then running
>>>>>
>>>>> mvn deprected-dependency:check
>>>>> would list usage
>>>>>
>>>>> This could be combined with options / tools in archiva could
>>>>> help too.
>>>>>
>>>>> best regards
>>>>> Anders Kristian Andersen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 25/09/2009, at 06.11, Brian Fox wrote:
>>>>>
>>>>>> This has already been done once in history, between M1 and M2
>>>>>> and look
>>>>>> how we still have that mess to deal with all the time. Doing this
>>>>>> again serves no one well, making sure new data coming in is
>>>>>> clean is
>>>>>> more productive for everyone. Who would _want_ to deploy their
>>>>>> stuff
>>>>>> to the "old" repo? No one. The hurdle to get to the new repo
>>>>>> would be
>>>>>> the same as putting the checks on the current repo for all new
>>>>>> artifacts.
>>>>>>
>>>>>> On Thu, Sep 24, 2009 at 8:37 PM, Brett Porter
>>>>>> <br...@apache.org> wrote:
>>>>>>>
>>>>>>> Moving over to dev...
>>>>>>>
>>>>>>> So here's a thought - why don't we create a "new" central
>>>>>>> repository?
>>>>>>>
>>>>>>> - a new repository with strict acceptance rules regarding POMs,
>>>>>>> signatures,
>>>>>>> ownership, etc.
>>>>>>> - if there's a new metadata format needed (recently
>>>>>>> discussed), this
>>>>>>> would
>>>>>>> use it
>>>>>>> - validated artifacts could be moved over and requests to the
>>>>>>> old
>>>>>>> rewritten
>>>>>>> (in the same way we maintained the maven1 repo)
>>>>>>> - default Maven can ship with both repositories enabled, but a
>>>>>>> "best
>>>>>>> practice" would be to turn old central off (or better, use a
>>>>>>> repository
>>>>>>> manager that doesn't access it / only access it for acceptable
>>>>>>> artifacts)
>>>>>>>
>>>>>>> The main issue is finding a way to overcome confusion when an
>>>>>>> artifact is
>>>>>>> changed - you want "old" builds to keep using the same one it
>>>>>>> always did,
>>>>>>> but new builds to use the new one (and cope with potential
>>>>>>> revision of
>>>>>>> metadata without breaking builds). This is the sort of thing
>>>>>>> that could
>>>>>>> be
>>>>>>> built into Maven in a new version and the new repo format only
>>>>>>> accessible
>>>>>>> from that version.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Brett
>>>>>>>
>>>>>>> On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
>>>>>>>
>>>>>>>> Jason and Brian, thanks for the explanations.
>>>>>>>> Understood, the policy of not removing anything from Maven
>>>>>>>> Central
>>>>>>>> serves a purpose.
>>>>>>>>
>>>>>>>> I wish there would be another publicly Maven repository,
>>>>>>>> which is
>>>>>>>> maintained with rules enforced. This repo could even have a
>>>>>>>> rule
>>>>>>>> (additional to the old and unenforced rules) that only Maven
>>>>>>>> built
>>>>>>>> projects can enter, maybe even more restriction: only the
>>>>>>>> designated
>>>>>>>> Continuous Integration server can upload to it.
>>>>>>>> This pure Maven repo would not be able to compete with Maven
>>>>>>>> Central
>>>>>>>> regarding size or the number of artifacts, but some OSS
>>>>>>>> developers
>>>>>>>> might prefer to use from and supply to this one instead of
>>>>>>>> the big and
>>>>>>>> ugly.
>>>>>>>>
>>>>>>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox
>>>>>>>> <br...@infinity.nu> wrote:
>>>>>>>>>
>>>>>>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz
>>>>>>>>> <al...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Requirements for the POMs are defined as:
>>>>>>>>>>
>>>>>>>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>>>>>>>> I call the artifact corrupt (regarding Maven Central
>>>>>>>>>> Compliance) if
>>>>>>>>>> the POM of the artifact does not fulfills the above
>>>>>>>>>> requirements.
>>>>>>>>>> There are corrupt ones have made it to the Central, because
>>>>>>>>>> the guard
>>>>>>>>>> was sleeping.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Correct, but changing them is not an option because it will
>>>>>>>>> destabilize builds. This is a long standing rule that we do
>>>>>>>>> not remove
>>>>>>>>> or change the contents of central.
>>>>>>>>>
>>>>>>>>> ---
>>>>>>>>> ---
>>>>>>>>> ---
>>>>>>>>> ------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---
>>>>>>>> ---
>>>>>>>> ---------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: users-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
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> - - - - - - - -
>>> | Author @ Manning Publications.
>>> | CEO @ Phamola
>>> | BGJUG-Bulgarian Java User Group Leader.
>>> | Apache Maven Developer.
>>> | Apache Jakarta PMC member.
>>> | Jakarta Cactus Lead Developer.
>>> | Codehaus Plexus Developer
>>> | Blogger: http://weblogs.java.net/blog/paranoiabla/
>>> - - - - - - - -
>>> Public PGP Key at:
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>>>
>>> ---
>>> ------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>> Thanks,
>> Jason
>> ----------------------------------------------------------
>> Jason van Zyl
>> Founder, Apache Maven
>> http://twitter.com/jvanzyl
>> ----------------------------------------------------------
>> ---------------------------------------------------------------------
>> 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
Re: a cleaned up central repository?
Posted by Paul Gier <pg...@redhat.com>.
What about creating a new legacy repository for deprecated artifacts? Stuff
that we don't want in the main repository could be moved to a new legacy repo.
This way we effectively deprecate these artifacts, but it does not require any
POM or metadata changes. Anyone that needs to use the deprecated artifacts,
could then just add the legacy repo to their repo manager or a profile in
settings.xml.
Jason van Zyl wrote:
>
> On 2009-09-25, at 5:13 AM, Petar Tahchiev wrote:
>
>> Hi all,
>>
>> I also like the idea about deprecating artifacts, or whole directory
>> structure.
>> A step forward would be to create a maven-dev-approved repositories or
>> artifacts.
>
> Exactly, this is all part of providing better information over time.
> There is no big bang cleanup that makes it all better. That is just a
> pipe dream. We just have to incrementally and diligently clean up what
> we have. Maven Central is a great resource and it needs some TLC but not
> cleansing.
>
>> Imagine you are using an outside repository that is really messed up
>> (or worse - anyone can put anything any time).
>> What maven the team could do is setup a ground base of rules, so that
>> if you want your repository to be
>> maven-dev-compliant you must follow them. Later if you are using
>> artifacts from repositories that are not
>> maven-dev-compliant, there could be a message warning you.
>> To me it doesn't really make sense to create a new repository without
>> improving the process of using the repositories.
>> Otherwise, as Brian pointed, we will end up with a new repository,
>> which has the same data, and no one is using the old repo.
>>
>> Cheers, Petar.
>>
>> Because without it doesn't really make
>> sense creating new repository and
>>
>> 2009/9/25 Stephen Connolly <st...@gmail.com>:
>>> +1 to adding deprecation metadata.
>>>
>>> -1 to having a plugin... the deprecation warnings should come from
>>> maven core itself... ok we can add a plugin for [2.0.x,2.2.1] support
>>>
>>> Also if we are adding deprecation metadata, there are a number of
>>> other little bits of metadata that should be added, e.g. version
>>> comparison scheme (since OSGI rules are different from Maven 2.x
>>> rules, we will need a way to flag which rules apply... I see this as
>>> being a rule applied to a groupId or at best a groupId:artifactId...
>>> if you want to change your version comparison rule halfway through,
>>> change the groupId or the artifactId)
>>>
>>> -Stephen
>>>
>>> 2009/9/25 Anders Kristian Andersen <an...@gmail.com>:
>>>> I think it is TOTAL important we keep the contract:
>>>> *** This is a long standing rule that we do not remove or change the
>>>> contents of central ***
>>>>
>>>> Therefore a way out could be to start making deprecated tags in the
>>>> directories.
>>>> Then we could come up with a *** maven-deprected-dependency-plugin
>>>> *** that
>>>> could warn users against various bad / deprecated / moved artifacts.
>>>>
>>>> Consider a director xxxx with pom.xml and other files.
>>>>
>>>> adding a file called deprecated.xml could deprecate the directory /
>>>> parts of
>>>> the files etc.
>>>>
>>>> then running
>>>>
>>>> mvn deprected-dependency:check
>>>> would list usage
>>>>
>>>> This could be combined with options / tools in archiva could help too.
>>>>
>>>> best regards
>>>> Anders Kristian Andersen
>>>>
>>>>
>>>>
>>>>
>>>> On 25/09/2009, at 06.11, Brian Fox wrote:
>>>>
>>>>> This has already been done once in history, between M1 and M2 and look
>>>>> how we still have that mess to deal with all the time. Doing this
>>>>> again serves no one well, making sure new data coming in is clean is
>>>>> more productive for everyone. Who would _want_ to deploy their stuff
>>>>> to the "old" repo? No one. The hurdle to get to the new repo would be
>>>>> the same as putting the checks on the current repo for all new
>>>>> artifacts.
>>>>>
>>>>> On Thu, Sep 24, 2009 at 8:37 PM, Brett Porter <br...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> Moving over to dev...
>>>>>>
>>>>>> So here's a thought - why don't we create a "new" central repository?
>>>>>>
>>>>>> - a new repository with strict acceptance rules regarding POMs,
>>>>>> signatures,
>>>>>> ownership, etc.
>>>>>> - if there's a new metadata format needed (recently discussed), this
>>>>>> would
>>>>>> use it
>>>>>> - validated artifacts could be moved over and requests to the old
>>>>>> rewritten
>>>>>> (in the same way we maintained the maven1 repo)
>>>>>> - default Maven can ship with both repositories enabled, but a "best
>>>>>> practice" would be to turn old central off (or better, use a
>>>>>> repository
>>>>>> manager that doesn't access it / only access it for acceptable
>>>>>> artifacts)
>>>>>>
>>>>>> The main issue is finding a way to overcome confusion when an
>>>>>> artifact is
>>>>>> changed - you want "old" builds to keep using the same one it
>>>>>> always did,
>>>>>> but new builds to use the new one (and cope with potential
>>>>>> revision of
>>>>>> metadata without breaking builds). This is the sort of thing that
>>>>>> could
>>>>>> be
>>>>>> built into Maven in a new version and the new repo format only
>>>>>> accessible
>>>>>> from that version.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Cheers,
>>>>>> Brett
>>>>>>
>>>>>> On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
>>>>>>
>>>>>>> Jason and Brian, thanks for the explanations.
>>>>>>> Understood, the policy of not removing anything from Maven Central
>>>>>>> serves a purpose.
>>>>>>>
>>>>>>> I wish there would be another publicly Maven repository, which is
>>>>>>> maintained with rules enforced. This repo could even have a rule
>>>>>>> (additional to the old and unenforced rules) that only Maven built
>>>>>>> projects can enter, maybe even more restriction: only the designated
>>>>>>> Continuous Integration server can upload to it.
>>>>>>> This pure Maven repo would not be able to compete with Maven Central
>>>>>>> regarding size or the number of artifacts, but some OSS developers
>>>>>>> might prefer to use from and supply to this one instead of the
>>>>>>> big and
>>>>>>> ugly.
>>>>>>>
>>>>>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz
>>>>>>>> <al...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Requirements for the POMs are defined as:
>>>>>>>>>
>>>>>>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>>>>>>>
>>>>>>>>> I call the artifact corrupt (regarding Maven Central
>>>>>>>>> Compliance) if
>>>>>>>>> the POM of the artifact does not fulfills the above requirements.
>>>>>>>>> There are corrupt ones have made it to the Central, because the
>>>>>>>>> guard
>>>>>>>>> was sleeping.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Correct, but changing them is not an option because it will
>>>>>>>> destabilize builds. This is a long standing rule that we do not
>>>>>>>> remove
>>>>>>>> or change the contents of central.
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-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
>>>
>>>
>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> - - - - - - - -
>> | Author @ Manning Publications.
>> | CEO @ Phamola
>> | BGJUG-Bulgarian Java User Group Leader.
>> | Apache Maven Developer.
>> | Apache Jakarta PMC member.
>> | Jakarta Cactus Lead Developer.
>> | Codehaus Plexus Developer
>> | Blogger: http://weblogs.java.net/blog/paranoiabla/
>> - - - - - - - -
>> Public PGP Key at:
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> 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
Re: a cleaned up central repository? (was: Maven Central Repository - Cleanup Efforts)
Posted by Jason van Zyl <jv...@sonatype.com>.
On 2009-09-25, at 5:13 AM, Petar Tahchiev wrote:
> Hi all,
>
> I also like the idea about deprecating artifacts, or whole directory
> structure.
> A step forward would be to create a maven-dev-approved repositories or
> artifacts.
Exactly, this is all part of providing better information over time.
There is no big bang cleanup that makes it all better. That is just a
pipe dream. We just have to incrementally and diligently clean up what
we have. Maven Central is a great resource and it needs some TLC but
not cleansing.
> Imagine you are using an outside repository that is really messed up
> (or worse - anyone can put anything any time).
> What maven the team could do is setup a ground base of rules, so that
> if you want your repository to be
> maven-dev-compliant you must follow them. Later if you are using
> artifacts from repositories that are not
> maven-dev-compliant, there could be a message warning you.
> To me it doesn't really make sense to create a new repository without
> improving the process of using the repositories.
> Otherwise, as Brian pointed, we will end up with a new repository,
> which has the same data, and no one is using the old repo.
>
> Cheers, Petar.
>
> Because without it doesn't really make
> sense creating new repository and
>
> 2009/9/25 Stephen Connolly <st...@gmail.com>:
>> +1 to adding deprecation metadata.
>>
>> -1 to having a plugin... the deprecation warnings should come from
>> maven core itself... ok we can add a plugin for [2.0.x,2.2.1] support
>>
>> Also if we are adding deprecation metadata, there are a number of
>> other little bits of metadata that should be added, e.g. version
>> comparison scheme (since OSGI rules are different from Maven 2.x
>> rules, we will need a way to flag which rules apply... I see this as
>> being a rule applied to a groupId or at best a groupId:artifactId...
>> if you want to change your version comparison rule halfway through,
>> change the groupId or the artifactId)
>>
>> -Stephen
>>
>> 2009/9/25 Anders Kristian Andersen <anders.kristian.andersen@gmail.com
>> >:
>>> I think it is TOTAL important we keep the contract:
>>> *** This is a long standing rule that we do not remove or change the
>>> contents of central ***
>>>
>>> Therefore a way out could be to start making deprecated tags in the
>>> directories.
>>> Then we could come up with a *** maven-deprected-dependency-
>>> plugin *** that
>>> could warn users against various bad / deprecated / moved artifacts.
>>>
>>> Consider a director xxxx with pom.xml and other files.
>>>
>>> adding a file called deprecated.xml could deprecate the
>>> directory / parts of
>>> the files etc.
>>>
>>> then running
>>>
>>> mvn deprected-dependency:check
>>> would list usage
>>>
>>> This could be combined with options / tools in archiva could help
>>> too.
>>>
>>> best regards
>>> Anders Kristian Andersen
>>>
>>>
>>>
>>>
>>> On 25/09/2009, at 06.11, Brian Fox wrote:
>>>
>>>> This has already been done once in history, between M1 and M2 and
>>>> look
>>>> how we still have that mess to deal with all the time. Doing this
>>>> again serves no one well, making sure new data coming in is clean
>>>> is
>>>> more productive for everyone. Who would _want_ to deploy their
>>>> stuff
>>>> to the "old" repo? No one. The hurdle to get to the new repo
>>>> would be
>>>> the same as putting the checks on the current repo for all new
>>>> artifacts.
>>>>
>>>> On Thu, Sep 24, 2009 at 8:37 PM, Brett Porter <br...@apache.org>
>>>> wrote:
>>>>>
>>>>> Moving over to dev...
>>>>>
>>>>> So here's a thought - why don't we create a "new" central
>>>>> repository?
>>>>>
>>>>> - a new repository with strict acceptance rules regarding POMs,
>>>>> signatures,
>>>>> ownership, etc.
>>>>> - if there's a new metadata format needed (recently discussed),
>>>>> this
>>>>> would
>>>>> use it
>>>>> - validated artifacts could be moved over and requests to the old
>>>>> rewritten
>>>>> (in the same way we maintained the maven1 repo)
>>>>> - default Maven can ship with both repositories enabled, but a
>>>>> "best
>>>>> practice" would be to turn old central off (or better, use a
>>>>> repository
>>>>> manager that doesn't access it / only access it for acceptable
>>>>> artifacts)
>>>>>
>>>>> The main issue is finding a way to overcome confusion when an
>>>>> artifact is
>>>>> changed - you want "old" builds to keep using the same one it
>>>>> always did,
>>>>> but new builds to use the new one (and cope with potential
>>>>> revision of
>>>>> metadata without breaking builds). This is the sort of thing
>>>>> that could
>>>>> be
>>>>> built into Maven in a new version and the new repo format only
>>>>> accessible
>>>>> from that version.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Cheers,
>>>>> Brett
>>>>>
>>>>> On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
>>>>>
>>>>>> Jason and Brian, thanks for the explanations.
>>>>>> Understood, the policy of not removing anything from Maven
>>>>>> Central
>>>>>> serves a purpose.
>>>>>>
>>>>>> I wish there would be another publicly Maven repository, which is
>>>>>> maintained with rules enforced. This repo could even have a rule
>>>>>> (additional to the old and unenforced rules) that only Maven
>>>>>> built
>>>>>> projects can enter, maybe even more restriction: only the
>>>>>> designated
>>>>>> Continuous Integration server can upload to it.
>>>>>> This pure Maven repo would not be able to compete with Maven
>>>>>> Central
>>>>>> regarding size or the number of artifacts, but some OSS
>>>>>> developers
>>>>>> might prefer to use from and supply to this one instead of the
>>>>>> big and
>>>>>> ugly.
>>>>>>
>>>>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu>
>>>>>> wrote:
>>>>>>>
>>>>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz
>>>>>>> <al...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Requirements for the POMs are defined as:
>>>>>>>>
>>>>>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>>>>>> I call the artifact corrupt (regarding Maven Central
>>>>>>>> Compliance) if
>>>>>>>> the POM of the artifact does not fulfills the above
>>>>>>>> requirements.
>>>>>>>> There are corrupt ones have made it to the Central, because
>>>>>>>> the guard
>>>>>>>> was sleeping.
>>>>>>>>
>>>>>>>
>>>>>>> Correct, but changing them is not an option because it will
>>>>>>> destabilize builds. This is a long standing rule that we do
>>>>>>> not remove
>>>>>>> or change the contents of central.
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-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
>>
>>
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> - - - - - - - -
> | Author @ Manning Publications.
> | CEO @ Phamola
> | BGJUG-Bulgarian Java User Group Leader.
> | Apache Maven Developer.
> | Apache Jakarta PMC member.
> | Jakarta Cactus Lead Developer.
> | Codehaus Plexus Developer
> | Blogger: http://weblogs.java.net/blog/paranoiabla/
> - - - - - - - -
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository? (was: Maven Central Repository -
Cleanup Efforts)
Posted by Petar Tahchiev <pa...@gmail.com>.
Hi all,
I also like the idea about deprecating artifacts, or whole directory structure.
A step forward would be to create a maven-dev-approved repositories or
artifacts.
Imagine you are using an outside repository that is really messed up
(or worse - anyone can put anything any time).
What maven the team could do is setup a ground base of rules, so that
if you want your repository to be
maven-dev-compliant you must follow them. Later if you are using
artifacts from repositories that are not
maven-dev-compliant, there could be a message warning you.
To me it doesn't really make sense to create a new repository without
improving the process of using the repositories.
Otherwise, as Brian pointed, we will end up with a new repository,
which has the same data, and no one is using the old repo.
Cheers, Petar.
Because without it doesn't really make
sense creating new repository and
2009/9/25 Stephen Connolly <st...@gmail.com>:
> +1 to adding deprecation metadata.
>
> -1 to having a plugin... the deprecation warnings should come from
> maven core itself... ok we can add a plugin for [2.0.x,2.2.1] support
>
> Also if we are adding deprecation metadata, there are a number of
> other little bits of metadata that should be added, e.g. version
> comparison scheme (since OSGI rules are different from Maven 2.x
> rules, we will need a way to flag which rules apply... I see this as
> being a rule applied to a groupId or at best a groupId:artifactId...
> if you want to change your version comparison rule halfway through,
> change the groupId or the artifactId)
>
> -Stephen
>
> 2009/9/25 Anders Kristian Andersen <an...@gmail.com>:
>> I think it is TOTAL important we keep the contract:
>> *** This is a long standing rule that we do not remove or change the
>> contents of central ***
>>
>> Therefore a way out could be to start making deprecated tags in the
>> directories.
>> Then we could come up with a *** maven-deprected-dependency-plugin *** that
>> could warn users against various bad / deprecated / moved artifacts.
>>
>> Consider a director xxxx with pom.xml and other files.
>>
>> adding a file called deprecated.xml could deprecate the directory / parts of
>> the files etc.
>>
>> then running
>>
>> mvn deprected-dependency:check
>> would list usage
>>
>> This could be combined with options / tools in archiva could help too.
>>
>> best regards
>> Anders Kristian Andersen
>>
>>
>>
>>
>> On 25/09/2009, at 06.11, Brian Fox wrote:
>>
>>> This has already been done once in history, between M1 and M2 and look
>>> how we still have that mess to deal with all the time. Doing this
>>> again serves no one well, making sure new data coming in is clean is
>>> more productive for everyone. Who would _want_ to deploy their stuff
>>> to the "old" repo? No one. The hurdle to get to the new repo would be
>>> the same as putting the checks on the current repo for all new
>>> artifacts.
>>>
>>> On Thu, Sep 24, 2009 at 8:37 PM, Brett Porter <br...@apache.org> wrote:
>>>>
>>>> Moving over to dev...
>>>>
>>>> So here's a thought - why don't we create a "new" central repository?
>>>>
>>>> - a new repository with strict acceptance rules regarding POMs,
>>>> signatures,
>>>> ownership, etc.
>>>> - if there's a new metadata format needed (recently discussed), this
>>>> would
>>>> use it
>>>> - validated artifacts could be moved over and requests to the old
>>>> rewritten
>>>> (in the same way we maintained the maven1 repo)
>>>> - default Maven can ship with both repositories enabled, but a "best
>>>> practice" would be to turn old central off (or better, use a repository
>>>> manager that doesn't access it / only access it for acceptable artifacts)
>>>>
>>>> The main issue is finding a way to overcome confusion when an artifact is
>>>> changed - you want "old" builds to keep using the same one it always did,
>>>> but new builds to use the new one (and cope with potential revision of
>>>> metadata without breaking builds). This is the sort of thing that could
>>>> be
>>>> built into Maven in a new version and the new repo format only accessible
>>>> from that version.
>>>>
>>>> Thoughts?
>>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>> On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
>>>>
>>>>> Jason and Brian, thanks for the explanations.
>>>>> Understood, the policy of not removing anything from Maven Central
>>>>> serves a purpose.
>>>>>
>>>>> I wish there would be another publicly Maven repository, which is
>>>>> maintained with rules enforced. This repo could even have a rule
>>>>> (additional to the old and unenforced rules) that only Maven built
>>>>> projects can enter, maybe even more restriction: only the designated
>>>>> Continuous Integration server can upload to it.
>>>>> This pure Maven repo would not be able to compete with Maven Central
>>>>> regarding size or the number of artifacts, but some OSS developers
>>>>> might prefer to use from and supply to this one instead of the big and
>>>>> ugly.
>>>>>
>>>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu> wrote:
>>>>>>
>>>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz
>>>>>> <al...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Requirements for the POMs are defined as:
>>>>>>>
>>>>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>>>>> I call the artifact corrupt (regarding Maven Central Compliance) if
>>>>>>> the POM of the artifact does not fulfills the above requirements.
>>>>>>> There are corrupt ones have made it to the Central, because the guard
>>>>>>> was sleeping.
>>>>>>>
>>>>>>
>>>>>> Correct, but changing them is not an option because it will
>>>>>> destabilize builds. This is a long standing rule that we do not remove
>>>>>> or change the contents of central.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-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
>
>
--
Regards, Petar!
Karlovo, Bulgaria.
- - - - - - - -
| Author @ Manning Publications.
| CEO @ Phamola
| BGJUG-Bulgarian Java User Group Leader.
| Apache Maven Developer.
| Apache Jakarta PMC member.
| Jakarta Cactus Lead Developer.
| Codehaus Plexus Developer
| Blogger: http://weblogs.java.net/blog/paranoiabla/
- - - - - - - -
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: a cleaned up central repository? (was: Maven Central Repository -
Cleanup Efforts)
Posted by Stephen Connolly <st...@gmail.com>.
+1 to adding deprecation metadata.
-1 to having a plugin... the deprecation warnings should come from
maven core itself... ok we can add a plugin for [2.0.x,2.2.1] support
Also if we are adding deprecation metadata, there are a number of
other little bits of metadata that should be added, e.g. version
comparison scheme (since OSGI rules are different from Maven 2.x
rules, we will need a way to flag which rules apply... I see this as
being a rule applied to a groupId or at best a groupId:artifactId...
if you want to change your version comparison rule halfway through,
change the groupId or the artifactId)
-Stephen
2009/9/25 Anders Kristian Andersen <an...@gmail.com>:
> I think it is TOTAL important we keep the contract:
> *** This is a long standing rule that we do not remove or change the
> contents of central ***
>
> Therefore a way out could be to start making deprecated tags in the
> directories.
> Then we could come up with a *** maven-deprected-dependency-plugin *** that
> could warn users against various bad / deprecated / moved artifacts.
>
> Consider a director xxxx with pom.xml and other files.
>
> adding a file called deprecated.xml could deprecate the directory / parts of
> the files etc.
>
> then running
>
> mvn deprected-dependency:check
> would list usage
>
> This could be combined with options / tools in archiva could help too.
>
> best regards
> Anders Kristian Andersen
>
>
>
>
> On 25/09/2009, at 06.11, Brian Fox wrote:
>
>> This has already been done once in history, between M1 and M2 and look
>> how we still have that mess to deal with all the time. Doing this
>> again serves no one well, making sure new data coming in is clean is
>> more productive for everyone. Who would _want_ to deploy their stuff
>> to the "old" repo? No one. The hurdle to get to the new repo would be
>> the same as putting the checks on the current repo for all new
>> artifacts.
>>
>> On Thu, Sep 24, 2009 at 8:37 PM, Brett Porter <br...@apache.org> wrote:
>>>
>>> Moving over to dev...
>>>
>>> So here's a thought - why don't we create a "new" central repository?
>>>
>>> - a new repository with strict acceptance rules regarding POMs,
>>> signatures,
>>> ownership, etc.
>>> - if there's a new metadata format needed (recently discussed), this
>>> would
>>> use it
>>> - validated artifacts could be moved over and requests to the old
>>> rewritten
>>> (in the same way we maintained the maven1 repo)
>>> - default Maven can ship with both repositories enabled, but a "best
>>> practice" would be to turn old central off (or better, use a repository
>>> manager that doesn't access it / only access it for acceptable artifacts)
>>>
>>> The main issue is finding a way to overcome confusion when an artifact is
>>> changed - you want "old" builds to keep using the same one it always did,
>>> but new builds to use the new one (and cope with potential revision of
>>> metadata without breaking builds). This is the sort of thing that could
>>> be
>>> built into Maven in a new version and the new repo format only accessible
>>> from that version.
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>> Brett
>>>
>>> On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
>>>
>>>> Jason and Brian, thanks for the explanations.
>>>> Understood, the policy of not removing anything from Maven Central
>>>> serves a purpose.
>>>>
>>>> I wish there would be another publicly Maven repository, which is
>>>> maintained with rules enforced. This repo could even have a rule
>>>> (additional to the old and unenforced rules) that only Maven built
>>>> projects can enter, maybe even more restriction: only the designated
>>>> Continuous Integration server can upload to it.
>>>> This pure Maven repo would not be able to compete with Maven Central
>>>> regarding size or the number of artifacts, but some OSS developers
>>>> might prefer to use from and supply to this one instead of the big and
>>>> ugly.
>>>>
>>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu> wrote:
>>>>>
>>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz
>>>>> <al...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Requirements for the POMs are defined as:
>>>>>>
>>>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>>>> I call the artifact corrupt (regarding Maven Central Compliance) if
>>>>>> the POM of the artifact does not fulfills the above requirements.
>>>>>> There are corrupt ones have made it to the Central, because the guard
>>>>>> was sleeping.
>>>>>>
>>>>>
>>>>> Correct, but changing them is not an option because it will
>>>>> destabilize builds. This is a long standing rule that we do not remove
>>>>> or change the contents of central.
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-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
Re: a cleaned up central repository? (was: Maven Central Repository - Cleanup Efforts)
Posted by Anders Kristian Andersen <an...@gmail.com>.
I think it is TOTAL important we keep the contract:
*** This is a long standing rule that we do not remove or change the
contents of central ***
Therefore a way out could be to start making deprecated tags in the
directories.
Then we could come up with a *** maven-deprected-dependency-plugin
*** that
could warn users against various bad / deprecated / moved artifacts.
Consider a director xxxx with pom.xml and other files.
adding a file called deprecated.xml could deprecate the directory /
parts of the files etc.
then running
mvn deprected-dependency:check
would list usage
This could be combined with options / tools in archiva could help too.
best regards
Anders Kristian Andersen
On 25/09/2009, at 06.11, Brian Fox wrote:
> This has already been done once in history, between M1 and M2 and look
> how we still have that mess to deal with all the time. Doing this
> again serves no one well, making sure new data coming in is clean is
> more productive for everyone. Who would _want_ to deploy their stuff
> to the "old" repo? No one. The hurdle to get to the new repo would be
> the same as putting the checks on the current repo for all new
> artifacts.
>
> On Thu, Sep 24, 2009 at 8:37 PM, Brett Porter <br...@apache.org>
> wrote:
>> Moving over to dev...
>>
>> So here's a thought - why don't we create a "new" central repository?
>>
>> - a new repository with strict acceptance rules regarding POMs,
>> signatures,
>> ownership, etc.
>> - if there's a new metadata format needed (recently discussed),
>> this would
>> use it
>> - validated artifacts could be moved over and requests to the old
>> rewritten
>> (in the same way we maintained the maven1 repo)
>> - default Maven can ship with both repositories enabled, but a "best
>> practice" would be to turn old central off (or better, use a
>> repository
>> manager that doesn't access it / only access it for acceptable
>> artifacts)
>>
>> The main issue is finding a way to overcome confusion when an
>> artifact is
>> changed - you want "old" builds to keep using the same one it
>> always did,
>> but new builds to use the new one (and cope with potential revision
>> of
>> metadata without breaking builds). This is the sort of thing that
>> could be
>> built into Maven in a new version and the new repo format only
>> accessible
>> from that version.
>>
>> Thoughts?
>>
>> Cheers,
>> Brett
>>
>> On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
>>
>>> Jason and Brian, thanks for the explanations.
>>> Understood, the policy of not removing anything from Maven Central
>>> serves a purpose.
>>>
>>> I wish there would be another publicly Maven repository, which is
>>> maintained with rules enforced. This repo could even have a rule
>>> (additional to the old and unenforced rules) that only Maven built
>>> projects can enter, maybe even more restriction: only the designated
>>> Continuous Integration server can upload to it.
>>> This pure Maven repo would not be able to compete with Maven Central
>>> regarding size or the number of artifacts, but some OSS developers
>>> might prefer to use from and supply to this one instead of the big
>>> and
>>> ugly.
>>>
>>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu>
>>> wrote:
>>>>
>>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <albert.kurucz@gmail.com
>>>> >
>>>> wrote:
>>>>>
>>>>> Requirements for the POMs are defined as:
>>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>>> I call the artifact corrupt (regarding Maven Central Compliance)
>>>>> if
>>>>> the POM of the artifact does not fulfills the above requirements.
>>>>> There are corrupt ones have made it to the Central, because the
>>>>> guard
>>>>> was sleeping.
>>>>>
>>>>
>>>> Correct, but changing them is not an option because it will
>>>> destabilize builds. This is a long standing rule that we do not
>>>> remove
>>>> or change the contents of central.
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-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
>
Re: a cleaned up central repository? (was: Maven Central Repository -
Cleanup Efforts)
Posted by Brian Fox <br...@infinity.nu>.
This has already been done once in history, between M1 and M2 and look
how we still have that mess to deal with all the time. Doing this
again serves no one well, making sure new data coming in is clean is
more productive for everyone. Who would _want_ to deploy their stuff
to the "old" repo? No one. The hurdle to get to the new repo would be
the same as putting the checks on the current repo for all new
artifacts.
On Thu, Sep 24, 2009 at 8:37 PM, Brett Porter <br...@apache.org> wrote:
> Moving over to dev...
>
> So here's a thought - why don't we create a "new" central repository?
>
> - a new repository with strict acceptance rules regarding POMs, signatures,
> ownership, etc.
> - if there's a new metadata format needed (recently discussed), this would
> use it
> - validated artifacts could be moved over and requests to the old rewritten
> (in the same way we maintained the maven1 repo)
> - default Maven can ship with both repositories enabled, but a "best
> practice" would be to turn old central off (or better, use a repository
> manager that doesn't access it / only access it for acceptable artifacts)
>
> The main issue is finding a way to overcome confusion when an artifact is
> changed - you want "old" builds to keep using the same one it always did,
> but new builds to use the new one (and cope with potential revision of
> metadata without breaking builds). This is the sort of thing that could be
> built into Maven in a new version and the new repo format only accessible
> from that version.
>
> Thoughts?
>
> Cheers,
> Brett
>
> On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
>
>> Jason and Brian, thanks for the explanations.
>> Understood, the policy of not removing anything from Maven Central
>> serves a purpose.
>>
>> I wish there would be another publicly Maven repository, which is
>> maintained with rules enforced. This repo could even have a rule
>> (additional to the old and unenforced rules) that only Maven built
>> projects can enter, maybe even more restriction: only the designated
>> Continuous Integration server can upload to it.
>> This pure Maven repo would not be able to compete with Maven Central
>> regarding size or the number of artifacts, but some OSS developers
>> might prefer to use from and supply to this one instead of the big and
>> ugly.
>>
>> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu> wrote:
>>>
>>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <al...@gmail.com>
>>> wrote:
>>>>
>>>> Requirements for the POMs are defined as:
>>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>>> I call the artifact corrupt (regarding Maven Central Compliance) if
>>>> the POM of the artifact does not fulfills the above requirements.
>>>> There are corrupt ones have made it to the Central, because the guard
>>>> was sleeping.
>>>>
>>>
>>> Correct, but changing them is not an option because it will
>>> destabilize builds. This is a long standing rule that we do not remove
>>> or change the contents of central.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-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
a cleaned up central repository? (was: Maven Central Repository - Cleanup Efforts)
Posted by Brett Porter <br...@apache.org>.
Moving over to dev...
So here's a thought - why don't we create a "new" central repository?
- a new repository with strict acceptance rules regarding POMs,
signatures, ownership, etc.
- if there's a new metadata format needed (recently discussed), this
would use it
- validated artifacts could be moved over and requests to the old
rewritten (in the same way we maintained the maven1 repo)
- default Maven can ship with both repositories enabled, but a "best
practice" would be to turn old central off (or better, use a
repository manager that doesn't access it / only access it for
acceptable artifacts)
The main issue is finding a way to overcome confusion when an artifact
is changed - you want "old" builds to keep using the same one it
always did, but new builds to use the new one (and cope with potential
revision of metadata without breaking builds). This is the sort of
thing that could be built into Maven in a new version and the new repo
format only accessible from that version.
Thoughts?
Cheers,
Brett
On 25/09/2009, at 12:52 PM, Albert Kurucz wrote:
> Jason and Brian, thanks for the explanations.
> Understood, the policy of not removing anything from Maven Central
> serves a purpose.
>
> I wish there would be another publicly Maven repository, which is
> maintained with rules enforced. This repo could even have a rule
> (additional to the old and unenforced rules) that only Maven built
> projects can enter, maybe even more restriction: only the designated
> Continuous Integration server can upload to it.
> This pure Maven repo would not be able to compete with Maven Central
> regarding size or the number of artifacts, but some OSS developers
> might prefer to use from and supply to this one instead of the big and
> ugly.
>
> On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu> wrote:
>> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <albert.kurucz@gmail.com
>> > wrote:
>>> Requirements for the POMs are defined as:
>>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>> I call the artifact corrupt (regarding Maven Central Compliance) if
>>> the POM of the artifact does not fulfills the above requirements.
>>> There are corrupt ones have made it to the Central, because the
>>> guard
>>> was sleeping.
>>>
>>
>> Correct, but changing them is not an option because it will
>> destabilize builds. This is a long standing rule that we do not
>> remove
>> or change the contents of central.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
Jason and Brian, thanks for the explanations.
Understood, the policy of not removing anything from Maven Central
serves a purpose.
I wish there would be another publicly Maven repository, which is
maintained with rules enforced. This repo could even have a rule
(additional to the old and unenforced rules) that only Maven built
projects can enter, maybe even more restriction: only the designated
Continuous Integration server can upload to it.
This pure Maven repo would not be able to compete with Maven Central
regarding size or the number of artifacts, but some OSS developers
might prefer to use from and supply to this one instead of the big and
ugly.
On Thu, Sep 24, 2009 at 6:44 PM, Brian Fox <br...@infinity.nu> wrote:
> On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <al...@gmail.com> wrote:
>> Requirements for the POMs are defined as:
>> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>> I call the artifact corrupt (regarding Maven Central Compliance) if
>> the POM of the artifact does not fulfills the above requirements.
>> There are corrupt ones have made it to the Central, because the guard
>> was sleeping.
>>
>
> Correct, but changing them is not an option because it will
> destabilize builds. This is a long standing rule that we do not remove
> or change the contents of central.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Brian Fox <br...@infinity.nu>.
On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz <al...@gmail.com> wrote:
> Requirements for the POMs are defined as:
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> I call the artifact corrupt (regarding Maven Central Compliance) if
> the POM of the artifact does not fulfills the above requirements.
> There are corrupt ones have made it to the Central, because the guard
> was sleeping.
>
Correct, but changing them is not an option because it will
destabilize builds. This is a long standing rule that we do not remove
or change the contents of central.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
Requirements for the POMs are defined as:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
I call the artifact corrupt (regarding Maven Central Compliance) if
the POM of the artifact does not fulfills the above requirements.
There are corrupt ones have made it to the Central, because the guard
was sleeping.
Rules are enforced or here comes the anarchy...
The severity of the damage?
The Central should be an example of good practice. Otherwise...
On Thu, Sep 24, 2009 at 4:41 PM, Brian Fox <br...@infinity.nu> wrote:
> On Thu, Sep 24, 2009 at 12:04 PM, Albert Kurucz <al...@gmail.com> wrote:
>> Brian,
>> Probably no one ever suggested that the corrupt artifacts should be
>> fixed, because fixing is not even possible (every artifact must be
>> signed by the creator).
>> The question is whether you prefer the corrupt ones to be removed or
>> just wait until they become obsolete and no one would care about that
>> they stay or not (quantity or quality has the priority?).
>
> To take this further you must define corrupt. If something is
> demonstrated truly and completely broken and/or dangerous, it will be
> removed immediately. If a pom is missing a dependency, that doesn't
> qualify, it's up to the project to fix and produce a new release in
> that case.
>
>> The work on preventing the ugly ones from getting in I agree has the
>> first priority.
>> But will you address (and when?) this second most important task, the
>> garbage collection?
>
> We are actively working on technology to address this, expect details
> in the near future. What do you mean by garbage collection?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Brian Fox <br...@infinity.nu>.
On Thu, Sep 24, 2009 at 12:04 PM, Albert Kurucz <al...@gmail.com> wrote:
> Brian,
> Probably no one ever suggested that the corrupt artifacts should be
> fixed, because fixing is not even possible (every artifact must be
> signed by the creator).
> The question is whether you prefer the corrupt ones to be removed or
> just wait until they become obsolete and no one would care about that
> they stay or not (quantity or quality has the priority?).
To take this further you must define corrupt. If something is
demonstrated truly and completely broken and/or dangerous, it will be
removed immediately. If a pom is missing a dependency, that doesn't
qualify, it's up to the project to fix and produce a new release in
that case.
> The work on preventing the ugly ones from getting in I agree has the
> first priority.
> But will you address (and when?) this second most important task, the
> garbage collection?
We are actively working on technology to address this, expect details
in the near future. What do you mean by garbage collection?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
Brian,
Probably no one ever suggested that the corrupt artifacts should be
fixed, because fixing is not even possible (every artifact must be
signed by the creator).
The question is whether you prefer the corrupt ones to be removed or
just wait until they become obsolete and no one would care about that
they stay or not (quantity or quality has the priority?).
The work on preventing the ugly ones from getting in I agree has the
first priority.
But will you address (and when?) this second most important task, the
garbage collection?
On Thu, Sep 24, 2009 at 1:13 PM, Brian Fox <br...@infinity.nu> wrote:
> The MEV project on jira.codehaus.org is where we collect data to fix
> these known issues. In general the policy is not to change existing
> files (checksums is one exception), and also we need to be careful to
> not insert pom files in place of missing ones. Even doing this can
> cause user's builds to change in subtle ways.
>
> There are plans to get some of this cleaned up and mainly focus on
> stopping the garbage from getting in there in the first place.
>
> On Thu, Sep 24, 2009 at 7:40 AM, Albert Kurucz <al...@gmail.com> wrote:
>> According to 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.
>> "
>>
>> There are some artifacts on the Maven Central Repo, with corrupt meta data.
>> Is there an issue tracker where such corrupt artifacts could be reported?
>>
>> What is the policy of Sonatype handling this issue?
>> 1. Will corrupt artifacts be removed (causing a chain reaction,
>> because Central hosted dependents will loose their dependencies, which
>> are required to be also on Central)?
>> 2. Or is it in Sonatype's plan to start a new Central Repo, which is
>> now better scanned?
>> 3. Or ignorance?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Brian Fox <br...@infinity.nu>.
On Thu, Sep 24, 2009 at 12:18 PM, Albert Kurucz <al...@gmail.com> wrote:
> Brian,
> MEV is for "Maven Evangelism" issues.
> Are you sure maintenance issues of any given repo should belong to that?
>
For any given repo no, for Central, yes.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Albert Kurucz <al...@gmail.com>.
Brian,
MEV is for "Maven Evangelism" issues.
Are you sure maintenance issues of any given repo should belong to that?
On Thu, Sep 24, 2009 at 1:13 PM, Brian Fox <br...@infinity.nu> wrote:
> The MEV project on jira.codehaus.org is where we collect data to fix
> these known issues. In general the policy is not to change existing
> files (checksums is one exception), and also we need to be careful to
> not insert pom files in place of missing ones. Even doing this can
> cause user's builds to change in subtle ways.
>
> There are plans to get some of this cleaned up and mainly focus on
> stopping the garbage from getting in there in the first place.
>
> On Thu, Sep 24, 2009 at 7:40 AM, Albert Kurucz <al...@gmail.com> wrote:
>> According to 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.
>> "
>>
>> There are some artifacts on the Maven Central Repo, with corrupt meta data.
>> Is there an issue tracker where such corrupt artifacts could be reported?
>>
>> What is the policy of Sonatype handling this issue?
>> 1. Will corrupt artifacts be removed (causing a chain reaction,
>> because Central hosted dependents will loose their dependencies, which
>> are required to be also on Central)?
>> 2. Or is it in Sonatype's plan to start a new Central Repo, which is
>> now better scanned?
>> 3. Or ignorance?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
Posted by Brian Fox <br...@infinity.nu>.
The MEV project on jira.codehaus.org is where we collect data to fix
these known issues. In general the policy is not to change existing
files (checksums is one exception), and also we need to be careful to
not insert pom files in place of missing ones. Even doing this can
cause user's builds to change in subtle ways.
There are plans to get some of this cleaned up and mainly focus on
stopping the garbage from getting in there in the first place.
On Thu, Sep 24, 2009 at 7:40 AM, Albert Kurucz <al...@gmail.com> wrote:
> According to 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.
> "
>
> There are some artifacts on the Maven Central Repo, with corrupt meta data.
> Is there an issue tracker where such corrupt artifacts could be reported?
>
> What is the policy of Sonatype handling this issue?
> 1. Will corrupt artifacts be removed (causing a chain reaction,
> because Central hosted dependents will loose their dependencies, which
> are required to be also on Central)?
> 2. Or is it in Sonatype's plan to start a new Central Repo, which is
> now better scanned?
> 3. Or ignorance?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org