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]
