Re: Maven central repository
Ok thanks to both of you! Now I've been able to update (rerunning the update a couple of times) Bye, Stefano -- View this message in context: http://maven.40175.n5.nabble.com/Maven-central-repository-tp4901567p4909808.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven central repository
Hi everybody, I've been using Maven for a while, but now I'm facing a problem I can't understand. In the last days I've not been able to update index for maven central repository at http://repo1.maven.org/maven2 both from m2eclipse and from a proxy on my Nexus. Nothing changed in my network configuration, so I was wodering if there's a problem on the repo. Thanks, Stefano -- View this message in context: http://maven.40175.n5.nabble.com/Maven-central-repository-tp4901567p4901567.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven central repository
http://repo1.maven.org/maven2/.index/ redirect to http://mirrors.ibiblio.org/pub/mirrors/maven2/dot-index/ which doesn't work nice 2011/10/14 stefano.cazzola zakh...@gmail.com: Hi everybody, I've been using Maven for a while, but now I'm facing a problem I can't understand. In the last days I've not been able to update index for maven central repository at http://repo1.maven.org/maven2 both from m2eclipse and from a proxy on my Nexus. Nothing changed in my network configuration, so I was wodering if there's a problem on the repo. Thanks, Stefano -- View this message in context: http://maven.40175.n5.nabble.com/Maven-central-repository-tp4901567p4901567.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven central repository
A new version of the indexer was released and requested to be rerun over central. That means a new full index was generated, when typically it is just an incremental index. The size of the file and speed of ibiblio seems to be giving some people trouble. But it should sort itself out, besides resetting the incrmental chain, there were no changes. On Fri, Oct 14, 2011 at 3:18 AM, Olivier Lamy ol...@apache.org wrote: http://repo1.maven.org/maven2/.index/ redirect to http://mirrors.ibiblio.org/pub/mirrors/maven2/dot-index/ which doesn't work nice 2011/10/14 stefano.cazzola zakh...@gmail.com: Hi everybody, I've been using Maven for a while, but now I'm facing a problem I can't understand. In the last days I've not been able to update index for maven central repository at http://repo1.maven.org/maven2 both from m2eclipse and from a proxy on my Nexus. Nothing changed in my network configuration, so I was wodering if there's a problem on the repo. Thanks, Stefano -- View this message in context: http://maven.40175.n5.nabble.com/Maven-central-repository-tp4901567p4901567.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven Central Repository Bad Checksums
Once upon a time, I filed a JIRA at Codehaus: http://jira.codehaus.org/browse/MEV-641. Eleven months elapsed before someone finally fixed the checksum metadata to match the jar in the repository. Yesterday, I filed another pair of issues: MEV-675 and MEV-676. I was wondering if I have to wait another 11 months before they are addressed.[1] Who is handling these? Is there a labor shortage on handling these issues? Furthermore, it would seem that automating this process would be the answer, as it probably wouldn't be difficult to crawl the repository and check checksums and either (a) add them where they are missing or (b) fix them where they are there and are incorrect. If there's a need, I'll volunteer to do just that. --sgp [1] Just kidding, naturally.
Re: Maven Central Repository Bad Checksums
You should file tickets for Maven Central at [1] instead. /Anders [1] https://issues.sonatype.org/browse/MVNCENTRAL On Thu, Dec 2, 2010 at 15:21, Scott Parkerson s...@snortasprocket.netwrote: Once upon a time, I filed a JIRA at Codehaus: http://jira.codehaus.org/browse/MEV-641. Eleven months elapsed before someone finally fixed the checksum metadata to match the jar in the repository. Yesterday, I filed another pair of issues: MEV-675 and MEV-676. I was wondering if I have to wait another 11 months before they are addressed.[1] Who is handling these? Is there a labor shortage on handling these issues? Furthermore, it would seem that automating this process would be the answer, as it probably wouldn't be difficult to crawl the repository and check checksums and either (a) add them where they are missing or (b) fix them where they are there and are incorrect. If there's a need, I'll volunteer to do just that. --sgp [1] Just kidding, naturally.
Re: Maven Central Repository Bad Checksums
On Dec 2, 2010, at 10:02 AM, Anders Hammar wrote: You should file tickets for Maven Central at [1] instead. [1] https://issues.sonatype.org/browse/MVNCENTRAL Sigh. This is what I get for not reading *closely* (and assuming that things were as they were 11 months ago). So Sonatype is in charge of housekeeping for Maven Central now? I'll close my issues on the Codehaus JIRA and re-open them on Sonatype's JIRA, then. Cheers, --sgp - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository Bad Checksums
Furthermore, it would seem that automating this process would be the answer, as it probably wouldn't be difficult to crawl the repository and check checksums and either (a) add them where they are missing or (b) fix them where they are there and are incorrect. I don't think you want to automate fixing them, only detecting the problems. Because if/when an honestly bad (or compromised/hacked) jar lands in Central, you want to know about it, and not just assume it is correct and use that MD5, right? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository Bad Checksums
I don't think that checksums are for detecting compromised jars. Checksums are for checking that a file was transferred correctly, regardless of it being compromised or not. So, I also think that all checksums should be corrected. However, pgp signatures are for detecting compromised files. /Anders On Thu, Dec 2, 2010 at 17:58, Wayne Fay wayne...@gmail.com wrote: Furthermore, it would seem that automating this process would be the answer, as it probably wouldn't be difficult to crawl the repository and check checksums and either (a) add them where they are missing or (b) fix them where they are there and are incorrect. I don't think you want to automate fixing them, only detecting the problems. Because if/when an honestly bad (or compromised/hacked) jar lands in Central, you want to know about it, and not just assume it is correct and use that MD5, right? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository Bad Checksums
I don't think that checksums are for detecting compromised jars. Checksums are for checking that a file was transferred correctly, regardless of it being compromised or not. So, I also think that all checksums should be corrected. But how does a bot know that the Jar was uploaded ok into Central? Its the same problem. The checksum should be generated by the original owner of the artifact and uploaded alongside it, and any deviations should be directed back to the owner to resolve. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository Bad Checksums
We do a little bit of sleuthing when resolving these types of issues to make sure the file hasn't been changed, which is why automatic correction isn't implemented. We are working on process to ensure that no new things come in this way. It can only happen today via the old rsync mechanisms and those are deprecated and will be disabled soon anyway. On Thu, Dec 2, 2010 at 2:45 PM, Wayne Fay wayne...@gmail.com wrote: I don't think that checksums are for detecting compromised jars. Checksums are for checking that a file was transferred correctly, regardless of it being compromised or not. So, I also think that all checksums should be corrected. But how does a bot know that the Jar was uploaded ok into Central? Its the same problem. The checksum should be generated by the original owner of the artifact and uploaded alongside it, and any deviations should be directed back to the owner to resolve. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Amazon EC2 EBS Volume for Maven central repository
What's the current storage requirements for the central repository at this time? Per Jarvana, Central is around 100gb, as of mid October 2009: http://www.jarvana.com/jarvana/info/repository_statistics Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Amazon EC2 EBS Volume for Maven central repository
Ok, so, from the EBS web page...we can speculate... As an example, a medium sized website database might be 100 GB in size and expect to average 100 I/Os per second over the course of a month. This would translate to $10 per month in storage costs (100 GB x $0.10/month), and approximately $26 per month in request costs (~2.6 million seconds/month x 100 I/O per second * $0.10 per million I/O). We might seek out the Freebase folks and inquire for the what their costs are like to provide an EBS dataset. Mark On Mon, Dec 21, 2009 at 12:43 AM, Wayne Fay wayne...@gmail.com wrote: What's the current storage requirements for the central repository at this time? Per Jarvana, Central is around 100gb, as of mid October 2009: http://www.jarvana.com/jarvana/info/repository_statistics Wayne On Sun, Dec 20, 2009 at 9:09 PM, Mark Diggory mdigg...@gmail.com wrote: I imagine there have to be a number of projects/companies out there using Maven artifacts and incurring bandwidth costs to build systems. Atlassian seems to be recommending the practice to its Bamboo users... http://confluence.atlassian.com/display/BAMBOO/Populating+your+EBS+volume#PopulatingyourEBSvolume-UploadingMaven2repositorydata I know its not much, but on large builds and continuous integration projects would benefit. What's the current storage requirements for the central repository at this time? I wonder if the maven central repo could qualify as a public dataset? http://aws.amazon.com/publicdatasets/ http://developer.amazonwebservices.com/connect/forum.jspa?forumID=55 Mark On Sun, Dec 20, 2009 at 8:28 PM, Carlos Sanchez car...@apache.org wrote: there was some talk about it during ApacheCON but there are some costs associated - S3 storage of the EBS snapshot - bandwidth to upload the repo and keep it up to date - an EC2 machine to do the rsync and scheduled snapshots of the EBS volume There's an option to sell it so users end paying the fees On Sun, Dec 20, 2009 at 8:18 PM, Mark Diggory mdigg...@gmail.com wrote: Cheers, After experimenting a bit with EC2, It seems it would be ideal if there were an EBS volume that had all the Maven central repository within it. Does anyone know of such a thing? thanks, Mark
Re: Amazon EC2 EBS Volume for Maven central repository
On Mon, Dec 21, 2009 at 12:09 AM, Mark Diggory mdigg...@gmail.com wrote: I imagine there have to be a number of projects/companies out there using Maven artifacts and incurring bandwidth costs to build systems. Atlassian seems to be recommending the practice to its Bamboo users... They should just have a repo manager running in their ec2 grid anyway to reduce bandwidth. We looked into putting central into s3 but then you loose all control over the access and we would get killed by the scrapers constantly downloading everything because it's free. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Amazon EC2 EBS Volume for Maven central repository
you can set s3 buckets where requester pays http://developer.amazonwebservices.com/connect/message.jspa?messageID=123715 On Mon, Dec 21, 2009 at 9:30 AM, Brian Fox bri...@infinity.nu wrote: On Mon, Dec 21, 2009 at 12:09 AM, Mark Diggory mdigg...@gmail.com wrote: I imagine there have to be a number of projects/companies out there using Maven artifacts and incurring bandwidth costs to build systems. Atlassian seems to be recommending the practice to its Bamboo users... They should just have a repo manager running in their ec2 grid anyway to reduce bandwidth. We looked into putting central into s3 but then you loose all control over the access and we would get killed by the scrapers constantly downloading everything because it's free. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Amazon EC2 EBS Volume for Maven central repository
FYI Initiating a thread here to see its effect. http://developer.amazonwebservices.com/connect/thread.jspa?messageID=158762#158762 Cheers, Mark On Mon, Dec 21, 2009 at 10:19 AM, Carlos Sanchez car...@apache.org wrote: you can set s3 buckets where requester pays http://developer.amazonwebservices.com/connect/message.jspa?messageID=123715 On Mon, Dec 21, 2009 at 9:30 AM, Brian Fox bri...@infinity.nu wrote: On Mon, Dec 21, 2009 at 12:09 AM, Mark Diggory mdigg...@gmail.com wrote: I imagine there have to be a number of projects/companies out there using Maven artifacts and incurring bandwidth costs to build systems. Atlassian seems to be recommending the practice to its Bamboo users... They should just have a repo manager running in their ec2 grid anyway to reduce bandwidth. We looked into putting central into s3 but then you loose all control over the access and we would get killed by the scrapers constantly downloading everything because it's free.
Re: Amazon EC2 EBS Volume for Maven central repository
the problem for a public dataset it's that AFAIK they are static while the repo keeps changing On Mon, Dec 21, 2009 at 12:55 PM, Mark Diggory mdigg...@gmail.com wrote: FYI Initiating a thread here to see its effect. http://developer.amazonwebservices.com/connect/thread.jspa?messageID=158762#158762 Cheers, Mark On Mon, Dec 21, 2009 at 10:19 AM, Carlos Sanchez car...@apache.org wrote: you can set s3 buckets where requester pays http://developer.amazonwebservices.com/connect/message.jspa?messageID=123715 On Mon, Dec 21, 2009 at 9:30 AM, Brian Fox bri...@infinity.nu wrote: On Mon, Dec 21, 2009 at 12:09 AM, Mark Diggory mdigg...@gmail.com wrote: I imagine there have to be a number of projects/companies out there using Maven artifacts and incurring bandwidth costs to build systems. Atlassian seems to be recommending the practice to its Bamboo users... They should just have a repo manager running in their ec2 grid anyway to reduce bandwidth. We looked into putting central into s3 but then you loose all control over the access and we would get killed by the scrapers constantly downloading everything because it's free. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Amazon EC2 EBS Volume for Maven central repository
Cheers, After experimenting a bit with EC2, It seems it would be ideal if there were an EBS volume that had all the Maven central repository within it. Does anyone know of such a thing? thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Amazon EC2 EBS Volume for Maven central repository
I imagine there have to be a number of projects/companies out there using Maven artifacts and incurring bandwidth costs to build systems. Atlassian seems to be recommending the practice to its Bamboo users... http://confluence.atlassian.com/display/BAMBOO/Populating+your+EBS+volume#PopulatingyourEBSvolume-UploadingMaven2repositorydata I know its not much, but on large builds and continuous integration projects would benefit. What's the current storage requirements for the central repository at this time? I wonder if the maven central repo could qualify as a public dataset? http://aws.amazon.com/publicdatasets/ http://developer.amazonwebservices.com/connect/forum.jspa?forumID=55 Mark On Sun, Dec 20, 2009 at 8:28 PM, Carlos Sanchez car...@apache.org wrote: there was some talk about it during ApacheCON but there are some costs associated - S3 storage of the EBS snapshot - bandwidth to upload the repo and keep it up to date - an EC2 machine to do the rsync and scheduled snapshots of the EBS volume There's an option to sell it so users end paying the fees On Sun, Dec 20, 2009 at 8:18 PM, Mark Diggory mdigg...@gmail.com wrote: Cheers, After experimenting a bit with EC2, It seems it would be ideal if there were an EBS volume that had all the Maven central repository within it. Does anyone know of such a thing? thanks, Mark - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Help to get Android artifacts to be published to Maven central repository
As a Maven and Android user and committer with the Maven Android plugin I have created a feature request on google code to get the android jar into the maven central repository. More technical details are with the bugreport: http://bit.ly/1HoyoZ If you are a Android or Maven user I would urge you to star the issue, comment on it and or twitter about this. Getting good maven support for android would be very helpful for continuous integration builds of Android project using Maven and allow developers to take advantage of the many other features of Maven improving the quality of their project. Please help us to spread the word. Thanks manfred -- Manfred Moser Founder Vancouver Island Java User Group http://www.mosabuam.com/vijug http://twitter.com/mosabua http://www.linkedin.com/in/manfredmoser - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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. 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: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 albert.kur...@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 albert.kur...@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 herve.bout...@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 bri...@infinity.nu wrote:
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:
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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To
Re: Maven Central Repository - Cleanup Efforts
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 herve.bout...@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 bri...@infinity.nu wrote: 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: 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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 herve.bout...@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 bri...@infinity.nu wrote: 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: 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 albert.kur...@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 d...@... 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 albert.kur...@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 albert.kur...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 stephen.alan.conno...@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 albert.kur...@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 albert.kur...@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 -
Re: Maven Central Repository - Cleanup Efforts
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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 bri...@infinity.nu wrote: 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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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
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 bimargul...@gmail.comwrote: I agree that a point system is pointless.
Re : Maven Central Repository - Cleanup Efforts
- 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? 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.conno...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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.6true/ (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.bout...@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-unsubscr...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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.ander...@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.6true/ (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.bout...@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
Re: Maven Central Repository - Cleanup Efforts
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.ander...@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.6true/ (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
Re: Maven Central Repository - Cleanup Efforts
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 jvan...@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.ander...@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.6true/ (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.
Re: Maven Central Repository - Cleanup Efforts
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 jvan...@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.ander...@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.6true/ (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
Re: Maven Central Repository - Cleanup Efforts
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 d...@... 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 d...@... 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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: http://mail.opensolaris.org/pipermail/opensolaris-discuss/2005-February/002170.html
Re: Maven Central Repository - Cleanup Efforts
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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 bri...@infinity.nu wrote: 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: 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 bri...@infinity.nu wrote: 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: 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 herve.bout...@free.frwrote: I need some clarifications to be sure that we are all speaking of the same thing.
Re: Maven Central Repository - Cleanup Efforts
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.bout...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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.kur...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 albert.kur...@gmail.comwrote: 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.bout...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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 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.bout...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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.bout...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 stephen.alan.conno...@gmail.com wrote: 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 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.bout...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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.bout...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 stephen.alan.conno...@gmail.com wrote: 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 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.bout...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 jvan...@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 bri...@infinity.nu wrote: 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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 albert.kur...@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 jvan...@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 bri...@infinity.nu wrote: 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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven
Re: Maven Central Repository - Cleanup Efforts
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 albert.kur...@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 jvan...@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 bri...@infinity.nu wrote: 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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl
Re: Maven Central Repository - Cleanup Efforts
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 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 albert.kur...@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 jvan...@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 bri...@infinity.nu wrote: 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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For
Re: Maven Central Repository - Cleanup Efforts
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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 stephen.alan.conno...@gmail.com wrote: 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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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: 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 bri...@infinity.nu wrote: 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: 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 albert.kur...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 bri...@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 albert.kur...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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 albert.kur...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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, 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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, 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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, 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 bri...@infinity.nu wrote: 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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven Central Repository - Cleanup Efforts
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 bri...@infinity.nu wrote: 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 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to override the maven central repository completely
Hi, I like to maintain our own internal repository instead of http://repo1.maven.org/maven2 due to some restrictions. I created internal server and downloaded necessary plugins and directory structures same as http://repo1.maven.org/maven2. I updated the pom file repository setting as follows. But it is still goes to look in to http://repo1.maven.org/maven2. repository idcentral/id namecentral/name urlhttp://PHX51682:8080/mvn//url layoutdefault/layout /repository I like to know how to override the central repository. Thanks in advance Venkat M
Re: How to override the maven central repository completely
Hi, AFAIK, that is the right way on overriding central repository, try to check if central repository is declared in your settings.xml? -allan Venkat Muthusamy wrote: Hi, I like to maintain our own internal repository instead of http://repo1.maven.org/maven2 due to some restrictions. I created internal server and downloaded necessary plugins and directory structures same as http://repo1.maven.org/maven2. I updated the pom file repository setting as follows. But it is still goes to look in to http://repo1.maven.org/maven2. repository idcentral/id namecentral/name urlhttp://PHX51682:8080/mvn//url layoutdefault/layout /repository I like to know how to override the central repository. Thanks in advance Venkat M No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.371 / Virus Database: 267.14.1/206 - Release Date: 12/16/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to override the maven central repository completely
Dear , You can set you reposity id in setting.xml as central . for example profiles profile iddevpprofile1/id activation os familyunix/family /os /activation properties devep.websiteresource/appserver/devep.website /properties repositories repository releases enabledtrue/enabled updatePolicyalways/updatePolicy checksumPolicyfail/checksumPolicy /releases snapshots enabledtrue/enabled updatePolicyalways/updatePolicy checksumPolicyfail/checksumPolicy /snapshots idmaven2repo1/id namedeveloper Resp/name urlhttp://repo1.maven.org/maven2//url /repository repository releases enabledtrue/enabled updatePolicynever/updatePolicy checksumPolicyfail/checksumPolicy /releases snapshots enabledtrue/enabled updatePolicynever/updatePolicy checksumPolicyfail/checksumPolicy /snapshots idlocalreposity/id namedeveloper local Resp/name urlfile:///d:/m2localrepo//url /repository /repositories pluginRepositories pluginRepository releases enabledtrue/enabled updatePolicynever/updatePolicy checksumPolicyfail/checksumPolicy /releases idpluginLili/id namemaven plugin/name urlhttp://www.ibiblio.org/maven2//url /pluginRepository pluginRepository releases enabledtrue/enabled updatePolicynever/updatePolicy checksumPolicyfail/checksumPolicy /releases idlocalplugin/id namelocal maven plugin/name urlfile:///d:/m2localrepo//url /pluginRepository /pluginRepositories /profile profile iddevpprofile2/id activation !--jdk1.5.0_04/jdk-- os familywindows/family /os /activation properties devep.websiteresource/appserver/devep.website /properties repositories repository snapshots enabledfalse/enabled /snapshots idcentral/id nameMaven Repository Switchboard/name !--urlhttp://repo1.maven.org/maven2/url-- urlfile:///d:/m2localrepo//url /repository /repositories pluginRepositories pluginRepository releases updatePolicynever/updatePolicy /releases snapshots enabledfalse/enabled /snapshots idcentral/id nameMaven Plugin Repository/name !-- urlhttp://repo1.maven.org/maven2/url-- urlfile:///d:/m2localrepo//url /pluginRepository /pluginRepositories /profile /profiles !-- activeProfiles | List of profiles that are active for all builds. |-- activeProfiles !--activeProfiledevpprofile1/activeProfile-- activeProfiledevpprofile2/activeProfile !--activeProfileanotherAlwaysActiveProfile/activeProfile-- /activeProfiles thanks. Tel: (020)36315358-328 Fax: (020)36315170 Allan Ramirez [EMAIL PROTECTED]To: Maven Users List users@maven.apache.org om cc: Subject: Re: How to override the maven central repository completely 21/12/2005 09:26 Please respond to Maven Users List
