Yes, I was expecting something more. I thought there'd be a stack trace associated with the warning.
I'll take a look. - Brett On 11/7/05, Jeff Jensen <[EMAIL PROTECTED]> wrote: > Actually, I should say "I can't tell"! Is there more info to get somehow? > Was there something specific you were expecting that isn't there?? > > > -----Original Message----- > From: Jeff Jensen [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 06, 2005 7:28 PM > To: 'Maven Users List' > Subject: RE: keyword "SNAPSHOT" in depedency version is ignored > > Looks like the jar itself: > > [INFO] artifact junit:junit: checking for updates from central > [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = > '732552cf5a2673094c0d6ceb38249ebc9dfbe9e3'; remote = > 'da39a3ee5e6b4b0d3255bfef95601890afd80709' - RETRYING > [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = > '732552cf5a2673094c0d6ceb38249ebc9dfbe9e3'; remote = > 'da39a3ee5e6b4b0d3255bfef95601890afd80709' - IGNORING > [DEBUG] junit:junit:jar:3.8.1 (setting version to: 3.8.1 from range: > [3.8.1,)) > [DEBUG] junit:junit:jar:3.8.1 (selected for test) > > > -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 06, 2005 6:39 PM > To: Maven Users List > Subject: Re: keyword "SNAPSHOT" in depedency version is ignored > > 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] > > > --------------------------------------------------------------------- > 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]
