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-unsubscr...@maven.apache.org
For additional commands, e-mail:
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 albert.kur...@gmail.com wrote:
Then make your own repository. See how useful that is.
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
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
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 albert.kur...@gmail.com wrote:
Do you really mean that you would like to enforce such -source-release.zip
artefacts to be
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
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
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
On Mon, Sep 28, 2009 at 9:02 AM, Albert Kurucz albert.kur...@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
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
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.conno...@gmail.com wrote:
We do not allow repository definitions in pom files for a good reason.
This seemed as a good
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
- Message d'origine
De : Albert Kurucz albert.kur...@gmail.com
À : Maven Users List users@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
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
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
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
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
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
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
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
A lot of +1-es to this quote
~t~
On Sat, Sep 26, 2009 at 4:35 AM, Albert Kurucz albert.kur...@gmail.comwrote:
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:
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
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
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
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
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
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
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
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
Sent from my [rhymes with tryPod] ;-)
On 26 Sep 2009, at 18:58, Albert Kurucz albert.kur...@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
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
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
On Sat, Sep 26, 2009 at 12:11 PM, Albert Kurucz albert.kur...@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
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
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)
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
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
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.
2009/9/25 Albert Kurucz albert.kur...@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
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
Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
2009/9/25 Albert Kurucz albert.kur...@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
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
2009/9/25 Hervé BOUTEMY herve.bout...@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
2009/9/25 Hervé BOUTEMY herve.bout...@free.fr:
Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
2009/9/25 Albert Kurucz albert.kur...@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
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
On Fri, Sep 25, 2009 at 12:44 PM, Albert Kurucz albert.kur...@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:
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
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 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
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
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 bri...@infinity.nu wrote:
The MEV project on jira.codehaus.org is where we collect data to fix
these known issues. In general the
On Thu, Sep 24, 2009 at 12:18 PM, Albert Kurucz albert.kur...@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.
On Thu, Sep 24, 2009 at 12:04 PM, Albert Kurucz albert.kur...@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
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
Garbage collection?
Identify corrupted ones and remove.
On Thu, Sep 24, 2009 at 4:41 PM, Brian Fox bri...@infinity.nu wrote:
On Thu, Sep 24, 2009 at 12:04 PM, Albert Kurucz albert.kur...@gmail.com
wrote:
Brian,
Probably no one ever suggested that the corrupt artifacts should be
fixed,
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
On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz albert.kur...@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
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
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
59 matches
Mail list logo
