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 Nabbl
.cazzola :
>> 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
.
> 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 rep
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 c
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 tho
> 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 C
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.
/Ander
> 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 wa
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
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 wrote:
> Once upon a time, I filed a JIRA at Codehaus:
> http://jira.codehaus.org/browse/MEV-641. Eleven months elapsed before
> some
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
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 wrote:
> FYI
>
> Initiating a thread here to see its effect.
>
> http://developer.amazonwebservices.com/connect/thread.jspa?messageID=158762𦰪
>
> Cheers,
>
FYI
Initiating a thread here to see its effect.
http://developer.amazonwebservices.com/connect/thread.jspa?messageID=158762𦰪
Cheers,
Mark
On Mon, Dec 21, 2009 at 10:19 AM, Carlos Sanchez wrote:
> you can set s3 buckets where "requester pays"
>
>
> http://developer.amazonwebservices.com/connec
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 wrote:
> On Mon, Dec 21, 2009 at 12:09 AM, Mark Diggory wrote:
>> I imagine there have to be a number of projects/companies out t
On Mon, Dec 21, 2009 at 12:09 AM, Mark Diggory 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 rep
re's an option to "sell" it so users end paying the fees
> >
> >
> > On Sun, Dec 20, 2009 at 8:18 PM, Mark Diggory
> 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
>
>
> 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 unsubscri
eers,
>>
>> 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
---
sers end paying the fees
On Sun, Dec 20, 2009 at 8:18 PM, Mark Diggory 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 su
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
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
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 wrote:
>> Then make your own repository. See how useful that is.
>
> Jason, you are probably
> 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: user
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 =
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 wrote:
>> Do you really mean that you would like to enforce such -source-release.zip
>> artefacts to be published?
> Not any qua
> 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 filte
- Message d'origine
> De : Albert Kurucz
> À : Maven Users List
> 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?
ht
Tamas, could explain "MRMs + grouping + mirrorOf" or send a link?
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> w
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
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
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
th
On Mon, Sep 28, 2009 at 9:02 AM, Albert Kurucz 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
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 definitions in po
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
definition in a pom.xml file.
We do not allow definitions in pom files for a good reason.
certlists is just another name for the same thin
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 wrote:
> It
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 eac
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 repositori
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 publis
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
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 abo
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 communit
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
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)
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 Son
On Sat, Sep 26, 2009 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 (veri
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
> 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 crit
Sent from my [rhymes with tryPod] ;-)
On 26 Sep 2009, at 18:58, 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
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
q
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
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 [r
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 cust
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
t
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
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
A lot of +1-es to this quote
~t~
On Sat, Sep 26, 2009 at 4:35 AM, Albert Kurucz 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/o
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
On Fri, Sep 25, 2009 at 12:44 PM, Albert Kurucz 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
> N
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 b
2009/9/25 Hervé BOUTEMY :
> Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
>> 2009/9/25 Albert Kurucz :
>> > 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 p
2009/9/25 Hervé BOUTEMY :
> 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 define
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 th
Le vendredi 25 septembre 2009, Stephen Connolly a écrit :
> 2009/9/25 Albert Kurucz :
> > 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 librarie
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
2009/9/25 Albert Kurucz :
> 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
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.
Fi
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 h
"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 b
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 e
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 unenforce
On Thu, Sep 24, 2009 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 r
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.
Garbage collection?
Identify corrupted ones and remove.
On Thu, Sep 24, 2009 at 4:41 PM, Brian Fox wrote:
> On Thu, Sep 24, 2009 at 12:04 PM, Albert Kurucz
> wrote:
>> Brian,
>> Probably no one ever suggested that the corrupt artifacts should be
>> fixed, because fixing is not even possible (ev
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
On Thu, Sep 24, 2009 at 12:04 PM, Albert Kurucz 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 o
On Thu, Sep 24, 2009 at 12:18 PM, Albert Kurucz 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.
>
-
T
l 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 protec
om/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
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 f
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 ea
cc:
Subject: Re: How to override
the maven central repository completely
21/12/2005
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.
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.
84 matches
Mail list logo
