You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mark Hobson <ma...@gmail.com> on 2007/07/06 15:52:37 UTC
Version ranges and snapshots
Hi,
Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
contrary to the 2.0 design docs:
http://jira.codehaus.org/browse/MNG-3092
Brett, Kenney and myself had a brief discussion on IRC about this:
Kenney says that the behaviour is theoretically correct (which it is),
although I feel it goes against the practical usage described in the
docs. The two main choices I can see are:
1) We stick to the design docs and disallow snapshots in ranges when
they aren't an explicit boundary, as per the MNG-3092 patch.
2) We reconsider the design docs and leave range resolution behaving
as it is, then use profiles to enable or disable snapshot repositories
at build time.
Any thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Version ranges and snapshots
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
It will warn or fail the build. It's a gatekeeper not a negotiator ;-)
-----Original Message-----
From: dhoffer [mailto:DHoffer@xrite.com]
Sent: Thursday, January 10, 2008 9:49 PM
To: dev@maven.apache.org
Subject: Re: Version ranges and snapshots
Does maven-enforcer-plugin just stop a build from including a snapshot
or
does it force it to find a release? You know what I mean? Is it a
after-the-fact filter or does it change the behavior of maven?
Michael McCallum-3 wrote:
>
> On Wed, 09 Jan 2008 15:15:55 Michael McCallum wrote:
>> > IMHO, I think our approach excels in making sure this doesn't
happen.
>> > First and foremost, if this version range issue can be fixed,
snapshots
>> > will never be considered valid unless explicitly asked for.
Therefore
>> > snapshot deploys will never be a problem for me. Currently I can't
>> even
>> > release because snapshots are not filtered out.
>>
>> the enforcer plugin definitely fixes this and the
>> generateReleasePoms=true
>> ensures that the build from tag uses the same clean deps as when
tagging
> sorry lets you get errors if you try to release with snapshots...
>
> this is how i configured it... it pays to do a clean test enabling the
> profile
> first otherwise it fails on perform rather than tag... there may be a
> better
> way that this though
>
> <profile>
> <id>enforce-no-snapshots</id>
> <activation>
> <property>
> <name>performRelease</name>
> <value>true</value>
> </property>
> </activation>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-enforcer-plugin</artifactId>
> <executions>
> <execution>
> <id>enforce-no-snapshots</id>
> <phase>validate</phase>
> <goals>
> <goal>enforce</goal>
> </goals>
> <configuration>
> <rules>
> <noSnapshots>
> <message>
> No snapshots allowed in releases it breaks
build
> reproducibility.
> </message>
> </noSnapshots>
> </rules>
> <searchTransitive>true</searchTransitive>
> <fail>true</fail>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> </profile>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context:
http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p147487
36.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
Does maven-enforcer-plugin just stop a build from including a snapshot or
does it force it to find a release? You know what I mean? Is it a
after-the-fact filter or does it change the behavior of maven?
Michael McCallum-3 wrote:
>
> On Wed, 09 Jan 2008 15:15:55 Michael McCallum wrote:
>> > IMHO, I think our approach excels in making sure this doesn't happen.
>> > First and foremost, if this version range issue can be fixed, snapshots
>> > will never be considered valid unless explicitly asked for. Therefore
>> > snapshot deploys will never be a problem for me. Currently I can't
>> even
>> > release because snapshots are not filtered out.
>>
>> the enforcer plugin definitely fixes this and the
>> generateReleasePoms=true
>> ensures that the build from tag uses the same clean deps as when tagging
> sorry lets you get errors if you try to release with snapshots...
>
> this is how i configured it... it pays to do a clean test enabling the
> profile
> first otherwise it fails on perform rather than tag... there may be a
> better
> way that this though
>
> <profile>
> <id>enforce-no-snapshots</id>
> <activation>
> <property>
> <name>performRelease</name>
> <value>true</value>
> </property>
> </activation>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-enforcer-plugin</artifactId>
> <executions>
> <execution>
> <id>enforce-no-snapshots</id>
> <phase>validate</phase>
> <goals>
> <goal>enforce</goal>
> </goals>
> <configuration>
> <rules>
> <noSnapshots>
> <message>
> No snapshots allowed in releases it breaks build
> reproducibility.
> </message>
> </noSnapshots>
> </rules>
> <searchTransitive>true</searchTransitive>
> <fail>true</fail>
> </configuration>
> </execution>
> </executions>
> </plugin>
> </plugins>
> </build>
> </profile>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14748736.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
On Wed, 09 Jan 2008 15:15:55 Michael McCallum wrote:
> > IMHO, I think our approach excels in making sure this doesn't happen.
> > First and foremost, if this version range issue can be fixed, snapshots
> > will never be considered valid unless explicitly asked for. Therefore
> > snapshot deploys will never be a problem for me. Currently I can't even
> > release because snapshots are not filtered out.
>
> the enforcer plugin definitely fixes this and the generateReleasePoms=true
> ensures that the build from tag uses the same clean deps as when tagging
sorry lets you get errors if you try to release with snapshots...
this is how i configured it... it pays to do a clean test enabling the profile
first otherwise it fails on perform rather than tag... there may be a better
way that this though
<profile>
<id>enforce-no-snapshots</id>
<activation>
<property>
<name>performRelease</name>
<value>true</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<executions>
<execution>
<id>enforce-no-snapshots</id>
<phase>validate</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<noSnapshots>
<message>
No snapshots allowed in releases it breaks build
reproducibility.
</message>
</noSnapshots>
</rules>
<searchTransitive>true</searchTransitive>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
> IMHO, I think our approach excels in making sure this doesn't happen.
> First and foremost, if this version range issue can be fixed, snapshots
> will never be considered valid unless explicitly asked for. Therefore
> snapshot deploys will never be a problem for me. Currently I can't even
> release because snapshots are not filtered out.
the enforcer plugin definitely fixes this and the generateReleasePoms=true
ensures that the build from tag uses the same clean deps as when tagging
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
so you are saying that A-2.0-SNAPSHOT uses B [1,2-!) and someone deploys B
1.4.1-SNAPSHOT and that overrides B 2.0-SNAPSHOT and B 1.4 or just that it
overrides B1.4?
Depends on your use case... as to how you would deal with that. And one of the
reasons why I don't want mng-3092 because I can CI for this problem at the
moment.
<digression>
well you do need to be careful but the same it true even if you have version
ranges for releases... mvn depedency:resolve is your friend...
when creating patched assemblies you need to confirm that any changes are
ok... its not sufficient just to exclude snapshots... because any released
version could also change the behaviour of the system...
</digression>
On Thu, 24 Jan 2008 08:41:48 Stephen Connolly wrote:
> But that will bugger you up...
>
> You are working on the version 2 branch, there is no 2.0 released, only
> 2.0-SNAPSHOT... you don't care as it is still new and you are happy to use
> the last stable release, 1.4...
>
> Now there is some work that is needed for the 1.4 service pack, so
> 1.4.1-SNAPSHOT arrives and bang! you are scuppered
>
> On Jan 23, 2008 7:31 PM, Michael McCallum <gh...@apache.org> wrote:
> > BTW if you want to _not_ include a snapshot on an open upper bound you
> > can..
> > [1,2-!)
> >
> > which will not include 1.0-SNAPSHOT, 1-SNAPSHOT
> > will include any version between 1 and 2 including any 1.2-SNAPSHOT or
> > 1.4-SNAPSHOT
> > will not include 2.0-SNAPSHOT or 2-SNAPSHOT
> >
> > On Thu, 24 Jan 2008 03:42:13 Mark Hobson wrote:
> > > Hi Michael,
> > >
> > > On 23/01/2008, Michael McCallum <gh...@apache.org> wrote:
> > > > Firstly IMHO of MNG-3092 is that is it not the right thing for maven
> >
> > in
> >
> > > > general.
> > > >
> > > > I believe with MNG-2994 and appropriate use of profiles to enable and
> > > > disable snapshot repositories you can have everything that you want
> >
> > and
> >
> > > > still maintain the ability to allow any snapshot to be injected when
> > > > desired. There is a little gem that i discovered - or maybe i just
> > > > imagined it - the resolution tree is built from metadata, if you have
> >
> > no
> >
> > > > local metadata and MNG-2994 is fixed then you can control the
> >
> > resolution
> >
> > > > of any artifact by controlling its set of repositories - irrelevant
> > > > of
> >
> > if
> >
> > > > a snapshot is cached in the local repo.
> > > >
> > > > There is one caveat: the local repository is a merging of two
> >
> > things... a
> >
> > > > local repository and a cache of remote repositories... which is
> > > > unfortunate because that means deploy ends up installing local
> >
> > metadata
> >
> > > > and that results in my view of snapshots and other peoples views of
> > > > snapshots being different. So the act of deploying or installing
> >
> > breaks
> >
> > > > the use of repository selection because local metadata is always
> > > > used. Perhaps the 'local' repository metadata should be maskable as
> > > > well. Strictly speaking there is no reason it should be treated
> > > > differently.
> > >
> > > There is another caveat in that it's all or nothing. Using a profile
> > > mechanism will switch all range dependencies into snapshot mode, when
> > > typically a developer only wishes to upgrade a couple. How could this
> > > be achieved using profiles?
> > >
> > > > I'm concerned that MNG-3092 is a one way street where better more
> > > > flexible solutions could exist. But having said that if you did fix
> >
> > 3092
> >
> > > > it would not adversely affect me right now. And if it does... well
> >
> > I'll
> >
> > > > figure something out.
> > >
> > > I can see the theoretical opposition to fixing MNG-3092, but since
> > > it's impractical and unworkable it seems merely academic. I'm open to
> > > suggestions if they still give the efficiency gains that working with
> > > version ranges will provide.
> > >
> > > Cheers,
> > >
> > > Mark
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > --
> > Michael McCallum
> > Enterprise Engineer
> > mailto:gholam@apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Stephen Connolly <st...@gmail.com>.
But that will bugger you up...
You are working on the version 2 branch, there is no 2.0 released, only
2.0-SNAPSHOT... you don't care as it is still new and you are happy to use
the last stable release, 1.4...
Now there is some work that is needed for the 1.4 service pack, so
1.4.1-SNAPSHOT arrives and bang! you are scuppered
On Jan 23, 2008 7:31 PM, Michael McCallum <gh...@apache.org> wrote:
> BTW if you want to _not_ include a snapshot on an open upper bound you
> can..
> [1,2-!)
>
> which will not include 1.0-SNAPSHOT, 1-SNAPSHOT
> will include any version between 1 and 2 including any 1.2-SNAPSHOT or
> 1.4-SNAPSHOT
> will not include 2.0-SNAPSHOT or 2-SNAPSHOT
>
>
> On Thu, 24 Jan 2008 03:42:13 Mark Hobson wrote:
> > Hi Michael,
> >
> > On 23/01/2008, Michael McCallum <gh...@apache.org> wrote:
> > > Firstly IMHO of MNG-3092 is that is it not the right thing for maven
> in
> > > general.
> > >
> > > I believe with MNG-2994 and appropriate use of profiles to enable and
> > > disable snapshot repositories you can have everything that you want
> and
> > > still maintain the ability to allow any snapshot to be injected when
> > > desired. There is a little gem that i discovered - or maybe i just
> > > imagined it - the resolution tree is built from metadata, if you have
> no
> > > local metadata and MNG-2994 is fixed then you can control the
> resolution
> > > of any artifact by controlling its set of repositories - irrelevant of
> if
> > > a snapshot is cached in the local repo.
> > >
> > > There is one caveat: the local repository is a merging of two
> things... a
> > > local repository and a cache of remote repositories... which is
> > > unfortunate because that means deploy ends up installing local
> metadata
> > > and that results in my view of snapshots and other peoples views of
> > > snapshots being different. So the act of deploying or installing
> breaks
> > > the use of repository selection because local metadata is always used.
> > > Perhaps the 'local' repository metadata should be maskable as well.
> > > Strictly speaking there is no reason it should be treated differently.
> >
> > There is another caveat in that it's all or nothing. Using a profile
> > mechanism will switch all range dependencies into snapshot mode, when
> > typically a developer only wishes to upgrade a couple. How could this
> > be achieved using profiles?
> >
> > > I'm concerned that MNG-3092 is a one way street where better more
> > > flexible solutions could exist. But having said that if you did fix
> 3092
> > > it would not adversely affect me right now. And if it does... well
> I'll
> > > figure something out.
> >
> > I can see the theoretical opposition to fixing MNG-3092, but since
> > it's impractical and unworkable it seems merely academic. I'm open to
> > suggestions if they still give the efficiency gains that working with
> > version ranges will provide.
> >
> > Cheers,
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
BTW if you want to _not_ include a snapshot on an open upper bound you can..
[1,2-!)
which will not include 1.0-SNAPSHOT, 1-SNAPSHOT
will include any version between 1 and 2 including any 1.2-SNAPSHOT or
1.4-SNAPSHOT
will not include 2.0-SNAPSHOT or 2-SNAPSHOT
On Thu, 24 Jan 2008 03:42:13 Mark Hobson wrote:
> Hi Michael,
>
> On 23/01/2008, Michael McCallum <gh...@apache.org> wrote:
> > Firstly IMHO of MNG-3092 is that is it not the right thing for maven in
> > general.
> >
> > I believe with MNG-2994 and appropriate use of profiles to enable and
> > disable snapshot repositories you can have everything that you want and
> > still maintain the ability to allow any snapshot to be injected when
> > desired. There is a little gem that i discovered - or maybe i just
> > imagined it - the resolution tree is built from metadata, if you have no
> > local metadata and MNG-2994 is fixed then you can control the resolution
> > of any artifact by controlling its set of repositories - irrelevant of if
> > a snapshot is cached in the local repo.
> >
> > There is one caveat: the local repository is a merging of two things... a
> > local repository and a cache of remote repositories... which is
> > unfortunate because that means deploy ends up installing local metadata
> > and that results in my view of snapshots and other peoples views of
> > snapshots being different. So the act of deploying or installing breaks
> > the use of repository selection because local metadata is always used.
> > Perhaps the 'local' repository metadata should be maskable as well.
> > Strictly speaking there is no reason it should be treated differently.
>
> There is another caveat in that it's all or nothing. Using a profile
> mechanism will switch all range dependencies into snapshot mode, when
> typically a developer only wishes to upgrade a couple. How could this
> be achieved using profiles?
>
> > I'm concerned that MNG-3092 is a one way street where better more
> > flexible solutions could exist. But having said that if you did fix 3092
> > it would not adversely affect me right now. And if it does... well I'll
> > figure something out.
>
> I can see the theoretical opposition to fixing MNG-3092, but since
> it's impractical and unworkable it seems merely academic. I'm open to
> suggestions if they still give the efficiency gains that working with
> version ranges will provide.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
On Thu, 31 Jan 2008 01:56:09 Mark Hobson wrote:
> On 30/01/2008, Mark Hobson <ma...@gmail.com> wrote:
> > I don't think that linking this level of artifact resolution
> > uncertainty to its source repository is a good idea. How version
> > ranges are resolved should be completely deterministic and independent
> > from where the artifact was actually downloaded from, otherwise we'll
> > end up with no end of build reproducibility problems.
fair enough
>
> In addition, the local repository would be exempt from these rules.
I think the local repository should be treated just like any repo and separate
from the cache of remote repositories... this is actually the cause of _many_
problems in thats its always included...
> This would require manually deleting artifacts from the local repo to
> ensure that certain versions weren't picked up; a maintenance
> nightmare I'm sure you'll agree.
which is bloody annoying if I was able to configure my release profiles to not
include the local repository that would be much better because I would only
get released artifacts in remote repositories
>
> How's best to proceed with resolving this issue? Would voting make
> sense, or should the PMC lay down the intended direction? I'm not
> sure whether this thread needs to get any longer.. :)
open to a vote
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
I am only speaking in regard to MNG-3092, there are several other related
issues which I think all should be fixed
Cons
----------------------
1) Continuous integration of trunks
I would like to be able to run the tests of all of my artifacts against a
build of trunk of every other. How I currently achieve this...
Use continuum with clean install and force a rebuild of every artifact on a
regular basis.
If MNG-3092 were to go ahead in order to include a snapshot in a build I would
have to change the dep of each artifact to include a -SNAPSHOT in one of the
bounds.
2) Using MNG-3092 is not the correct approach to exclude snapshots from
releases. The enforcer plugin can detect and alert when a snapshot is
resolved anywhere in the transitive tree. It would be nice to be able to bind
this to a release
Pros
---------------------------------
1) stops you getting inconsistent builds when you have a snapshot repository
in your repository list that has artifacts matching a range
2) will stop (i think) dirty builds from snapshot metadata in the local
repository. The local repository has multiple personality disorder. There is
no way to enable disable the local metadata left in the local repository
after a release or install. If the local repository cache was separate and
the actual local repository (i.e. for installs) was a first order repo then
this problem would go away
On Thu, 31 Jan 2008 02:14:59 Stephen Connolly wrote:
> IMHO
>
> I think a vote with the two positions clearly identified (perhaps with pros
> and cons for both if the pair of ye can agree on the pros and cons).
> (unless somebody else has a third position)
>
> -Stephen.
>
> On Jan 30, 2008 12:56 PM, Mark Hobson <ma...@gmail.com> wrote:
> > On 30/01/2008, Mark Hobson <ma...@gmail.com> wrote:
> > > I don't think that linking this level of artifact resolution
> > > uncertainty to its source repository is a good idea. How version
> > > ranges are resolved should be completely deterministic and independent
> > > from where the artifact was actually downloaded from, otherwise we'll
> > > end up with no end of build reproducibility problems.
> >
> > In addition, the local repository would be exempt from these rules.
> > This would require manually deleting artifacts from the local repo to
> > ensure that certain versions weren't picked up; a maintenance
> > nightmare I'm sure you'll agree.
> >
> > How's best to proceed with resolving this issue? Would voting make
> > sense, or should the PMC lay down the intended direction? I'm not
> > sure whether this thread needs to get any longer.. :)
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
Well ask us to do something rather than blabber on and we shut up...
I lost two managers and a developer which has chewed up all my time...
On Thu, 31 Jan 2008 02:14:59 Stephen Connolly wrote:
> IMHO
>
> I think a vote with the two positions clearly identified (perhaps with pros
> and cons for both if the pair of ye can agree on the pros and cons).
> (unless somebody else has a third position)
>
> -Stephen.
>
> On Jan 30, 2008 12:56 PM, Mark Hobson <ma...@gmail.com> wrote:
> > On 30/01/2008, Mark Hobson <ma...@gmail.com> wrote:
> > > I don't think that linking this level of artifact resolution
> > > uncertainty to its source repository is a good idea. How version
> > > ranges are resolved should be completely deterministic and independent
> > > from where the artifact was actually downloaded from, otherwise we'll
> > > end up with no end of build reproducibility problems.
> >
> > In addition, the local repository would be exempt from these rules.
> > This would require manually deleting artifacts from the local repo to
> > ensure that certain versions weren't picked up; a maintenance
> > nightmare I'm sure you'll agree.
> >
> > How's best to proceed with resolving this issue? Would voting make
> > sense, or should the PMC lay down the intended direction? I'm not
> > sure whether this thread needs to get any longer.. :)
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Stephen Connolly <st...@gmail.com>.
IMHO
I think a vote with the two positions clearly identified (perhaps with pros
and cons for both if the pair of ye can agree on the pros and cons). (unless
somebody else has a third position)
-Stephen.
On Jan 30, 2008 12:56 PM, Mark Hobson <ma...@gmail.com> wrote:
> On 30/01/2008, Mark Hobson <ma...@gmail.com> wrote:
> > I don't think that linking this level of artifact resolution
> > uncertainty to its source repository is a good idea. How version
> > ranges are resolved should be completely deterministic and independent
> > from where the artifact was actually downloaded from, otherwise we'll
> > end up with no end of build reproducibility problems.
>
> In addition, the local repository would be exempt from these rules.
> This would require manually deleting artifacts from the local repo to
> ensure that certain versions weren't picked up; a maintenance
> nightmare I'm sure you'll agree.
>
> How's best to proceed with resolving this issue? Would voting make
> sense, or should the PMC lay down the intended direction? I'm not
> sure whether this thread needs to get any longer.. :)
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Version ranges and snapshots
Posted by Mark Hobson <ma...@gmail.com>.
On 30/01/2008, Mark Hobson <ma...@gmail.com> wrote:
> I don't think that linking this level of artifact resolution
> uncertainty to its source repository is a good idea. How version
> ranges are resolved should be completely deterministic and independent
> from where the artifact was actually downloaded from, otherwise we'll
> end up with no end of build reproducibility problems.
In addition, the local repository would be exempt from these rules.
This would require manually deleting artifacts from the local repo to
ensure that certain versions weren't picked up; a maintenance
nightmare I'm sure you'll agree.
How's best to proceed with resolving this issue? Would voting make
sense, or should the PMC lay down the intended direction? I'm not
sure whether this thread needs to get any longer.. :)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Mark Hobson <ma...@gmail.com>.
On 29/01/2008, Michael McCallum <gh...@apache.org> wrote:
> How about for MNG-3092 we make it configurable per repository whether the
> metadata resolution includes snapshots in ranges... you could even default to
> false to keep Dave and yourself happy and I can turn it on where i need it.
>
> I'm not certain if its possible but would perhaps be the most flexible
> compromise.
I don't think that linking this level of artifact resolution
uncertainty to its source repository is a good idea. How version
ranges are resolved should be completely deterministic and independent
from where the artifact was actually downloaded from, otherwise we'll
end up with no end of build reproducibility problems.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
How about for MNG-3092 we make it configurable per repository whether the
metadata resolution includes snapshots in ranges... you could even default to
false to keep Dave and yourself happy and I can turn it on where i need it.
I'm not certain if its possible but would perhaps be the most flexible
compromise.
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Mark Hobson <ma...@gmail.com>.
On 23/01/2008, Michael McCallum <gh...@apache.org> wrote:
> On Thu, 24 Jan 2008 03:42:13 Mark Hobson wrote:
> > There is another caveat in that it's all or nothing. Using a profile
> > mechanism will switch all range dependencies into snapshot mode, when
> > typically a developer only wishes to upgrade a couple. How could this
> > be achieved using profiles?
> i can think of two ways off the top of my head
> * install on the specific project
This doesn't work when suitable snapshot repositories are available to
the project, nor when the local repository contains cached snapshots
from other repositories.
> * selective repositories and profiles for different project groups
I move dependencies to their next snapshot when I need to work on
them, so this option would require a profile per dependency which is
unworkable and extremely error prone.
> The real question is what do you hope to achieve by enabling snapshots for a
> particular project or set of projects. Perhaps a change of direction in the
> discussion do you use multiple lines and merging to manage what your
> releases?
In the simplest case, this is how we typically use snapshots to add a
new feature to a previously released project ("A"):
1) A's component ("B") that the new feature will be added to is identified
2) A's dependency on B is upgraded to the next snapshot version, e.g.
1.1 to 1.2-SNAPSHOT
3) Work is carried out on B to add the new feature, installing locally
to receive the changes
4) Work on B is committed to SCM at suitable points for CI to push
changes to any developers working on the same feature
5) When the work is completed, B is released, e.g. 1.2
6) A's dependency on B is upgraded to the released version, e.g. 1.2
7) A is released
Hence the need to be able to switch a single dependency from a release
to the next snapshot is necessary. Is this use case really that
atypical? Version ranges will work in a similar way but with the
following differences:
2) A's dependency on B is upgraded to the next snapshot version, e.g.
[1.0,2.0) to [1.0,2.0-SNAPSHOT)
...
6) A's dependency on B is upgraded to the released version, e.g. [1.0,2.0)
> At the moment I can do continuous integration in two ways
> * head to head (configure continuum deployment #1 to do clean install)
> * latest relevant release to latest relevant release - using version ranges
> (configure continuum deployment #2 do just do clean test)
>
> With mgn-3092 it will be impossible to take one artifact commit a change to
> the head and see if that breaks any of my other artifacts without changing
> poms. As the #1 won't pickup any changes because snapshot is not explicitly
> selected.
That's the way it normally works. When a project is ready to receive
an upgraded dependency, the dependency is explicitly upgraded,
adjustments are made accordingly, it is then tested and released.
Reproducibility is the focus here, not the ease of upgrading a
project's dependencies; that's what tools should facilitate.
> I think people just overrate what snapshots provide... a non reproducible...
> non rollbackable... changes get pushed on me as a developer so i get broken
> when its incovenient to me...
This is not a problem when managed correctly. Of course, if all
dependencies are left in snapshot on trunk with multiple developers
working on various new features simultaneously, then yes, development
will be troublesome. But feature branches and the emphasis on
releasing often mitigates this.
> I work on the basic premise that the system should be in a state or
> releasability not development. Snapshots just bugger that up. And worse it
> makes people lazy. "Its only a snapshot". Not using snapshots as a norm gives
> me more power to "smack someone in the head" - if you will excuse the
> metaphor - if they are not working responsibly.
Surely having the pom control exact versions of dependencies promotes
reproducibility and releaseability? Having the command line control
them via profiles and the such moves the responsibility to the user,
thus becoming more error prone.
> IMO if its not in source control it does not count, there is no trail, no
> guarantees, no possibility of generating diffs -Perhaps mercurial or svk
> could mitigate that to some extent - and chances are no recent backups.
All source changes that occur in a snapshot are in SCM since that's
what CI builds from?
I really would like to come to a resolution of how we want version
ranges to work within Maven. This is holding up using ranges
seriously and fixing bugs relating to ranges, e.g. MNG-2994,
MRELEASE-318 and of course MNG-3092. I've got some time to be able to
work on these issues but my hands are tied until we have a clear
direction.
Does anyone from the PMC care to comment?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
On Thu, 24 Jan 2008 03:42:13 Mark Hobson wrote:
> Hi Michael,
> There is another caveat in that it's all or nothing. Using a profile
> mechanism will switch all range dependencies into snapshot mode, when
> typically a developer only wishes to upgrade a couple. How could this
> be achieved using profiles?
i can think of two ways off the top of my head
* install on the specific project
* selective repositories and profiles for different project groups
The real question is what do you hope to achieve by enabling snapshots for a
particular project or set of projects. Perhaps a change of direction in the
discussion do you use multiple lines and merging to manage what your
releases?
>
> > I'm concerned that MNG-3092 is a one way street where better more
> > flexible solutions could exist. But having said that if you did fix 3092
> > it would not adversely affect me right now. And if it does... well I'll
> > figure something out.
>
> I can see the theoretical opposition to fixing MNG-3092, but since
> it's impractical and unworkable it seems merely academic. I'm open to
At the moment I can do continuous integration in two ways
* head to head (configure continuum deployment #1 to do clean install)
* latest relevant release to latest relevant release - using version ranges
(configure continuum deployment #2 do just do clean test)
With mgn-3092 it will be impossible to take one artifact commit a change to
the head and see if that breaks any of my other artifacts without changing
poms. As the #1 won't pickup any changes because snapshot is not explicitly
selected.
> suggestions if they still give the efficiency gains that working with
> version ranges will provide.
I think people just overrate what snapshots provide... a non reproducible...
non rollbackable... changes get pushed on me as a developer so i get broken
when its incovenient to me...
I work on the basic premise that the system should be in a state or
releasability not development. Snapshots just bugger that up. And worse it
makes people lazy. "Its only a snapshot". Not using snapshots as a norm gives
me more power to "smack someone in the head" - if you will excuse the
metaphor - if they are not working responsibly.
IMO if its not in source control it does not count, there is no trail, no
guarantees, no possibility of generating diffs -Perhaps mercurial or svk
could mitigate that to some extent - and chances are no recent backups.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Mark Hobson <ma...@gmail.com>.
Hi Michael,
On 23/01/2008, Michael McCallum <gh...@apache.org> wrote:
> Firstly IMHO of MNG-3092 is that is it not the right thing for maven in
> general.
>
> I believe with MNG-2994 and appropriate use of profiles to enable and disable
> snapshot repositories you can have everything that you want and still
> maintain the ability to allow any snapshot to be injected when desired.
> There is a little gem that i discovered - or maybe i just imagined it - the
> resolution tree is built from metadata, if you have no local metadata and
> MNG-2994 is fixed then you can control the resolution of any artifact by
> controlling its set of repositories - irrelevant of if a snapshot is cached
> in the local repo.
>
> There is one caveat: the local repository is a merging of two things... a
> local repository and a cache of remote repositories... which is unfortunate
> because that means deploy ends up installing local metadata and that results
> in my view of snapshots and other peoples views of snapshots being different.
> So the act of deploying or installing breaks the use of repository selection
> because local metadata is always used. Perhaps the 'local' repository
> metadata should be maskable as well. Strictly speaking there is no reason it
> should be treated differently.
There is another caveat in that it's all or nothing. Using a profile
mechanism will switch all range dependencies into snapshot mode, when
typically a developer only wishes to upgrade a couple. How could this
be achieved using profiles?
> I'm concerned that MNG-3092 is a one way street where better more flexible
> solutions could exist. But having said that if you did fix 3092 it would not
> adversely affect me right now. And if it does... well I'll figure something
> out.
I can see the theoretical opposition to fixing MNG-3092, but since
it's impractical and unworkable it seems merely academic. I'm open to
suggestions if they still give the efficiency gains that working with
version ranges will provide.
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
Firstly IMHO of MNG-3092 is that is it not the right thing for maven in
general.
I believe with MNG-2994 and appropriate use of profiles to enable and disable
snapshot repositories you can have everything that you want and still
maintain the ability to allow any snapshot to be injected when desired.
There is a little gem that i discovered - or maybe i just imagined it - the
resolution tree is built from metadata, if you have no local metadata and
MNG-2994 is fixed then you can control the resolution of any artifact by
controlling its set of repositories - irrelevant of if a snapshot is cached
in the local repo.
There is one caveat: the local repository is a merging of two things... a
local repository and a cache of remote repositories... which is unfortunate
because that means deploy ends up installing local metadata and that results
in my view of snapshots and other peoples views of snapshots being different.
So the act of deploying or installing breaks the use of repository selection
because local metadata is always used. Perhaps the 'local' repository
metadata should be maskable as well. Strictly speaking there is no reason it
should be treated differently.
I'm concerned that MNG-3092 is a one way street where better more flexible
solutions could exist. But having said that if you did fix 3092 it would not
adversely affect me right now. And if it does... well I'll figure something
out.
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
Mark,
I added more files to MNG-3351 (since I'm not sure what will be needed).
This issue also relates to MIDEA-84 (I don't know if you use IntelliJ or
not).
Regards,
-Dave
dhoffer wrote:
>
> Mark,
>
> That sounds wonderful. I want to help any way I can!
>
> I attached some test files to MNG-3351 today (pom and settings files). I
> don't know if this is enough, if you need more just let me know I will try
> to get it for you.
>
> I stumbled across MNG-2431 recently, this fix will get this one for free.
> I will look at your other JIRA's to see if I can comment on those.
>
> Again, let me know how I can help, I'd be glad to assist any way possible.
>
> -Dave
>
>
>
> mihobson wrote:
>>
>> I agree with David's comments. Responding to his latest comment on
>> MNG-3092 here to keep discussion out of JIRA:
>>
>> I totally empathise with your situation David. It seems that we're
>> both wishing to use version ranges in the same way, the only
>> difference is that you've bit the bullet already whereas we're waiting
>> for these issues to be resolved before moving to ranges (and in the
>> meantime putting up with a lot of manual dependency management).
>>
>> My current hit list before moving our company to version ranges is:
>> MNG-2994, MNG-3092, MNG-3351, MRELEASE-262. I've got some time to try
>> moving forward with this again so hopefully we can wrap this up once
>> and for all. I'm just getting back up to speed with this issue on the
>> latest maven and release plugin, so any relevant findings would be
>> welcome.
>>
>> Cheers,
>>
>> Mark
>>
>> On 19/01/2008, dhoffer <DH...@xrite.com> wrote:
>>>
>>> I feel this is the most important bug that needs to be fixed. We make
>>> heavy
>>> use of version ranges and without this fix they are unusable (we have to
>>> manually apply a patch to each maven release).
>>>
>>> "1) You wish a release build with no snapshots which is the normal
>>> behaviour
>>> and so you just build the trunk of your artifact and it works...
>>> optionally
>>> the enforcer plugin can ensure that you are not including snapshot
>>> dependencies "
>>> -No it doesn't work. We can't release using version ranges because of
>>> this
>>> bug, (that is what this issue is all about). The enforcer is no fix,
>>> that
>>> doesn't help the release succeed.
>>>
>>> "2) You wish a dev build with all snapshots enabled so you enable a
>>> project
>>> configured in your settings.xml that exposes you snapshot repositories
>>> Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994
>>> first"
>>> -No, that does not work. If I have already specified what versions
>>> (snapshots, version ranges, etc) in my pom that I need, I should not
>>> have to
>>> do a system fix/workaround of modifying my settings.xml to get the pom
>>> to do
>>> what it says. But even if I could do this it will not work, because it
>>> cannot stop the build from getting snapshots from my local repo. For
>>> this
>>> workaround to work I would also have to delete my local repo before each
>>> build!
>>>
>>> "3) You wish a dev build but with only a single snapshot... build the
>>> project you wish a snapshot of into your local repo... build as in #1"
>>> -No again. I don't want to have to build local snapshots first of every
>>> snapshot i want to depend on! Furthermore each developer would have to
>>> do
>>> the same.
>>>
>>> "If we were to fix MNG-3092 then 2 would not be possible... as you would
>>> have to go and edit all your poms to enable snapshots... i have well
>>> over
>>> 100 artifacts and many dependencies that exist in 40 or more projects...
>>> it
>>> seems to be that decent continuous integration would not be possible if
>>> you
>>> fix MNG-3092"
>>> -Again we don't want the settings.xml to control if snapshots are
>>> visible or
>>> not...as discussed, it simply cannot do this job. You have made a
>>> process
>>> that works for you but in essence you do not use snapshots, rather you
>>> make
>>> many releases instead so why would you need to go back and modify your
>>> 40
>>> projects to include snapshots. Now I can see for others that do use
>>> snapshots that it might be nice to have a global override of this
>>> behavior.
>>> That is, I want/need this bug fixed but I suggest we add a new command
>>> line
>>> switch that can optionally be used to keep the behavior as it is.
>>>
>>> I vote to fix this bug. (If it will help I will get my dev team to vote
>>> also!)
>>>
>>>
>>> Michael McCallum-3 wrote:
>>> >
>>> > Back to the origin of the thread
>>> >
>>> > Version ranges with non-snapshot bounds can contain snapshot versions
>>> > http://jira.codehaus.org/browse/MNG-3092
>>> >
>>> >
>>> > I feel that the current behaviour is correct and can be managed
>>> > sufficiently
>>> > by profiles. Let me render some scenarios...
>>> >
>>> > 1) You wish a release build with no snapshots which is the normal
>>> > behaviour
>>> > and so you just build the trunk of your artifact and it works...
>>> > optionally
>>> > the enforcer plugin can ensure that you are not including snapshot
>>> > dependencies
>>> >
>>> > 2) You wish a dev build with all snapshots enabled so you enable a
>>> project
>>> > configured in your settings.xml that exposes you snapshot repositories
>>> > Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994
>>> first
>>> >
>>> > 3) You wish a dev build but with only a single snapshot... build the
>>> > project
>>> > you wish a snapshot of into your local repo... build as in #1
>>> >
>>> >
>>> > If we were to fix MNG-3092 then 2 would not be possible... as you
>>> would
>>> > have
>>> > to go and edit all your poms to enable snapshots... i have well over
>>> 100
>>> > artifacts and many dependencies that exist in 40 or more projects...
>>> it
>>> > seems
>>> > to be that decent continuous integration would not be possible if you
>>> fix
>>> > MNG-3092
>>> >
>>> > Can we start a vote for this issue here I guess the same rules as
>>> releases
>>> > would apply. 72 hours only pmc votes are binding. etc etc
>>> >
>>> > --
>>> > Michael McCallum
>>> > Enterprise Engineer
>>> > mailto:gholam@apache.org
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14967465.html
>>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p15032985.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
Mark,
That sounds wonderful. I want to help any way I can!
I attached some test files to MNG-3351 today (pom and settings files). I
don't know if this is enough, if you need more just let me know I will try
to get it for you.
I stumbled across MNG-2431 recently, this fix will get this one for free. I
will look at your other JIRA's to see if I can comment on those.
Again, let me know how I can help, I'd be glad to assist any way possible.
-Dave
mihobson wrote:
>
> I agree with David's comments. Responding to his latest comment on
> MNG-3092 here to keep discussion out of JIRA:
>
> I totally empathise with your situation David. It seems that we're
> both wishing to use version ranges in the same way, the only
> difference is that you've bit the bullet already whereas we're waiting
> for these issues to be resolved before moving to ranges (and in the
> meantime putting up with a lot of manual dependency management).
>
> My current hit list before moving our company to version ranges is:
> MNG-2994, MNG-3092, MNG-3351, MRELEASE-262. I've got some time to try
> moving forward with this again so hopefully we can wrap this up once
> and for all. I'm just getting back up to speed with this issue on the
> latest maven and release plugin, so any relevant findings would be
> welcome.
>
> Cheers,
>
> Mark
>
> On 19/01/2008, dhoffer <DH...@xrite.com> wrote:
>>
>> I feel this is the most important bug that needs to be fixed. We make
>> heavy
>> use of version ranges and without this fix they are unusable (we have to
>> manually apply a patch to each maven release).
>>
>> "1) You wish a release build with no snapshots which is the normal
>> behaviour
>> and so you just build the trunk of your artifact and it works...
>> optionally
>> the enforcer plugin can ensure that you are not including snapshot
>> dependencies "
>> -No it doesn't work. We can't release using version ranges because of
>> this
>> bug, (that is what this issue is all about). The enforcer is no fix,
>> that
>> doesn't help the release succeed.
>>
>> "2) You wish a dev build with all snapshots enabled so you enable a
>> project
>> configured in your settings.xml that exposes you snapshot repositories
>> Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994
>> first"
>> -No, that does not work. If I have already specified what versions
>> (snapshots, version ranges, etc) in my pom that I need, I should not have
>> to
>> do a system fix/workaround of modifying my settings.xml to get the pom to
>> do
>> what it says. But even if I could do this it will not work, because it
>> cannot stop the build from getting snapshots from my local repo. For
>> this
>> workaround to work I would also have to delete my local repo before each
>> build!
>>
>> "3) You wish a dev build but with only a single snapshot... build the
>> project you wish a snapshot of into your local repo... build as in #1"
>> -No again. I don't want to have to build local snapshots first of every
>> snapshot i want to depend on! Furthermore each developer would have to
>> do
>> the same.
>>
>> "If we were to fix MNG-3092 then 2 would not be possible... as you would
>> have to go and edit all your poms to enable snapshots... i have well over
>> 100 artifacts and many dependencies that exist in 40 or more projects...
>> it
>> seems to be that decent continuous integration would not be possible if
>> you
>> fix MNG-3092"
>> -Again we don't want the settings.xml to control if snapshots are visible
>> or
>> not...as discussed, it simply cannot do this job. You have made a
>> process
>> that works for you but in essence you do not use snapshots, rather you
>> make
>> many releases instead so why would you need to go back and modify your 40
>> projects to include snapshots. Now I can see for others that do use
>> snapshots that it might be nice to have a global override of this
>> behavior.
>> That is, I want/need this bug fixed but I suggest we add a new command
>> line
>> switch that can optionally be used to keep the behavior as it is.
>>
>> I vote to fix this bug. (If it will help I will get my dev team to vote
>> also!)
>>
>>
>> Michael McCallum-3 wrote:
>> >
>> > Back to the origin of the thread
>> >
>> > Version ranges with non-snapshot bounds can contain snapshot versions
>> > http://jira.codehaus.org/browse/MNG-3092
>> >
>> >
>> > I feel that the current behaviour is correct and can be managed
>> > sufficiently
>> > by profiles. Let me render some scenarios...
>> >
>> > 1) You wish a release build with no snapshots which is the normal
>> > behaviour
>> > and so you just build the trunk of your artifact and it works...
>> > optionally
>> > the enforcer plugin can ensure that you are not including snapshot
>> > dependencies
>> >
>> > 2) You wish a dev build with all snapshots enabled so you enable a
>> project
>> > configured in your settings.xml that exposes you snapshot repositories
>> > Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994
>> first
>> >
>> > 3) You wish a dev build but with only a single snapshot... build the
>> > project
>> > you wish a snapshot of into your local repo... build as in #1
>> >
>> >
>> > If we were to fix MNG-3092 then 2 would not be possible... as you would
>> > have
>> > to go and edit all your poms to enable snapshots... i have well over
>> 100
>> > artifacts and many dependencies that exist in 40 or more projects... it
>> > seems
>> > to be that decent continuous integration would not be possible if you
>> fix
>> > MNG-3092
>> >
>> > Can we start a vote for this issue here I guess the same rules as
>> releases
>> > would apply. 72 hours only pmc votes are binding. etc etc
>> >
>> > --
>> > Michael McCallum
>> > Enterprise Engineer
>> > mailto:gholam@apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14967465.html
>> Sent from the Maven Developers mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p15032547.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Mark Hobson <ma...@gmail.com>.
I agree with David's comments. Responding to his latest comment on
MNG-3092 here to keep discussion out of JIRA:
I totally empathise with your situation David. It seems that we're
both wishing to use version ranges in the same way, the only
difference is that you've bit the bullet already whereas we're waiting
for these issues to be resolved before moving to ranges (and in the
meantime putting up with a lot of manual dependency management).
My current hit list before moving our company to version ranges is:
MNG-2994, MNG-3092, MNG-3351, MRELEASE-262. I've got some time to try
moving forward with this again so hopefully we can wrap this up once
and for all. I'm just getting back up to speed with this issue on the
latest maven and release plugin, so any relevant findings would be
welcome.
Cheers,
Mark
On 19/01/2008, dhoffer <DH...@xrite.com> wrote:
>
> I feel this is the most important bug that needs to be fixed. We make heavy
> use of version ranges and without this fix they are unusable (we have to
> manually apply a patch to each maven release).
>
> "1) You wish a release build with no snapshots which is the normal behaviour
> and so you just build the trunk of your artifact and it works... optionally
> the enforcer plugin can ensure that you are not including snapshot
> dependencies "
> -No it doesn't work. We can't release using version ranges because of this
> bug, (that is what this issue is all about). The enforcer is no fix, that
> doesn't help the release succeed.
>
> "2) You wish a dev build with all snapshots enabled so you enable a project
> configured in your settings.xml that exposes you snapshot repositories
> Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994 first"
> -No, that does not work. If I have already specified what versions
> (snapshots, version ranges, etc) in my pom that I need, I should not have to
> do a system fix/workaround of modifying my settings.xml to get the pom to do
> what it says. But even if I could do this it will not work, because it
> cannot stop the build from getting snapshots from my local repo. For this
> workaround to work I would also have to delete my local repo before each
> build!
>
> "3) You wish a dev build but with only a single snapshot... build the
> project you wish a snapshot of into your local repo... build as in #1"
> -No again. I don't want to have to build local snapshots first of every
> snapshot i want to depend on! Furthermore each developer would have to do
> the same.
>
> "If we were to fix MNG-3092 then 2 would not be possible... as you would
> have to go and edit all your poms to enable snapshots... i have well over
> 100 artifacts and many dependencies that exist in 40 or more projects... it
> seems to be that decent continuous integration would not be possible if you
> fix MNG-3092"
> -Again we don't want the settings.xml to control if snapshots are visible or
> not...as discussed, it simply cannot do this job. You have made a process
> that works for you but in essence you do not use snapshots, rather you make
> many releases instead so why would you need to go back and modify your 40
> projects to include snapshots. Now I can see for others that do use
> snapshots that it might be nice to have a global override of this behavior.
> That is, I want/need this bug fixed but I suggest we add a new command line
> switch that can optionally be used to keep the behavior as it is.
>
> I vote to fix this bug. (If it will help I will get my dev team to vote
> also!)
>
>
> Michael McCallum-3 wrote:
> >
> > Back to the origin of the thread
> >
> > Version ranges with non-snapshot bounds can contain snapshot versions
> > http://jira.codehaus.org/browse/MNG-3092
> >
> >
> > I feel that the current behaviour is correct and can be managed
> > sufficiently
> > by profiles. Let me render some scenarios...
> >
> > 1) You wish a release build with no snapshots which is the normal
> > behaviour
> > and so you just build the trunk of your artifact and it works...
> > optionally
> > the enforcer plugin can ensure that you are not including snapshot
> > dependencies
> >
> > 2) You wish a dev build with all snapshots enabled so you enable a project
> > configured in your settings.xml that exposes you snapshot repositories
> > Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994 first
> >
> > 3) You wish a dev build but with only a single snapshot... build the
> > project
> > you wish a snapshot of into your local repo... build as in #1
> >
> >
> > If we were to fix MNG-3092 then 2 would not be possible... as you would
> > have
> > to go and edit all your poms to enable snapshots... i have well over 100
> > artifacts and many dependencies that exist in 40 or more projects... it
> > seems
> > to be that decent continuous integration would not be possible if you fix
> > MNG-3092
> >
> > Can we start a vote for this issue here I guess the same rules as releases
> > would apply. 72 hours only pmc votes are binding. etc etc
> >
> > --
> > Michael McCallum
> > Enterprise Engineer
> > mailto:gholam@apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14967465.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
I feel this is the most important bug that needs to be fixed. We make heavy
use of version ranges and without this fix they are unusable (we have to
manually apply a patch to each maven release).
"1) You wish a release build with no snapshots which is the normal behaviour
and so you just build the trunk of your artifact and it works... optionally
the enforcer plugin can ensure that you are not including snapshot
dependencies "
-No it doesn't work. We can't release using version ranges because of this
bug, (that is what this issue is all about). The enforcer is no fix, that
doesn't help the release succeed.
"2) You wish a dev build with all snapshots enabled so you enable a project
configured in your settings.xml that exposes you snapshot repositories
Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994 first"
-No, that does not work. If I have already specified what versions
(snapshots, version ranges, etc) in my pom that I need, I should not have to
do a system fix/workaround of modifying my settings.xml to get the pom to do
what it says. But even if I could do this it will not work, because it
cannot stop the build from getting snapshots from my local repo. For this
workaround to work I would also have to delete my local repo before each
build!
"3) You wish a dev build but with only a single snapshot... build the
project you wish a snapshot of into your local repo... build as in #1"
-No again. I don't want to have to build local snapshots first of every
snapshot i want to depend on! Furthermore each developer would have to do
the same.
"If we were to fix MNG-3092 then 2 would not be possible... as you would
have to go and edit all your poms to enable snapshots... i have well over
100 artifacts and many dependencies that exist in 40 or more projects... it
seems to be that decent continuous integration would not be possible if you
fix MNG-3092"
-Again we don't want the settings.xml to control if snapshots are visible or
not...as discussed, it simply cannot do this job. You have made a process
that works for you but in essence you do not use snapshots, rather you make
many releases instead so why would you need to go back and modify your 40
projects to include snapshots. Now I can see for others that do use
snapshots that it might be nice to have a global override of this behavior.
That is, I want/need this bug fixed but I suggest we add a new command line
switch that can optionally be used to keep the behavior as it is.
I vote to fix this bug. (If it will help I will get my dev team to vote
also!)
Michael McCallum-3 wrote:
>
> Back to the origin of the thread
>
> Version ranges with non-snapshot bounds can contain snapshot versions
> http://jira.codehaus.org/browse/MNG-3092
>
>
> I feel that the current behaviour is correct and can be managed
> sufficiently
> by profiles. Let me render some scenarios...
>
> 1) You wish a release build with no snapshots which is the normal
> behaviour
> and so you just build the trunk of your artifact and it works...
> optionally
> the enforcer plugin can ensure that you are not including snapshot
> dependencies
>
> 2) You wish a dev build with all snapshots enabled so you enable a project
> configured in your settings.xml that exposes you snapshot repositories
> Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994 first
>
> 3) You wish a dev build but with only a single snapshot... build the
> project
> you wish a snapshot of into your local repo... build as in #1
>
>
> If we were to fix MNG-3092 then 2 would not be possible... as you would
> have
> to go and edit all your poms to enable snapshots... i have well over 100
> artifacts and many dependencies that exist in 40 or more projects... it
> seems
> to be that decent continuous integration would not be possible if you fix
> MNG-3092
>
> Can we start a vote for this issue here I guess the same rules as releases
> would apply. 72 hours only pmc votes are binding. etc etc
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14967465.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
Back to the origin of the thread
Version ranges with non-snapshot bounds can contain snapshot versions
http://jira.codehaus.org/browse/MNG-3092
I feel that the current behaviour is correct and can be managed sufficiently
by profiles. Let me render some scenarios...
1) You wish a release build with no snapshots which is the normal behaviour
and so you just build the trunk of your artifact and it works... optionally
the enforcer plugin can ensure that you are not including snapshot
dependencies
2) You wish a dev build with all snapshots enabled so you enable a project
configured in your settings.xml that exposes you snapshot repositories
Obivously we need to fix... http://jira.codehaus.org/browse/MNG-2994 first
3) You wish a dev build but with only a single snapshot... build the project
you wish a snapshot of into your local repo... build as in #1
If we were to fix MNG-3092 then 2 would not be possible... as you would have
to go and edit all your poms to enable snapshots... i have well over 100
artifacts and many dependencies that exist in 40 or more projects... it seems
to be that decent continuous integration would not be possible if you fix
MNG-3092
Can we start a vote for this issue here I guess the same rules as releases
would apply. 72 hours only pmc votes are binding. etc etc
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
On Tue, 15 Jan 2008 08:43:38 Michael McCallum wrote:
> > It's crazy that version ranges are still unusable in 2.0.8..
> * we can mix and match snapshots during development if we need to
would not appear to work, i could swear i had this working in the last year...
oh well, i can see how that would affect most projects
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
> It's crazy that version ranges are still unusable in 2.0.8..
I disagree entirely.
I use version ranges for a very complex Project... and it works very well
* we have repeatable builds
* we can mix and match snapshots during development if we need to
* releases fail if you have snapshot deps even in ranges and transitions
* this is all out of the box released maven core and plugins
* have modules projects to test that the trunk of all projects builds and
tests against the latest releases of all projects
* have modules projects to test that the trunk of all projects builds and
tests against the latest releases of all projects
what more do you need?
On Tue, 15 Jan 2008 06:41:42 Mark Hobson wrote:
> On 10/01/2008, Michael McCallum <gh...@apache.org> wrote:
> > another thought...
> >
> > by default you could not have snapshot repositories enabled and just
> > enable them with a profile...
> >
> > that way all builds by default have no snapshots, you could even have
> > separate profiles and snapshot repos for different departments to a allow
> > more flexible integration
>
> Unfortunately this won't work either due to
> http://jira.codehaus.org/browse/MNG-2994
>
> Both MNG-2994 and MNG-3092 need to be fixed before we can really start
> using version ranges as they were intended. I think we should just
> stick with the original design docs and apply the patch for MNG-3092.
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
"..It's crazy that version ranges are still unusable in 2.0.8.."
Exactly, we really need this fixed, can we apply this patch so we can use
version ranges and snapshots. This issue is killing us.
-Dave
mihobson wrote:
>
> On 10/01/2008, Michael McCallum <gh...@apache.org> wrote:
>> another thought...
>>
>> by default you could not have snapshot repositories enabled and just
>> enable
>> them with a profile...
>>
>> that way all builds by default have no snapshots, you could even have
>> separate
>> profiles and snapshot repos for different departments to a allow more
>> flexible integration
>
> Unfortunately this won't work either due to
> http://jira.codehaus.org/browse/MNG-2994
>
> Both MNG-2994 and MNG-3092 need to be fixed before we can really start
> using version ranges as they were intended. I think we should just
> stick with the original design docs and apply the patch for MNG-3092.
> It's crazy that version ranges are still unusable in 2.0.8..
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14967237.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Mark Hobson <ma...@gmail.com>.
On 10/01/2008, Michael McCallum <gh...@apache.org> wrote:
> another thought...
>
> by default you could not have snapshot repositories enabled and just enable
> them with a profile...
>
> that way all builds by default have no snapshots, you could even have separate
> profiles and snapshot repos for different departments to a allow more
> flexible integration
Unfortunately this won't work either due to
http://jira.codehaus.org/browse/MNG-2994
Both MNG-2994 and MNG-3092 need to be fixed before we can really start
using version ranges as they were intended. I think we should just
stick with the original design docs and apply the patch for MNG-3092.
It's crazy that version ranges are still unusable in 2.0.8..
Cheers,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
We have thought about this but since it cannot prevent local snapshots it is
not really a solution only a technique to limit the problem. BTW, we use
TeamCity for CI, builds get farmed out to many build agents so what is in
their local repo is quite random; sometimes it works sometimes it doesn't.
We do keep our snapshots on a separate repo (different server port no less)
but again this really doesn't help fix the problem.
There is no solution (we can come up with) other than patching maven. I
have done this and submitted the patch with my JIRA. Unfortunately, my JIRA
got closed in favor of this JIRA w/ patch. But then this discussion started
and no fix has been implemented...
Michael McCallum-3 wrote:
>
> another thought...
>
> by default you could not have snapshot repositories enabled and just
> enable
> them with a profile...
>
> that way all builds by default have no snapshots, you could even have
> separate
> profiles and snapshot repos for different departments to a allow more
> flexible integration
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14748696.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
another thought...
by default you could not have snapshot repositories enabled and just enable
them with a profile...
that way all builds by default have no snapshots, you could even have separate
profiles and snapshot repos for different departments to a allow more
flexible integration
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
"...But at the same time I would never want another department to break my
build
by deploying a snapshot I'm not ready for. "
IMHO, I think our approach excels in making sure this doesn't happen. First
and foremost, if this version range issue can be fixed, snapshots will never
be considered valid unless explicitly asked for. Therefore snapshot deploys
will never be a problem for me. Currently I can't even release because
snapshots are not filtered out.
"... Did we not start this
whole discussion because you wanted artifact resolution to not work
transparently with snapshots? i.e. you have to explicitly mention snapshots
in the ranges as defined the original maven2 dependency spec."
Yes exactly, if I don't explicitly mention a snapshot on either end of an
inclusive version range I don't want snapshots to be part of my build.
"...BTW snapshots are not filtered/faulted by the release plugin when
defined in
ranges, it would appear to work on the defined not resolved dependencies...
you have to use the enforcer plugin which works on the resolved tree."
Hum, not sure. I briefly looked at the enforcer plugin and it didn't seem
like it was something that should be required use here; i.e. to fix this
issue.
In summary, I think your process and mine are similar yet different.
Similar in that we have lots of projects and internal dependencies and we
want projects to 'automatically' use later versions. Different in that I
move all the 'bad releases' to snapshots which essentially go away when not
needed anymore. I vote we fix this issue such that version ranges work for
both of us (and others), if this requires a command line option (or
something) that is fine with me.
BTW, our CI server does clean deploys on all SVN checkins; releases never
occur unless we push the release button.
Michael McCallum-3 wrote:
>
> All fair comments. We don't release documentation for each release.
> site-deploys are independent. And we have perhaps fewer people.
>
> But at the same time I would never want another department to break my
> build
> by deploying a snapshot I'm not ready for.
>
> Quite possibly we could make more use of snapshots. Did we not start this
> whole discussion because you wanted artifact resolution to not work
> transparently with snapshots? i.e. you have to explicitly mention
> snapshots
> in the ranges as defined the original maven2 dependency spec.
>
> BTW snapshots are not filtered/faulted by the release plugin when defined
> in
> ranges, it would appear to work on the defined not resolved
> dependencies...
> you have to use the enforcer plugin which works on the resolved tree.
>
> cheers
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14689271.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
All fair comments. We don't release documentation for each release.
site-deploys are independent. And we have perhaps fewer people.
But at the same time I would never want another department to break my build
by deploying a snapshot I'm not ready for.
Quite possibly we could make more use of snapshots. Did we not start this
whole discussion because you wanted artifact resolution to not work
transparently with snapshots? i.e. you have to explicitly mention snapshots
in the ranges as defined the original maven2 dependency spec.
BTW snapshots are not filtered/faulted by the release plugin when defined in
ranges, it would appear to work on the defined not resolved dependencies...
you have to use the enforcer plugin which works on the resolved tree.
cheers
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
"...but anything that i share with other developers has a
release version. Each of our artifacts that in active development will get
released at least once a day."
That strikes me as working against the grain of agile development. Our
developers work across components and need to link in that new component
build right now, not next day 'when the other department makes that change
and makes the daily release'. We want to be continually refactoring code
and often we find we need to move some application logic into a shared
component. We want to do that now and let all developers get that change
now. (And I don't want to be forced to making a release each time, we often
do if we are done, but this should be flexable.)
"...the main reason being that i should not go
messing with other developers environments unless I am confident that all
the
tests pass and the code works the same or better than before. "
I don't disagree, all tests pass just the same it doesn't matter if its a
snapshot or release. Maven is designed so developers can link with either
snapshots and/or releases it should not matter.
"...I want a tool than gives me the power to define exactly what I am
deploying
and allow me to easily develop that and patch it if necessary. We are
working
with over 11 projects composed of 130 or so artifacts. It all works very
well
without snapshots being deployed. We do of course make use of snapshots in
our local repositories though."
Here too I don't disagree, snapshots are not supposed to be released and we
would never do so. We only release releases, the release-plugin enforces
this anyway. I don't disagree that you can't do what you say...I'm just
saying that you should not HAVE to make as fine grained of releases as you
do so that version ranges work. IMHO, your work-around degrades releases to
less than they should be. Not only is a release a time consuming task, it
generates reports, sites, etc. I want developers to know they can trust and
rely on these releases with the corresponding documentation. It would be
quite a nightmare if instead of the 100 minor releases I have now I have
10000 minor releases and have to keep track of good vs. bad ones, etc.
"...Once of my major beefs about snapshots being deployed is that you get to
a
point where you want to make Release and have to unroll and whole tangle of
transitive snapshots. We make at least one Release everyday and really need
a
fully consistent ready to deploy tree of artifacts."
We use snapshots and don't have to unroll anything. We simply go about
making the release of the snapshot. All regular projects use version ranges
to automatically get that new release. The one project that was using that
snapshot now gets updated to remove the reference to a snapshot (back to
full version range).
"...We mark the completion of a task as the release of the artifact... so if
you
have developers willy nilly deploying snapshots as a single developer i
cannot easily mark the end of my work without rolling up other peoples as
well. The simplest solution is to require by process that people release
things regularly. And use metadata - or otherwise -to manage horribly broken
artifacts, which very rarely happen with decent tests."
At the end of a task, we too release the artifact; else you really aren't
done! I guess the big difference is that I don't need any metadata...I let
maven do it all. Releases are just that known good releases and snapshots
are everything else...they just go away when not needed anymore.
"...In any case My vote would be for maintaining the current behaviour and
allowing an option to change it at runtime or on the command line. You run
the risk of breaking builds otherwise."
I don't know what you mean by "option to change it at runtime or on the
command line". Yes if there is a way to optionally get either behavior I
would like to discuss this. However I don't see why your vote would be to
maintain the current behavior. You don't use snapshots anyway so what does
it matter to you? I do and with them version ranges is broken, lets fix it
and we both get what we want. I don't understand the last statement 'You
run the risk of breaking builds otherwise.'
Michael McCallum-3 wrote:
>
> On Tue, 08 Jan 2008 14:25:06 dhoffer wrote:
>> Regarding 1: Well that's not normal maven operation. You apparently
>> have
>> created a 'work-around' that works for you...I prefer to fix the bug so
>> it
>> works as it is specified.
>>
>> There are lots of reasons to deploy snapshots. Normal maven behavior is
>> that everything, in development, is always a snapshot. You have to
>> deploy
>> these so they can be used by others; now we do keep these on a separate
>> repo, never mixed with releases.
>>
> Perhaps the implementor realised the spec wasn't right and failed to
> update
> the docs...
>
> Anyway to snapshots, well the pom thats in the trunk of any artifact has a
> snapshot version but anything that i share with other developers has a
> release version. Each of our artifacts that in active development will get
> released at least once a day. The main reason being that i should not go
> messing with other developers environments unless I am confident that all
> the
> tests pass and the code works the same or better than before.
>
> I want a tool than gives me the power to define exactly what I am
> deploying
> and allow me to easily develop that and patch it if necessary. We are
> working
> with over 11 projects composed of 130 or so artifacts. It all works very
> well
> without snapshots being deployed. We do of course make use of snapshots in
> our local repositories though.
>
> Once of my major beefs about snapshots being deployed is that you get to a
> point where you want to make Release and have to unroll and whole tangle
> of
> transitive snapshots. We make at least one Release everyday and really
> need a
> fully consistent ready to deploy tree of artifacts.
>
> We mark the completion of a task as the release of the artifact... so if
> you
> have developers willy nilly deploying snapshots as a single developer i
> cannot easily mark the end of my work without rolling up other peoples as
> well. The simplest solution is to require by process that people release
> things regularly. And use metadata - or otherwise -to manage horribly
> broken
> artifacts, which very rarely happen with decent tests.
>
> Consider one of my least favourite quotes "But it worked yesterday!"
>
> For stable artifacts the rate of commits/checkin to releases is close to
> 1:1.
> For developing artifacts its much higher.
>
> In any case My vote would be for maintaining the current behaviour and
> allowing an option to change it at runtime or on the command line. You run
> the risk of breaking builds otherwise.
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14681397.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
On Tue, 08 Jan 2008 14:25:06 dhoffer wrote:
> Regarding 1: Well that's not normal maven operation. You apparently have
> created a 'work-around' that works for you...I prefer to fix the bug so it
> works as it is specified.
>
> There are lots of reasons to deploy snapshots. Normal maven behavior is
> that everything, in development, is always a snapshot. You have to deploy
> these so they can be used by others; now we do keep these on a separate
> repo, never mixed with releases.
>
Perhaps the implementor realised the spec wasn't right and failed to update
the docs...
Anyway to snapshots, well the pom thats in the trunk of any artifact has a
snapshot version but anything that i share with other developers has a
release version. Each of our artifacts that in active development will get
released at least once a day. The main reason being that i should not go
messing with other developers environments unless I am confident that all the
tests pass and the code works the same or better than before.
I want a tool than gives me the power to define exactly what I am deploying
and allow me to easily develop that and patch it if necessary. We are working
with over 11 projects composed of 130 or so artifacts. It all works very well
without snapshots being deployed. We do of course make use of snapshots in
our local repositories though.
Once of my major beefs about snapshots being deployed is that you get to a
point where you want to make Release and have to unroll and whole tangle of
transitive snapshots. We make at least one Release everyday and really need a
fully consistent ready to deploy tree of artifacts.
We mark the completion of a task as the release of the artifact... so if you
have developers willy nilly deploying snapshots as a single developer i
cannot easily mark the end of my work without rolling up other peoples as
well. The simplest solution is to require by process that people release
things regularly. And use metadata - or otherwise -to manage horribly broken
artifacts, which very rarely happen with decent tests.
Consider one of my least favourite quotes "But it worked yesterday!"
For stable artifacts the rate of commits/checkin to releases is close to 1:1.
For developing artifacts its much higher.
In any case My vote would be for maintaining the current behaviour and
allowing an option to change it at runtime or on the command line. You run
the risk of breaking builds otherwise.
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
Regarding 1: Well that's not normal maven operation. You apparently have
created a 'work-around' that works for you...I prefer to fix the bug so it
works as it is specified.
There are lots of reasons to deploy snapshots. Normal maven behavior is
that everything, in development, is always a snapshot. You have to deploy
these so they can be used by others; now we do keep these on a separate
repo, never mixed with releases.
I agree with incrementing major version for breaking change. However this
does not eliminate the need for snapshots. Not every check-in should be a
release! Releases should be when you estimate you have enough 'correct'
checkins to warrant a release. It sounds like you may not be using
snapshots with version ranges simply because of this bug!?! BTW, because of
the rule that only major version changes should break the API; this is why
we really want/need to use version ranges. I.e. we always want builds to
get the later versions.
I would say that releases should never be broken; once you make a release
you are committed to it! As you say, you can make a X.Y.Z release if you
find a bug.
Furthermore you cannot solve this problem by saying you don't deploy
snapshots to remote repos. If you have one in your local repo you have the
same problem. There is no mechanism to prevent usage of your local repo!
Regarding 2: I have no idea what the enforcer plugin is, I will check it
out. Again I should not be forced into a 'work-around'. For instance, it's
not just releases that are a problem. When I run the idea plugin, for
instance, I don't want it to include snapshots either. All this would work
if version ranges worked as specified.
Regarding 3: I concur.
Michael McCallum-3 wrote:
>
> We just avoid that being an issue in three ways...
>
> 1) I slap anyone around who deploys a snapshot to a remote repository
> unless
> they have a _very_ good excuse. My method is to increment the major
> version
> if there is a breaking change and release early to avoid the need for
> snapshots. Ideally the repository would support sufficient metadata to tag
> releases as broken... but we get by for now.
>
> 2) enforcer plugin to stop releases having snapshots in them
>
> 3) all our versions are X.Y you only ever get X.Y.Z when you have patched
> a
> change to a library deployed into production
>
>
> On Tue, 08 Jan 2008 07:13:42 dhoffer wrote:
>> Which maven release/build is this in?
>>
>> Based on my understanding I don't think this is sufficient to resolve
>> this
>> issue. It needs to exclude 1.0.4-SNAPSHOT as well, let me try to
>> explain.
>>
>> If I specify a version range of [1.0,2.0) for a dependency, what I am
>> saying is that I will accept any RELEASED version from 1.0 (inclusive) to
>> 2.0 (exclusive). I am not saying I want any SNAPSHOTS to be allowed.
>> The
>> only time a SNAPSHOT should be allowed is when it is specified by an
>> inclusive version range boundary.
>>
>> Michael McCallum-3 wrote:
>> > you can specify a range [1.0,1.1-!) which will stop 1.1-SNAPSHOT from
>> > being
>> > included, this wont stop 1.0.4-SNAPSHOT but i think thats valid
>> anyway...
>> >
>> > On Sun, 06 Jan 2008 14:39:37 dhoffer wrote:
>> >> What is the status of this? This issue is very serious (highest
>> >> priority)
>> >> for us; every time we update maven we have to apply a patch to fix
>> this
>> >> else releases fail.
>> >>
>> >> Can we come to some conclusion on how to fix this?
>> >>
>> >> -Dave
>> >>
>> >> mihobson wrote:
>> >> > Hi,
>> >> >
>> >> > Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
>> >> > contrary to the 2.0 design docs:
>> >> >
>> >> > http://jira.codehaus.org/browse/MNG-3092
>> >> >
>> >> > Brett, Kenney and myself had a brief discussion on IRC about this:
>> >> > Kenney says that the behaviour is theoretically correct (which it
>> is),
>> >> > although I feel it goes against the practical usage described in the
>> >> > docs. The two main choices I can see are:
>> >> >
>> >> > 1) We stick to the design docs and disallow snapshots in ranges when
>> >> > they aren't an explicit boundary, as per the MNG-3092 patch.
>> >> >
>> >> > 2) We reconsider the design docs and leave range resolution behaving
>> >> > as it is, then use profiles to enable or disable snapshot
>> repositories
>> >> > at build time.
>> >> >
>> >> > Any thoughts?
>> >> >
>> >> > Mark
>> >> >
>> >> >
>> ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> > --
>> > Michael McCallum
>> > Enterprise Engineer
>> > mailto:gholam@apache.org
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14680482.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
We just avoid that being an issue in three ways...
1) I slap anyone around who deploys a snapshot to a remote repository unless
they have a _very_ good excuse. My method is to increment the major version
if there is a breaking change and release early to avoid the need for
snapshots. Ideally the repository would support sufficient metadata to tag
releases as broken... but we get by for now.
2) enforcer plugin to stop releases having snapshots in them
3) all our versions are X.Y you only ever get X.Y.Z when you have patched a
change to a library deployed into production
On Tue, 08 Jan 2008 07:13:42 dhoffer wrote:
> Which maven release/build is this in?
>
> Based on my understanding I don't think this is sufficient to resolve this
> issue. It needs to exclude 1.0.4-SNAPSHOT as well, let me try to explain.
>
> If I specify a version range of [1.0,2.0) for a dependency, what I am
> saying is that I will accept any RELEASED version from 1.0 (inclusive) to
> 2.0 (exclusive). I am not saying I want any SNAPSHOTS to be allowed. The
> only time a SNAPSHOT should be allowed is when it is specified by an
> inclusive version range boundary.
>
> Michael McCallum-3 wrote:
> > you can specify a range [1.0,1.1-!) which will stop 1.1-SNAPSHOT from
> > being
> > included, this wont stop 1.0.4-SNAPSHOT but i think thats valid anyway...
> >
> > On Sun, 06 Jan 2008 14:39:37 dhoffer wrote:
> >> What is the status of this? This issue is very serious (highest
> >> priority)
> >> for us; every time we update maven we have to apply a patch to fix this
> >> else releases fail.
> >>
> >> Can we come to some conclusion on how to fix this?
> >>
> >> -Dave
> >>
> >> mihobson wrote:
> >> > Hi,
> >> >
> >> > Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
> >> > contrary to the 2.0 design docs:
> >> >
> >> > http://jira.codehaus.org/browse/MNG-3092
> >> >
> >> > Brett, Kenney and myself had a brief discussion on IRC about this:
> >> > Kenney says that the behaviour is theoretically correct (which it is),
> >> > although I feel it goes against the practical usage described in the
> >> > docs. The two main choices I can see are:
> >> >
> >> > 1) We stick to the design docs and disallow snapshots in ranges when
> >> > they aren't an explicit boundary, as per the MNG-3092 patch.
> >> >
> >> > 2) We reconsider the design docs and leave range resolution behaving
> >> > as it is, then use profiles to enable or disable snapshot repositories
> >> > at build time.
> >> >
> >> > Any thoughts?
> >> >
> >> > Mark
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > --
> > Michael McCallum
> > Enterprise Engineer
> > mailto:gholam@apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
Which maven release/build is this in?
Based on my understanding I don't think this is sufficient to resolve this
issue. It needs to exclude 1.0.4-SNAPSHOT as well, let me try to explain.
If I specify a version range of [1.0,2.0) for a dependency, what I am saying
is that I will accept any RELEASED version from 1.0 (inclusive) to 2.0
(exclusive). I am not saying I want any SNAPSHOTS to be allowed. The only
time a SNAPSHOT should be allowed is when it is specified by an inclusive
version range boundary.
Michael McCallum-3 wrote:
>
> you can specify a range [1.0,1.1-!) which will stop 1.1-SNAPSHOT from
> being
> included, this wont stop 1.0.4-SNAPSHOT but i think thats valid anyway...
>
>
> On Sun, 06 Jan 2008 14:39:37 dhoffer wrote:
>> What is the status of this? This issue is very serious (highest
>> priority)
>> for us; every time we update maven we have to apply a patch to fix this
>> else releases fail.
>>
>> Can we come to some conclusion on how to fix this?
>>
>> -Dave
>>
>> mihobson wrote:
>> > Hi,
>> >
>> > Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
>> > contrary to the 2.0 design docs:
>> >
>> > http://jira.codehaus.org/browse/MNG-3092
>> >
>> > Brett, Kenney and myself had a brief discussion on IRC about this:
>> > Kenney says that the behaviour is theoretically correct (which it is),
>> > although I feel it goes against the practical usage described in the
>> > docs. The two main choices I can see are:
>> >
>> > 1) We stick to the design docs and disallow snapshots in ranges when
>> > they aren't an explicit boundary, as per the MNG-3092 patch.
>> >
>> > 2) We reconsider the design docs and leave range resolution behaving
>> > as it is, then use profiles to enable or disable snapshot repositories
>> > at build time.
>> >
>> > Any thoughts?
>> >
>> > Mark
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> --
> Michael McCallum
> Enterprise Engineer
> mailto:gholam@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14672336.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Michael McCallum <gh...@apache.org>.
you can specify a range [1.0,1.1-!) which will stop 1.1-SNAPSHOT from being
included, this wont stop 1.0.4-SNAPSHOT but i think thats valid anyway...
On Sun, 06 Jan 2008 14:39:37 dhoffer wrote:
> What is the status of this? This issue is very serious (highest priority)
> for us; every time we update maven we have to apply a patch to fix this
> else releases fail.
>
> Can we come to some conclusion on how to fix this?
>
> -Dave
>
> mihobson wrote:
> > Hi,
> >
> > Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
> > contrary to the 2.0 design docs:
> >
> > http://jira.codehaus.org/browse/MNG-3092
> >
> > Brett, Kenney and myself had a brief discussion on IRC about this:
> > Kenney says that the behaviour is theoretically correct (which it is),
> > although I feel it goes against the practical usage described in the
> > docs. The two main choices I can see are:
> >
> > 1) We stick to the design docs and disallow snapshots in ranges when
> > they aren't an explicit boundary, as per the MNG-3092 patch.
> >
> > 2) We reconsider the design docs and leave range resolution behaving
> > as it is, then use profiles to enable or disable snapshot repositories
> > at build time.
> >
> > Any thoughts?
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
--
Michael McCallum
Enterprise Engineer
mailto:gholam@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
What is the status of this? This issue is very serious (highest priority)
for us; every time we update maven we have to apply a patch to fix this else
releases fail.
Can we come to some conclusion on how to fix this?
-Dave
mihobson wrote:
>
> Hi,
>
> Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
> contrary to the 2.0 design docs:
>
> http://jira.codehaus.org/browse/MNG-3092
>
> Brett, Kenney and myself had a brief discussion on IRC about this:
> Kenney says that the behaviour is theoretically correct (which it is),
> although I feel it goes against the practical usage described in the
> docs. The two main choices I can see are:
>
> 1) We stick to the design docs and disallow snapshots in ranges when
> they aren't an explicit boundary, as per the MNG-3092 patch.
>
> 2) We reconsider the design docs and leave range resolution behaving
> as it is, then use profiles to enable or disable snapshot repositories
> at build time.
>
> Any thoughts?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tp11464715s177p14642183.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
This approach will not work because one would then have to continually
specify what snapshots to exclude. We use version ranges to specify the
range of valid released versions. I.e. when building get the latest
released version (in most all cases). What is need is to somehow disallow
all snapshots.
This is a blocking bug for us with maven. We use a custom build that fixes
this issue (does not allow snapshots). The feature of version ranges is not
usable without this fix.
Kenney Westerhof-3 wrote:
>
>
>
> Patrick Schneider wrote:
>> For now, I'm a fan of disallowing snapshots when they are not explicitly
>> in
>> the boundary, as per the patch.
>>
>> In my mind, the problem with a profile flag is that it's an
>> all-or-nothing
>> proposition. Any released artifacts with version ranges will also start
>> to
>> pull in snapshots. There wouldn't be enough control, IMO.
>>
>
> You can always exclude snapshots explicitly:
>
> [1.0,1.1-SNAPSHOT),(1.1-SNAPSHOT,1.1]
>
> Snapshots are valid versions in a range [1.0, 1.1], or even [1.0, 1.1).
>
> Personally I'm +1 for updating the docs, and let the presence of snapshot
> repo's
> and valid snapshot artifacts there determine wheter snapshots are used or
> not.
>
> -- Kenney
>
>
>>
>> Patrick
>>
>> On 7/6/07, Mark Hobson <ma...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
>>> contrary to the 2.0 design docs:
>>>
>>> http://jira.codehaus.org/browse/MNG-3092
>>>
>>> Brett, Kenney and myself had a brief discussion on IRC about this:
>>> Kenney says that the behaviour is theoretically correct (which it is),
>>> although I feel it goes against the practical usage described in the
>>> docs. The two main choices I can see are:
>>>
>>> 1) We stick to the design docs and disallow snapshots in ranges when
>>> they aren't an explicit boundary, as per the MNG-3092 patch.
>>>
>>> 2) We reconsider the design docs and leave range resolution behaving
>>> as it is, then use profiles to enable or disable snapshot repositories
>>> at build time.
>>>
>>> Any thoughts?
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tf4035629s177.html#a13164246
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
...be sure to cast your ballot for MNG-3092:)
ossi petz-2 wrote:
>
> hallo
>
> i would like to add one vote to exclude snapshots from version ranges
> that do not declare them.
>
> we encounter two problematic situations:
>
> when using the release plugin we need to clean the local repository from
> snapshots to make sure no snapshots end up in the build or any assembly.
>
> the situation is different in active development. somtimes a new version
> of a dependecy is required. this will be the next snapshot. imagine a
> range [1.1,2.0). the next snapshot is 1.2-SNAPSHOT. yet this must not be
> used in releases. its only the developer that needs to use the snapshot.
> something like [1.1,2.0)-SNAPSHOT could indicate to find the newest
> version including snapshots.
>
> as not every deloper should have to locally build/install the module we
> use a CI server too (clean deploy). if the pom does not tell exaclty
> which version is ok, we currently have the situation that released
> versions are downloaded from the repository, but snapshots are only
> ocnsidered if they are available in the local repository.
>
> so to make things clear for both the release man and the developer an
> explicit snaphot 'flag' or statement to specify the version range with
> or without snapshots would definitly improve the situation.
>
> currently the builds are not reproducable. they depend on the current
> state of the local repository.
>
>
> regards
>
> ossi
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tf4035629s177.html#a13253264
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by ossi petz <os...@hallo.ms>.
hallo
i would like to add one vote to exclude snapshots from version ranges
that do not declare them.
we encounter two problematic situations:
when using the release plugin we need to clean the local repository from
snapshots to make sure no snapshots end up in the build or any assembly.
the situation is different in active development. somtimes a new version
of a dependecy is required. this will be the next snapshot. imagine a
range [1.1,2.0). the next snapshot is 1.2-SNAPSHOT. yet this must not be
used in releases. its only the developer that needs to use the snapshot.
something like [1.1,2.0)-SNAPSHOT could indicate to find the newest
version including snapshots.
as not every deloper should have to locally build/install the module we
use a CI server too (clean deploy). if the pom does not tell exaclty
which version is ok, we currently have the situation that released
versions are downloaded from the repository, but snapshots are only
ocnsidered if they are available in the local repository.
so to make things clear for both the release man and the developer an
explicit snaphot 'flag' or statement to specify the version range with
or without snapshots would definitly improve the situation.
currently the builds are not reproducable. they depend on the current
state of the local repository.
regards
ossi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
>Quote:
I think snapshots are a different aspect, outside of version ranges. Version
ranges are meant to specify a range of versions. Snapshots fit perfectly
in a version range.
>
The problem with the statement that 'snapshots fit perfectly in a version
range' is that it missing the point. You are technically correct; a
snapshot is a version that precedes its version number. However that is not
the point when you are specifying the version tag of a dependency. The
problem with allowing snapshots to fill version ranges unless specified in
the version range is that it is inconsistent behavior with how non-version
ranges work. If I don't use version ranges I get precise control over
snapshots/non-snapshots. I.e. if I specify 1.2 I will never get a snapshot,
if I specify 1.3-SNAPSHOT I will always get a snapshot. I get what I
specified. Currently if I use version ranges I loose control. I expect the
same behavior. If I specify [1.0, 2.0) I do not expect snapshots because I
did not specify a snapshot. On the other hand if I specify
[1.0,1.5-SNAPSHOT) I would expect the 1.5-SNAPSHOT to fulfill the
requirement.
>Quote:
So you want to prevent accidental use of snapshots when released versions
are available in the given range.
>
No, I don't want what is available to determine what is used. I want the
version range to never include a snapshot unless directed. I want the
version (range) to determine the resolved version nothing else.
>Quote:
Having a mechanism in place to explicitly state what dependencies can be
resolved
to snapshot versions, and what dependencies cannot is certainly useful
>
Yes, this would be useful.
>Quote:
So what we're dealing here is a way to do that. This has nothing to do with
version
ranges but with being able to say that you don't want snapshots for a
certain
artifact. Specifying a normal version (without SNAPSHOT) is not going to be
resolved to a snapshot,
unless there's another declaration that does mention it, and with version
ranges that could happen.
The current resolution mechanism uses the first match, so it's pretty random
(the order of the searched repositories is important here).
>
It is not good to have random results, the build should not be dependent on
order.
>Quote:
If someone specifies a version range, he doesn't care about the version
except that it must
be in that range because he knows those versions work. SNAPSHOTs that fall
into that range
are compatible, so why can't they be used?
What about other dependencies that _are_ declared as a snapshot and bring in
a SNAPSHOT version
also declared somewhere else with a SNAPSHOT-excluding range? Should the
build fail then?
>
You cannot say that snapshot version work because they fall into the
technical definition of a version range. Yes the goal of a snapshot that
did not change the major version would be for the API to not break anything
but one cannot guarentee this. Snapshots may be alpha versions where the
API was changed experimentally to see if something will work...it may not
work and will be reverted. Snapshots are potentially in a state of change
and one should not assume anything about them.
As for your case of specifying a snapshot dependency and also the same
dependency as a version range...No I don't think the build should fail. In
this case you are stating explicitly that you want to use a snapshot version
and you are willing to take the associated risks. As a practical matter the
only way this is possible if for the version range to be specified in one of
the child dependencies which is at least one level lower then where you
specified the snapshot dependency. This case is not much different than
what would maven do if the other dependency version was a
fixed-non-version-range version.
>Quote:
Anyway, we could just 'assume' that when people specify version ranges they
don't want
snapshots and apply this change. I'm just worried about the side effects,
since A (using snapshots
in ranges) is possible now and B (excluding snapshots in ranges) is
cumbersome,
but when we apply this, B is possible but A is even more cumbersome.
>
Currently B is not possible. I have no way today of disallowing snapshots
when I use version ranges to state I want the latest released version. I.e.
[1.0,2.0). This is why we are forced to use our own build of maven today.
I really want to use public releases of maven!
>Quote:
Ow, just thought of something - have 'processing instructions' or similar in
the version ranges,
like [1.0,2.0){snapshots=off} (or just use xml attributes ofcourse ;))
>
Yes, this is a good idea. It allows finer control over the meaning of the
range. I.e. I would still allow snapshots if explicitly stated in the
version range as per the docs.
One more thought on this issue. I think it would be useful to have a way to
over-ride the version range behavior with a command line switch. There is
one use case where it would be useful for version ranges to always pull in
snapshots. Let me backup for a moment to explain. Our build server deploys
snapshots upon every code commit, i.e. clean deploy goal. (We don't want
all other builds to get these snapshots during their normal processes hence
this version range issue.) It would be somewhat helpful to be able to run
something like -AllowSnapshots=true clean verify on other dependent projects
just to ascertain if the snapshot did break anything. In this mode it does
bring in the next snapshot and if our automated server ran this on all
dependent projects we could find out sooner if a proposed change to an
artifact is going to break something. Note I would rate this feature as
minor compared to the resolution of how to limit version ranges to not
include snapshots by default.
-Dave
Kenney Westerhof-3 wrote:
>
>
>
> Max Bowsher wrote:
>> Kenney Westerhof wrote:
>>>
>>> Patrick Schneider wrote:
>>>> For now, I'm a fan of disallowing snapshots when they are not
>>>> explicitly in
>>>> the boundary, as per the patch.
>>>>
>>>> In my mind, the problem with a profile flag is that it's an
>>>> all-or-nothing
>>>> proposition. Any released artifacts with version ranges will also
>>>> start to
>>>> pull in snapshots. There wouldn't be enough control, IMO.
>>>>
>>> You can always exclude snapshots explicitly:
>>>
>>> [1.0,1.1-SNAPSHOT),(1.1-SNAPSHOT,1.1]
>>>
>>> Snapshots are valid versions in a range [1.0, 1.1], or even [1.0, 1.1).
>>>
>>> Personally I'm +1 for updating the docs, and let the presence of
>>> snapshot repo's
>>> and valid snapshot artifacts there determine wheter snapshots are used
>>> or not.
>>
>> Not only is the syntax above very cumbersome, but what about the
>> possibility of 1.0.1-SNAPSHOT, etc?
>
> Ah. Yes indeed. That'll be really cumbersome.
>
>> Controlling this through snapshot repo presence/absence would be rather
>> suboptimal, because you couldn't pull in a snapshot for one particular
>> artifact without possibly getting unwanted snapshots for other
>> dependency artifacts published in the same repo.
>
> True, though the proposed change will only affect version ranges, not
> versions.
>
> I think snapshots are a different aspect, outside of version ranges.
> Version
> ranges are meant to specify a range of versions. Snapshots fit perfectly
> in a version range.
>
> So you want to prevent accidental use of snapshots when released versions
> are available in the given range.
>
> Having a mechanism in place to explicitly state what dependencies can be
> resolved
> to snapshot versions, and what dependencies cannot is certainly useful
>
> So what we're dealing here is a way to do that. This has nothing to do
> with version
> ranges but with being able to say that you don't want snapshots for a
> certain
> artifact. Specifying a normal version (without SNAPSHOT) is not going to
> be resolved to a snapshot,
> unless there's another declaration that does mention it, and with version
> ranges that could happen.
> The current resolution mechanism uses the first match, so it's pretty
> random
> (the order of the searched repositories is important here).
>
> If someone specifies a version range, he doesn't care about the version
> except that it must
> be in that range because he knows those versions work. SNAPSHOTs that fall
> into that range
> are compatible, so why can't they be used?
> What about other dependencies that _are_ declared as a snapshot and bring
> in a SNAPSHOT version
> also declared somewhere else with a SNAPSHOT-excluding range? Should the
> build fail then?
>
> Most importantly, making this change prevents snapshots from being used in
> version ranges.
> Sure, you can explicitly mention them in the range, but you'd have the
> same problem
> as the other way around: specifying 1.0.1-SNAPSHOT, 1.0.2-SNAPSHOT etc..
>
> It seems we want more fine grained control on this matter.
> We could change the order of resolution to first check for non-snapshots,
> then for snapshots, so a non-snapshot will be used when it's possible.
> That would solve the problem,
> except for people who want to use snapshots.
> Another solution would be to somehow mark wheter a dependency or version
> range should
> include or exclude snapshots, or add information to repositories
> specifying the groupid/artifactids
> they provide or must not provide. That way you can declare the same repo
> twice, once with snapshots enabled
> and once without, listing the dependencies.
>
> Not sure if this is worth the trouble though..
>
> Anyway, we could just 'assume' that when people specify version ranges
> they don't want
> snapshots and apply this change. I'm just worried about the side effects,
> since A (using snapshots
> in ranges) is possible now and B (excluding snapshots in ranges) is
> cumbersome,
> but when we apply this, B is possible but A is even more cumbersome.
>
> Ow, just thought of something - have 'processing instructions' or similar
> in the version ranges,
> like [1.0,2.0){snapshots=off} (or just use xml attributes ofcourse ;))
>
> -- Kenney
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tf4035629s177.html#a13174214
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Kenney Westerhof <ke...@apache.org>.
Max Bowsher wrote:
> Kenney Westerhof wrote:
>>
>> Patrick Schneider wrote:
>>> For now, I'm a fan of disallowing snapshots when they are not
>>> explicitly in
>>> the boundary, as per the patch.
>>>
>>> In my mind, the problem with a profile flag is that it's an
>>> all-or-nothing
>>> proposition. Any released artifacts with version ranges will also
>>> start to
>>> pull in snapshots. There wouldn't be enough control, IMO.
>>>
>> You can always exclude snapshots explicitly:
>>
>> [1.0,1.1-SNAPSHOT),(1.1-SNAPSHOT,1.1]
>>
>> Snapshots are valid versions in a range [1.0, 1.1], or even [1.0, 1.1).
>>
>> Personally I'm +1 for updating the docs, and let the presence of
>> snapshot repo's
>> and valid snapshot artifacts there determine wheter snapshots are used
>> or not.
>
> Not only is the syntax above very cumbersome, but what about the
> possibility of 1.0.1-SNAPSHOT, etc?
Ah. Yes indeed. That'll be really cumbersome.
> Controlling this through snapshot repo presence/absence would be rather
> suboptimal, because you couldn't pull in a snapshot for one particular
> artifact without possibly getting unwanted snapshots for other
> dependency artifacts published in the same repo.
True, though the proposed change will only affect version ranges, not versions.
I think snapshots are a different aspect, outside of version ranges. Version
ranges are meant to specify a range of versions. Snapshots fit perfectly
in a version range.
So you want to prevent accidental use of snapshots when released versions
are available in the given range.
Having a mechanism in place to explicitly state what dependencies can be resolved
to snapshot versions, and what dependencies cannot is certainly useful
So what we're dealing here is a way to do that. This has nothing to do with version
ranges but with being able to say that you don't want snapshots for a certain
artifact. Specifying a normal version (without SNAPSHOT) is not going to be resolved to a snapshot,
unless there's another declaration that does mention it, and with version ranges that could happen.
The current resolution mechanism uses the first match, so it's pretty random
(the order of the searched repositories is important here).
If someone specifies a version range, he doesn't care about the version except that it must
be in that range because he knows those versions work. SNAPSHOTs that fall into that range
are compatible, so why can't they be used?
What about other dependencies that _are_ declared as a snapshot and bring in a SNAPSHOT version
also declared somewhere else with a SNAPSHOT-excluding range? Should the build fail then?
Most importantly, making this change prevents snapshots from being used in version ranges.
Sure, you can explicitly mention them in the range, but you'd have the same problem
as the other way around: specifying 1.0.1-SNAPSHOT, 1.0.2-SNAPSHOT etc..
It seems we want more fine grained control on this matter.
We could change the order of resolution to first check for non-snapshots,
then for snapshots, so a non-snapshot will be used when it's possible. That would solve the problem,
except for people who want to use snapshots.
Another solution would be to somehow mark wheter a dependency or version range should
include or exclude snapshots, or add information to repositories specifying the groupid/artifactids
they provide or must not provide. That way you can declare the same repo twice, once with snapshots enabled
and once without, listing the dependencies.
Not sure if this is worth the trouble though..
Anyway, we could just 'assume' that when people specify version ranges they don't want
snapshots and apply this change. I'm just worried about the side effects, since A (using snapshots
in ranges) is possible now and B (excluding snapshots in ranges) is cumbersome,
but when we apply this, B is possible but A is even more cumbersome.
Ow, just thought of something - have 'processing instructions' or similar in the version ranges,
like [1.0,2.0){snapshots=off} (or just use xml attributes ofcourse ;))
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by dhoffer <DH...@xrite.com>.
You can't fix this by disallowing repos because snapshots may be in the local
repo.
Max O Bowsher wrote:
>
> Kenney Westerhof wrote:
>>
>>
>> Patrick Schneider wrote:
>>> For now, I'm a fan of disallowing snapshots when they are not
>>> explicitly in
>>> the boundary, as per the patch.
>>>
>>> In my mind, the problem with a profile flag is that it's an
>>> all-or-nothing
>>> proposition. Any released artifacts with version ranges will also
>>> start to
>>> pull in snapshots. There wouldn't be enough control, IMO.
>>>
>>
>> You can always exclude snapshots explicitly:
>>
>> [1.0,1.1-SNAPSHOT),(1.1-SNAPSHOT,1.1]
>>
>> Snapshots are valid versions in a range [1.0, 1.1], or even [1.0, 1.1).
>>
>> Personally I'm +1 for updating the docs, and let the presence of
>> snapshot repo's
>> and valid snapshot artifacts there determine wheter snapshots are used
>> or not.
>
> Not only is the syntax above very cumbersome, but what about the
> possibility of 1.0.1-SNAPSHOT, etc?
>
> Controlling this through snapshot repo presence/absence would be rather
> suboptimal, because you couldn't pull in a snapshot for one particular
> artifact without possibly getting unwanted snapshots for other
> dependency artifacts published in the same repo.
>
> Max.
>
>
>
>
>
>
--
View this message in context: http://www.nabble.com/Version-ranges-and-snapshots-tf4035629s177.html#a13164250
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Max Bowsher <ma...@ukf.net>.
Kenney Westerhof wrote:
>
>
> Patrick Schneider wrote:
>> For now, I'm a fan of disallowing snapshots when they are not
>> explicitly in
>> the boundary, as per the patch.
>>
>> In my mind, the problem with a profile flag is that it's an
>> all-or-nothing
>> proposition. Any released artifacts with version ranges will also
>> start to
>> pull in snapshots. There wouldn't be enough control, IMO.
>>
>
> You can always exclude snapshots explicitly:
>
> [1.0,1.1-SNAPSHOT),(1.1-SNAPSHOT,1.1]
>
> Snapshots are valid versions in a range [1.0, 1.1], or even [1.0, 1.1).
>
> Personally I'm +1 for updating the docs, and let the presence of
> snapshot repo's
> and valid snapshot artifacts there determine wheter snapshots are used
> or not.
Not only is the syntax above very cumbersome, but what about the
possibility of 1.0.1-SNAPSHOT, etc?
Controlling this through snapshot repo presence/absence would be rather
suboptimal, because you couldn't pull in a snapshot for one particular
artifact without possibly getting unwanted snapshots for other
dependency artifacts published in the same repo.
Max.
Re: Version ranges and snapshots
Posted by Kenney Westerhof <ke...@apache.org>.
Patrick Schneider wrote:
> For now, I'm a fan of disallowing snapshots when they are not explicitly in
> the boundary, as per the patch.
>
> In my mind, the problem with a profile flag is that it's an all-or-nothing
> proposition. Any released artifacts with version ranges will also start to
> pull in snapshots. There wouldn't be enough control, IMO.
>
You can always exclude snapshots explicitly:
[1.0,1.1-SNAPSHOT),(1.1-SNAPSHOT,1.1]
Snapshots are valid versions in a range [1.0, 1.1], or even [1.0, 1.1).
Personally I'm +1 for updating the docs, and let the presence of snapshot repo's
and valid snapshot artifacts there determine wheter snapshots are used or not.
-- Kenney
>
> Patrick
>
> On 7/6/07, Mark Hobson <ma...@gmail.com> wrote:
>>
>> Hi,
>>
>> Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
>> contrary to the 2.0 design docs:
>>
>> http://jira.codehaus.org/browse/MNG-3092
>>
>> Brett, Kenney and myself had a brief discussion on IRC about this:
>> Kenney says that the behaviour is theoretically correct (which it is),
>> although I feel it goes against the practical usage described in the
>> docs. The two main choices I can see are:
>>
>> 1) We stick to the design docs and disallow snapshots in ranges when
>> they aren't an explicit boundary, as per the MNG-3092 patch.
>>
>> 2) We reconsider the design docs and leave range resolution behaving
>> as it is, then use profiles to enable or disable snapshot repositories
>> at build time.
>>
>> Any thoughts?
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Version ranges and snapshots
Posted by Patrick Schneider <ps...@gmail.com>.
For now, I'm a fan of disallowing snapshots when they are not explicitly in
the boundary, as per the patch.
In my mind, the problem with a profile flag is that it's an all-or-nothing
proposition. Any released artifacts with version ranges will also start to
pull in snapshots. There wouldn't be enough control, IMO.
Patrick
On 7/6/07, Mark Hobson <ma...@gmail.com> wrote:
>
> Hi,
>
> Whilst attempting to fix MNG-2994, I discovered MNG-3092 that was
> contrary to the 2.0 design docs:
>
> http://jira.codehaus.org/browse/MNG-3092
>
> Brett, Kenney and myself had a brief discussion on IRC about this:
> Kenney says that the behaviour is theoretically correct (which it is),
> although I feel it goes against the practical usage described in the
> docs. The two main choices I can see are:
>
> 1) We stick to the design docs and disallow snapshots in ranges when
> they aren't an explicit boundary, as per the MNG-3092 patch.
>
> 2) We reconsider the design docs and leave range resolution behaving
> as it is, then use profiles to enable or disable snapshot repositories
> at build time.
>
> Any thoughts?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>