Could you run with -X so it tells you exactly which file has the checksum error (it could be the metadata, the pom, or the JAR).
We are in the process of minotiring the repository for such errors. - Brett On 11/7/05, Jeff Jensen <[EMAIL PROTECTED]> wrote: > When I have this in the parent POM: > > <dependencyManagement> > <dependencies> > <dependency> > <groupId>junit</groupId> > <artifactId>junit</artifactId> > <version>[3.8.1,)</version> > <scope>test</scope> > </dependency> > [snip] > > This is the result when run in a module: > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] artifact junit:junit: checking for updates from central > [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = > '732552cf5a > 2673094c0d6ceb38249ebc9dfbe9e3'; remote = > 'da39a3ee5e6b4b0d3255bfef95601890afd80 > 709' - RETRYING > [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = > '732552cf5a > 2673094c0d6ceb38249ebc9dfbe9e3'; remote = > 'da39a3ee5e6b4b0d3255bfef95601890afd80 > 709' - IGNORING > [INFO] [compiler:compile] > > > Is this expected, something wrong on my part, or perhaps a bug? > > > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 03, 2005 5:58 PM > To: Maven Users List > Subject: Re: keyword "SNAPSHOT" in depedency version is ignored > > What was the dependency? Do you have a test case? > > - Brett > > > On 11/4/05, Brian E. Fox <[EMAIL PROTECTED]> wrote: > > I'm not able to make this work. I tried: > > [1.1,) > > [1.1,] > > (1.1,) > > > > Etc. Each time it is trying to resolve that version exactly as typed. > > > > -----Original Message----- > > From: Brett Porter [mailto:[EMAIL PROTECTED] > > Sent: Monday, October 31, 2005 3:27 PM > > To: Maven Users List > > Subject: Re: keyword "SNAPSHOT" in depedency version is ignored > > > > This functionality already exists in Maven 2.0. > > > > [1.0,) indicates >= 1.0 > > > > - Brett > > > > On 11/1/05, Lukas Theussl <[EMAIL PROTECTED]> wrote: > > > Right, but this would be something completely different from the > > > current snapshot functionality. > > > > > > > > > As I said in one of my earlier mails, if you want that functionality > > > you can open a JIRA request for it (preferably with a patch attached > > ;) ). > > > And of course, I retain all my reservations about automatic > > > dependency > > > > > upgrade as expressed before. But then, if you want it, it's your > > > decision. :) > > > > > > -Lukas > > > > > > > > > Brian E. Fox wrote: > > > > I think maybe what is being asked for is the ability to get the > > > > lastest non snapshot build? For example if wagon-ftp changes from > > > > 1.0 to 1.1, I want to automatically grab it. Maybe not the best > > > > decision, but still a possible option to allow people to choose. I > > > > think that in terms of versioning modules you have control over, > > this might be preferrable. > > > > This way a development team could depend on the latest "sanctioned" > > > > version without depending on unstable snapshot builds and without > > > > having to manually update all the poms everytime a new module is > > published. > > > > > > > > -----Original Message----- > > > > From: Lukas Theussl [mailto:[EMAIL PROTECTED] > > > > Sent: Monday, October 31, 2005 1:01 PM > > > > To: Maven Users List > > > > Subject: Re: keyword "SNAPSHOT" in depedency version is ignored > > > > > > > > > > > > Hi, > > > > > > > > > > > >>What if a released component on remote repository has any bugs? > > > > > > > > > > > > > > > > This just underscores my point, no? Generally, I think upgrading > > > > (or > > > > downgrading) a dependency is always something that should be done > > > > very carefully and very consciously, I wouldn't want to have that > > > > done automatically. > > > > > > > > Indicating a SNAPSHOT dependency is only useful if you know that a > > > > project is currently under heavy development and you want to stay > > > > up > > > > > > to date with changes on a, say, day-to-day basis (assuming the > > > > project publishes SNAPSHOTs that often). This implies that your > > > > project itself is currently changing frequently, and if something > > > > breaks from one day to the other, you know it might not be due to > > > > your own code, but to a changed dependency. As soon as a stable > > > > release gets out, you have to indicate explicitly (after testing) > > > > that you no longer want to use SNAPSHOTs, but stick to a > > > > particular > > stable version. > > > > > > > > > > > > > > > >>If features of a component do not have to be changed to fix bugs, > > > >>I think it's useful to replace this bad component on local > > > >>repository with bug fixed component on remote repository > > > >>automatically (after agreement). > > > > > > > > > > > > But how would you indicate which component is the good one? A > > > > SNAPSHOT always gets you the _latest_ development version, which > > > > is actually very rarely the most bug-free one! ;) > > > > > > > > > > > > -Lukas > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > -------------------------------------------------------------------- > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
