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
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
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
...@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
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
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
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
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
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.
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
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
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
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
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
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
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
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.
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
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
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
Then make your own repository. See how useful that is.
Jason, you are probably right.
http://xircles.codehaus.org/projects/pinin
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail:
Please see my response on the maven-dev list for how this problem is
best approached. For everyone's sanity, lets keep the discussion
thread on the dev list.
On Thu, Oct 1, 2009 at 2:41 PM, Albert Kurucz albert.kur...@gmail.com wrote:
Then make your own repository. See how useful that is.
Somebody just gave me an idea what would be an excellent tool to crawl
through a repository and create an index of the artifacts, which pass
some kind of acceptance criteria:
http://docs.codehaus.org/display/M2ECLIPSE/Nexus+Indexer
// get NexusIndexer component from Plexus
PlexusContainer plexus
Do you really mean that you would like to enforce such -source-release.zip
artefacts to be published?
Not any qualities of the code should be enforced.
But I very much want to be able to find those gems from the big pile of ...
Therefore the artifacts on Central should be search-able and
For some start-ups, this could mean a business opportunity!
Nobody said, that the quality info should be given away free.
On Tue, Sep 29, 2009 at 7:21 AM, Albert Kurucz albert.kur...@gmail.com wrote:
Do you really mean that you would like to enforce such -source-release.zip
artefacts to be
Filtering is already used for another Maven feature.
To avoid ambiguity, we should better call the one what I defined:
repository-skinning or repository-certification.
Do you think this new feature would hurt the repo or any Maven user?
On Sun, Sep 27, 2009 at 11:27 PM, Albert Kurucz
Yes it would hurt.
A build then becomes dependent on the certlist in order for it to function.
In such a way, a cert list becomes directly equivalent to a repository
definition in a pom.xml file.
We do not allow repository definitions in pom files for a good reason.
certlists is just another
Any other flaws?
A build then becomes dependent on the certlist in order for it to function.
The project's build will not become dependent of the certlist.
If it was able to build with certlist feature turned on, it will
certainly build without the certlist.
We do not allow repository
On Mon, Sep 28, 2009 at 9:02 AM, Albert Kurucz albert.kur...@gmail.com wrote:
Any other flaws?
A build then becomes dependent on the certlist in order for it to function.
The project's build will not become dependent of the certlist.
If it was able to build with certlist feature turned on, it
One unwritten? rule of Maven good practice is that you change the
undefined dependency version definitions to fixed versions before
release. If you have done that, resolution will not be effected by
certlist on or off status.
The value (benefit) what certlist would provide to a Maven user, is
Sorry for thread hijack, but was not able to resist...
Another thing to think about, since it's adoption:
On Mon, Sep 28, 2009 at 5:34 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
We do not allow repository definitions in pom files for a good reason.
This seemed as a good
I did not propose point system to describe the quality of repository
alone, I thought of it just to be able to compare two different
repositories... (ie. you find same thing in two of them, decide which one
will you want to use, etc). But now I understand that this would provide a
lot less value
- Message d'origine
De : Albert Kurucz albert.kur...@gmail.com
À : Maven Users List users@maven.apache.org
Envoyé le : Lundi, 28 Septembre 2009, 19h39mn 00s
Objet : Re: Maven Central Repository - Cleanup Efforts
Tamas, could explain MRMs + grouping + mirrorOf or send a link
I hope I get this right
Jason here states that there should only be one central
And yes we can ONLY have ONE central. And this is the ONE we got
today
That must be the game we are playing.
The community must be able to TRUST maven / central.
Starting changing this could cause doubt, and
I agree that a point system is pointless.
I mostly care about whether an artifact is well-formed. I don't depend on
maven central to help me make business decisions about what open source
components to depend on. If I need a component, I do the research to see
what exists, what has a live
This is exactly what all sane users do, but we will still try
extremely hard to clean everything up and make it easier for open
source projects to get their artifacts to central.
On 2009-09-27, at 10:41 AM, Benson Margulies wrote:
I agree that a point system is pointless.
I mostly care
Mr. Zyl,
Please don't mistake me. I'm on your side of this debate. I am no more
arguing against basic cleanup than I am arguing for trying to get into the
business of arbitrating and publishing elaborate metadata about what is
inside or behind the artifacts.
Central should be as clean as
Only pointing out that's what people typically do.
On 2009-09-27, at 11:27 AM, Benson Margulies wrote:
Mr. Zyl,
Please don't mistake me. I'm on your side of this debate. I am no more
arguing against basic cleanup than I am arguing for trying to get
into the
business of arbitrating and
On 27/09/2009, at 5:15 AM, Jason van Zyl wrote:
Not having a super high quality central repository actually makes
our commercial efforts a lot harder. If I was devious I would have
agreed with Brett and would make a completely clean central
repository as our plans require intact
It is not necessary to create a new repo and it is not necessary to
modify anything on Central or the policies how it is managed. Mess
could be cleaned up virtually if I could attach a filter.
In the ~/.m2/settings.xml for example, I should be able to add a list
of repository addresses and for
A lot of +1-es to this quote
~t~
On Sat, Sep 26, 2009 at 4:35 AM, Albert Kurucz albert.kur...@gmail.comwrote:
Non-buildable source is fine as a gesture of goodwill, but I think if the
public source isn't buildable, we're gonna end up with egg on our faces.
Quote from:
Le samedi 26 septembre 2009, Tamás Cservenák a écrit :
I think we all need some clarification, since we all talk about quality
(we all agreed upon the basic things unanimously).
What is the quality of a maven repository (in general)? Can we measure
it? Can we define it?
A wiki page with
Le samedi 26 septembre 2009, Albert Kurucz a écrit :
For the additional requirement, getting into the pure Maven repo (The
best), I really meant: build-able.
Me too, I don't really care what tool you use to build it as long as
the tool is already checked in and you only use the attached
Le samedi 26 septembre 2009, Albert Kurucz a écrit :
For the additional requirement, getting into the pure Maven repo (The
best), I really meant: build-able.
Me too, I don't really care what tool you use to build it as long as
the tool is already checked in and you only use the attached
I think we all need some clarification, since we all talk about quality
(we all agreed upon the basic things unanimously).
What is the quality of a maven repository (in general)? Can we measure it?
Can we define it?
A wiki page with piled up (even personal) opinions would be good -- whatever
they
Very nice idea to measure the quality.
But sorry Tamas, 50% corrupt or 90% corrupt does not make a difference for me.
Especially not, when I have feeling that it is possible to maintain a
100% clean repo with the right automation tools.
If Sonatype's goal is to sell these tools only for paying
IMHO, being buildable by maven is a nice to have, but to be honest, if
somebody wants to build their project with a DOS batch file and a
piece of string I don't mind as long as they publish the artifact with
a valid pom
anything else is setting the repository up for failure
Sent from my
You got the point. But that quality information (whatever it's form would
be), could do things like:
- describe the overall quality of repo (let's name it the MRQ score)
- the list (or only the count) of rules/tests ran (so, a repo of MRQ
score 5 with 5 tests would be less good than a repo with
if you start measuring artifact quality, it makes sense to break down
the stats by groupId
at least that way if I see that java.net has 100% quality for
com.stvconsultants.easygloss I can configure my repository manager to
allow that group I'd through, but leave org.glassfish out as its
Sent from my [rhymes with tryPod] ;-)
On 26 Sep 2009, at 18:58, Albert Kurucz albert.kur...@gmail.com wrote:
Very nice idea to measure the quality.
But sorry Tamas, 50% corrupt or 90% corrupt does not make a
difference for me.
Especially not, when I have feeling that it is possible to
central it just too useful... it has gathered critical mass whereby it is
nearly a right of passage for new java projects to get hosted on central...
hosting on central becomes one of those things projects are asked to do...
if we move the goalposts too far or too fast we will kill the
I don't want anyone to miss any of the numerous ok arifacts.
Those could still be housed by the Good enough Central repo.
I would like to have a setting in my Maven with 3 options:
-Good enough
-Good (verified meta)
-Best (verified buildable)
which selects which of the 3 maintained repo will be
On Sat, Sep 26, 2009 at 12:11 PM, Albert Kurucz albert.kur...@gmail.com wrote:
I don't want anyone to miss any of the numerous ok arifacts.
Those could still be housed by the Good enough Central repo.
I would like to have a setting in my Maven with 3 options:
-Good enough
-Good (verified
On 2009-09-26, at 10:58 AM, Albert Kurucz wrote:
Very nice idea to measure the quality.
But sorry Tamas, 50% corrupt or 90% corrupt does not make a
difference for me.
Especially not, when I have feeling that it is possible to maintain a
100% clean repo with the right automation tools.
If
On 2009-09-26, at 12:11 PM, Albert Kurucz wrote:
I don't want anyone to miss any of the numerous ok arifacts.
Those could still be housed by the Good enough Central repo.
I would like to have a setting in my Maven with 3 options:
-Good enough
-Good (verified meta)
-Best (verified buildable)
We just need a high-quality POM, correct metadata, javadocs, sources,
and signatures.
It is debatable is what you mean on high quality.
For me (totally a Maven fan!) what makes the POM high quality?
Its ability to build the project!
I don't really care if it is full of maven-antrun-plugin, but
For me,
High quality is that:
/project/(?parent/)(groupId|artifactId|version) are valid and do not
reference properties
/project/dependencies is valid and if there are any properties defined
they are defined within the pom or it's parents
/project/name
/project/description
/project/url
Bonus
The pure Maven repo should say:
We honestly don't care which Maven plugin the people build with, as
long as that plugin is already checked into here.
And why people would prefer to use libraries from the pure Maven repo?
Quality.
Being build-able has always been the target of OSS developments.
2009/9/25 Albert Kurucz albert.kur...@gmail.com:
The pure Maven repo should say:
We honestly don't care which Maven plugin the people build with, as
long as that plugin is already checked into here.
And why people would prefer to use libraries from the pure Maven repo?
Quality.
Being
Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
For me,
High quality is that:
/project/(?parent/)(groupId|artifactId|version) are valid and do not
reference properties
/project/dependencies is valid and if there are any properties defined
they are defined within the pom or it's
Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
2009/9/25 Albert Kurucz albert.kur...@gmail.com:
The pure Maven repo should say:
We honestly don't care which Maven plugin the people build with, as
long as that plugin is already checked into here.
And why people would prefer to
On Fri September 25 2009 12:07:09 pm Stephen Connolly wrote:
For me,
High quality is that:
/project/(?parent/)(groupId|artifactId|version) are valid and do not
reference properties
/project/dependencies is valid and if there are any properties defined
they are defined within the pom or
2009/9/25 Hervé BOUTEMY herve.bout...@free.fr:
Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
For me,
High quality is that:
/project/(?parent/)(groupId|artifactId|version) are valid and do not
reference properties
/project/dependencies is valid and if there are any properties
2009/9/25 Hervé BOUTEMY herve.bout...@free.fr:
Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
2009/9/25 Albert Kurucz albert.kur...@gmail.com:
The pure Maven repo should say:
We honestly don't care which Maven plugin the people build with, as
long as that plugin is already
Technically it is possible to manage 3 different OSS Maven repos.
1. The good enough
This is the current Maven Central
No rules, only recommendations:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
Note: it is not a rule what is not enforced!
2. The good
This would be
On Fri, Sep 25, 2009 at 12:44 PM, Albert Kurucz albert.kur...@gmail.com wrote:
Technically it is possible to manage 3 different OSS Maven repos.
1. The good enough
This is the current Maven Central
No rules, only recommendations:
For the additional requirement, getting into the pure Maven repo (The
best), I really meant: build-able.
Me too, I don't really care what tool you use to build it as long as
the tool is already checked in and you only use the attached metadata
and the attached sources.
But a tool like this, in
According to http://www.think88.com/resources/Maven_white_paper_june_2009.pdf
Sonatype maintains a central repository with more than 90,000 artifacts,
consuming more than 60 GB of storage. In addition to the artifacts
themselves, the
Maven Central Repository also contains a POM-file for each
/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
/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
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
On Thu, Sep 24, 2009 at 12:18 PM, Albert Kurucz albert.kur...@gmail.com wrote:
Brian,
MEV is for Maven Evangelism issues.
Are you sure maintenance issues of any given repo should belong to that?
For any given repo no, for Central, yes.
On Thu, Sep 24, 2009 at 12:04 PM, Albert Kurucz albert.kur...@gmail.com wrote:
Brian,
Probably no one ever suggested that the corrupt artifacts should be
fixed, because fixing is not even possible (every artifact must be
signed by the creator).
The question is whether you prefer the corrupt
Requirements for the POMs are defined as:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
I call the artifact corrupt (regarding Maven Central Compliance) if
the POM of the artifact does not fulfills the above requirements.
There are corrupt ones have made it to the
Garbage collection?
Identify corrupted ones and remove.
On Thu, Sep 24, 2009 at 4:41 PM, Brian Fox bri...@infinity.nu wrote:
On Thu, Sep 24, 2009 at 12:04 PM, Albert Kurucz albert.kur...@gmail.com
wrote:
Brian,
Probably no one ever suggested that the corrupt artifacts should be
fixed,
On 2009-09-24, at 3:16 PM, Albert Kurucz wrote:
Requirements for the POMs are defined as:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
I call the artifact corrupt (regarding Maven Central Compliance) if
the POM of the artifact does not fulfills the above
On Thu, Sep 24, 2009 at 3:16 PM, Albert Kurucz albert.kur...@gmail.com wrote:
Requirements for the POMs are defined as:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
I call the artifact corrupt (regarding Maven Central Compliance) if
the POM of the artifact does not
Jason and Brian, thanks for the explanations.
Understood, the policy of not removing anything from Maven Central
serves a purpose.
I wish there would be another publicly Maven repository, which is
maintained with rules enforced. This repo could even have a rule
(additional to the old and
On 2009-09-24, at 7:52 PM, Albert Kurucz wrote:
Jason and Brian, thanks for the explanations.
Understood, the policy of not removing anything from Maven Central
serves a purpose.
I wish there would be another publicly Maven repository, which is
maintained with rules enforced. This repo could
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
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.
@maven.apache.org
om cc:
Subject: Re: How to override
the maven central repository
82 matches
Mail list logo