Re: Version ranges and snapshots
ctly
> "switches" back to numeric order)
> +* "1.foo" < "1-foo" < "1-1" < "1.1"
> +* "1.0" = "1-0" = "1" = "1-" = "1-ga" = "1-final" (removing of
> trailing "null" values)
> +* "1.sp.1" < "1-.1" (empty token replaced by the number 0, not by
> the null value ""!)
> +* Complex example
> + * "1.0" < "1.sp" (trailing null value removed, padded to identifier
> null, which is less than sp)
> + * "1.sp.1" < "1.0.1" ( .sp < .0 because ".qualifier" < ".number")
> +
> + Note1: Contrary to what was stated in some design documents, snapshots
> are not treated differently than releases or any other qualifier.
> + Note2: The Versionning Order quickly becomes complex unless you stick
> with "sane" versions.
> +
> +
> +
> +
> *** {Exclusions}
>
>Exclusions explicitly tell Maven that you don't want to include the
>
>
>
> Jon
>
> On Sun, Mar 22, 2015 at 5:18 PM, Hervé BOUTEMY
> wrote:
>
>> Hi Jon,
>>
>> Thank you for your great proposal.
>> I fixed some formatting issues and integrated it: I think the intro is now
>> better
>>
>> Regards,
>>
>> Hervé
>>
>> Le vendredi 20 mars 2015 19:28:24 Jon Harper a écrit :
>> > Hi Hervé,
>> > what do you think of the following first patch ? I haven't generated the
>> > corresponding html yet, just throwing some ideas..
>> >
>> > Regards,
>> > Jon
>> >
>> > Index: pom.apt
>> > ===
>> > --- pom.apt (révision 1668105)
>> > +++ pom.apt (copie de travail)
>> > @@ -303,8 +303,14 @@
>> > +-+
>> >
>> >* <>, <>, <>:\
>> > - These elements are self-explanatory, and you will see them often.
>> This
>> > trinity represents the coordinate
>> > - of a specific project in time, demarcating it as a dependency of this
>> > project. You may be thinking:
>> > + You will see these elements often. This trinity is used to compute
>> the
>> > maven coordinate
>> > + of a specific project in time, demarcating it as a dependency of this
>> > project. The purpose
>> > + of this computation is to select a version that matches all the
>> > dependency declarations
>> > + (due to transitive dependencies, there can be multiple dependency
>> > declarations for the
>> > + same artifact). The values should be:
>> > +* <>, <>: directly the corresponding
>> coordinates
>> > of the dependency.
>> > +* <>: a <> that will be used to compute the
>> > dependency's version.
>> > + Since the dependency is described by maven coordinates, you may be
>> > thinking:
>> >"This means that my project can only depend upon Maven artifacts!"
>> The
>> > answer is, "Of course, but that's a
>> >good thing." This forces you to depend solely on dependencies that
>> Maven
>> > can manage. There are times,
>> >unfortunately, when a project cannot be downloaded from the central
>> > Maven repository. For example, a project
>> > @@ -388,6 +394,21 @@
>> >In the shortest terms, <<>> lets other projects know that,
>> > when you use this project, you
>> >do not require this dependency in order to work correctly.
>> >
>> > +*** {Version Ranges}
>> > +
>> > + Version Ranges used for the <> element have the following
>> > syntax (TODO only examples??):
>> > + * 1.0: "Soft" requirement on 1.0 (just a recommendation - helps
>> select
>> > the correct version if it matches all ranges)
>> > + * (,1.0]: x <= 1.0
>> > + * [1.0]: Hard requirement on 1.0
>> > + * [1.2,1.3]: 1.2 <= x <= 1.3
>> > + * [1.0,2.0): 1.0 <= x < 2.0
>> > + * [1.5,): x >= 1.5
>> > + * (,1.0],[1.2,): x <= 1.0 or x >= 1.2. Multiple sets are
>> comma-separated
>> > + * (,1.1),(1.1,): This excludes 1.1 if it is known not to work in
>> > combination with this library
>> > +
>> > + TODO: describe the pseudo-lexicographical order used above, using
>> major
>> > version, minor version, incr
Re: Version ranges and snapshots
Le mardi 24 mars 2015 13:09:03 Tibor Digana a écrit : > Why the Maven core isn't plugable via SPI, for instance the class > ComparableVersion? this was an old dream request, but when I tried, I found it would not make sense if the config had to be done in pom.xml And having the config in setting.xml of lib/ext was too much, since this would change the comparaison algorithm for every Maven run now that we have .mvn to load extension on specific projects, making the comparison algorithm would be feasible even if I'm not convinced it is useful... > It's a class which does not need any Maven API and no extension plugin. > We may refuse spending our efforts on fixing debatable issues which would be > good for both parties Maven developers and users. Changing the current > behavior may allow reporting new JIRA issues due to breaking current > behavior. The SPI would simplify our situation, wouldn't it? now, such a SPI will require a really good documentation, since without good documentation, it's only more complex code that nobody will be able to extend > > ComparableVersion class was just an example, maybe trivial, but the idea is > obvious. for sure, .mvn gives new opportunities: we'll need to find a way to document extension points, or Maven core will become even more complex wihtout anybody being able to really take advantage of it (or only a happy few who were there at the beginning) Regards, Hervé > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Re-Version-ranges-and-snapshots-tp5825997p > 5830193.html Sent from the Maven Developers mailing list archive at > Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Version ranges and snapshots
Why the Maven core isn't plugable via SPI, for instance the class ComparableVersion? It's a class which does not need any Maven API and no extension plugin. We may refuse spending our efforts on fixing debatable issues which would be good for both parties Maven developers and users. Changing the current behavior may allow reporting new JIRA issues due to breaking current behavior. The SPI would simplify our situation, wouldn't it? ComparableVersion class was just an example, maybe trivial, but the idea is obvious. -- View this message in context: http://maven.40175.n5.nabble.com/Re-Version-ranges-and-snapshots-tp5825997p5830193.html Sent from the Maven Developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Version ranges and snapshots
sp.1" < "1.0.1" ( .sp < .0 because ".qualifier" < ".number")
+
+ Note1: Contrary to what was stated in some design documents, snapshots
are not treated differently than releases or any other qualifier.
+ Note2: The Versionning Order quickly becomes complex unless you stick
with "sane" versions.
+
+
+
+
*** {Exclusions}
Exclusions explicitly tell Maven that you don't want to include the
Jon
On Sun, Mar 22, 2015 at 5:18 PM, Hervé BOUTEMY
wrote:
> Hi Jon,
>
> Thank you for your great proposal.
> I fixed some formatting issues and integrated it: I think the intro is now
> better
>
> Regards,
>
> Hervé
>
> Le vendredi 20 mars 2015 19:28:24 Jon Harper a écrit :
> > Hi Hervé,
> > what do you think of the following first patch ? I haven't generated the
> > corresponding html yet, just throwing some ideas..
> >
> > Regards,
> > Jon
> >
> > Index: pom.apt
> > ===
> > --- pom.apt (révision 1668105)
> > +++ pom.apt (copie de travail)
> > @@ -303,8 +303,14 @@
> > +-+
> >
> >* <>, <>, <>:\
> > - These elements are self-explanatory, and you will see them often. This
> > trinity represents the coordinate
> > - of a specific project in time, demarcating it as a dependency of this
> > project. You may be thinking:
> > + You will see these elements often. This trinity is used to compute the
> > maven coordinate
> > + of a specific project in time, demarcating it as a dependency of this
> > project. The purpose
> > + of this computation is to select a version that matches all the
> > dependency declarations
> > + (due to transitive dependencies, there can be multiple dependency
> > declarations for the
> > + same artifact). The values should be:
> > +* <>, <>: directly the corresponding
> coordinates
> > of the dependency.
> > +* <>: a <> that will be used to compute the
> > dependency's version.
> > + Since the dependency is described by maven coordinates, you may be
> > thinking:
> >"This means that my project can only depend upon Maven artifacts!" The
> > answer is, "Of course, but that's a
> >good thing." This forces you to depend solely on dependencies that
> Maven
> > can manage. There are times,
> >unfortunately, when a project cannot be downloaded from the central
> > Maven repository. For example, a project
> > @@ -388,6 +394,21 @@
> >In the shortest terms, <<>> lets other projects know that,
> > when you use this project, you
> >do not require this dependency in order to work correctly.
> >
> > +*** {Version Ranges}
> > +
> > + Version Ranges used for the <> element have the following
> > syntax (TODO only examples??):
> > + * 1.0: "Soft" requirement on 1.0 (just a recommendation - helps select
> > the correct version if it matches all ranges)
> > + * (,1.0]: x <= 1.0
> > + * [1.0]: Hard requirement on 1.0
> > + * [1.2,1.3]: 1.2 <= x <= 1.3
> > + * [1.0,2.0): 1.0 <= x < 2.0
> > + * [1.5,): x >= 1.5
> > + * (,1.0],[1.2,): x <= 1.0 or x >= 1.2. Multiple sets are
> comma-separated
> > + * (,1.1),(1.1,): This excludes 1.1 if it is known not to work in
> > combination with this library
> > +
> > + TODO: describe the pseudo-lexicographical order used above, using
> major
> > version, minor version, incremental version, and qualifier.
> > + examples: 1.0.0-SNAPSHOT < 1.0.0 ...
> > +
> > *** {Exclusions}
> >
> >Exclusions explicitly tell Maven that you don't want to include the
> >
> >
> > Jon
> >
> > On Sun, Feb 15, 2015 at 10:09 PM, Hervé BOUTEMY
> >
> > wrote:
> > > Hi Jon,
> > >
> > > Le dimanche 15 février 2015 21:41:52 Jon Harper a écrit :
> > > > Hi,
> > > > since there were no answers, I'm not sure I wrote to the correct
> mailing
> > > > list for this problem.
> > >
> > > good mailing list, but can of worm :)
> > >
> > > > Can anyone direct me to someone who is interested in
> > > > working on this issue ?
> > >
> > > I can try to work on this once more: perhaps we'll manage to improve
> > > something
> > >
> > > > For info, the docs have been saying the following for 7+ years:
> > > > &q
Re: Version ranges and snapshots
Hi Jon,
Thank you for your great proposal.
I fixed some formatting issues and integrated it: I think the intro is now
better
Regards,
Hervé
Le vendredi 20 mars 2015 19:28:24 Jon Harper a écrit :
> Hi Hervé,
> what do you think of the following first patch ? I haven't generated the
> corresponding html yet, just throwing some ideas..
>
> Regards,
> Jon
>
> Index: pom.apt
> ===
> --- pom.apt (révision 1668105)
> +++ pom.apt (copie de travail)
> @@ -303,8 +303,14 @@
> +-+
>
>* <>, <>, <>:\
> - These elements are self-explanatory, and you will see them often. This
> trinity represents the coordinate
> - of a specific project in time, demarcating it as a dependency of this
> project. You may be thinking:
> + You will see these elements often. This trinity is used to compute the
> maven coordinate
> + of a specific project in time, demarcating it as a dependency of this
> project. The purpose
> + of this computation is to select a version that matches all the
> dependency declarations
> + (due to transitive dependencies, there can be multiple dependency
> declarations for the
> + same artifact). The values should be:
> +* <>, <>: directly the corresponding coordinates
> of the dependency.
> +* <>: a <> that will be used to compute the
> dependency's version.
> + Since the dependency is described by maven coordinates, you may be
> thinking:
>"This means that my project can only depend upon Maven artifacts!" The
> answer is, "Of course, but that's a
>good thing." This forces you to depend solely on dependencies that Maven
> can manage. There are times,
>unfortunately, when a project cannot be downloaded from the central
> Maven repository. For example, a project
> @@ -388,6 +394,21 @@
>In the shortest terms, <<>> lets other projects know that,
> when you use this project, you
>do not require this dependency in order to work correctly.
>
> +*** {Version Ranges}
> +
> + Version Ranges used for the <> element have the following
> syntax (TODO only examples??):
> + * 1.0: "Soft" requirement on 1.0 (just a recommendation - helps select
> the correct version if it matches all ranges)
> + * (,1.0]: x <= 1.0
> + * [1.0]: Hard requirement on 1.0
> + * [1.2,1.3]: 1.2 <= x <= 1.3
> + * [1.0,2.0): 1.0 <= x < 2.0
> + * [1.5,): x >= 1.5
> + * (,1.0],[1.2,): x <= 1.0 or x >= 1.2. Multiple sets are comma-separated
> + * (,1.1),(1.1,): This excludes 1.1 if it is known not to work in
> combination with this library
> +
> + TODO: describe the pseudo-lexicographical order used above, using major
> version, minor version, incremental version, and qualifier.
> + examples: 1.0.0-SNAPSHOT < 1.0.0 ...
> +
> *** {Exclusions}
>
>Exclusions explicitly tell Maven that you don't want to include the
>
>
> Jon
>
> On Sun, Feb 15, 2015 at 10:09 PM, Hervé BOUTEMY
>
> wrote:
> > Hi Jon,
> >
> > Le dimanche 15 février 2015 21:41:52 Jon Harper a écrit :
> > > Hi,
> > > since there were no answers, I'm not sure I wrote to the correct mailing
> > > list for this problem.
> >
> > good mailing list, but can of worm :)
> >
> > > Can anyone direct me to someone who is interested in
> > > working on this issue ?
> >
> > I can try to work on this once more: perhaps we'll manage to improve
> > something
> >
> > > For info, the docs have been saying the following for 7+ years:
> > > "groupId, artifactId, version:
> > > These elements are self-explanatory"
> > >
> > > The version element is *not* self-explanatory, especially regarding
> > > interactions between version ranges and *-SNAPSHOTs artifacts.
> >
> > you're right: version *in dependencies* is not self explanatory (version
> > in
> > Maven coordinates is self explanatory)
> > It has a lot of subtle features: preferred vs exact match, version range,
> > then
> > the question of SNAPSHOTS
> >
> > > Any thoughts on this matter would be appreciated.
> >
> > if you have little patches for the source of the page [1], I can review
> > and we
> > can work and discuss on it step by step
> >
> > Regards,
> >
> > Hervé
> >
> > [1] https://svn.apache.org/repos/asf/maven/site/trunk/content/apt/pom.apt
> >
> > > Regards,
> > > Jon
> > >
> > > On Thu, Feb
Re: Version ranges and snapshots
Hi Hervé,
what do you think of the following first patch ? I haven't generated the
corresponding html yet, just throwing some ideas..
Regards,
Jon
Index: pom.apt
===
--- pom.apt (révision 1668105)
+++ pom.apt (copie de travail)
@@ -303,8 +303,14 @@
+-+
* <>, <>, <>:\
- These elements are self-explanatory, and you will see them often. This
trinity represents the coordinate
- of a specific project in time, demarcating it as a dependency of this
project. You may be thinking:
+ You will see these elements often. This trinity is used to compute the
maven coordinate
+ of a specific project in time, demarcating it as a dependency of this
project. The purpose
+ of this computation is to select a version that matches all the
dependency declarations
+ (due to transitive dependencies, there can be multiple dependency
declarations for the
+ same artifact). The values should be:
+* <>, <>: directly the corresponding coordinates
of the dependency.
+* <>: a <> that will be used to compute the
dependency's version.
+ Since the dependency is described by maven coordinates, you may be
thinking:
"This means that my project can only depend upon Maven artifacts!" The
answer is, "Of course, but that's a
good thing." This forces you to depend solely on dependencies that Maven
can manage. There are times,
unfortunately, when a project cannot be downloaded from the central
Maven repository. For example, a project
@@ -388,6 +394,21 @@
In the shortest terms, <<>> lets other projects know that,
when you use this project, you
do not require this dependency in order to work correctly.
+*** {Version Ranges}
+
+ Version Ranges used for the <> element have the following
syntax (TODO only examples??):
+ * 1.0: "Soft" requirement on 1.0 (just a recommendation - helps select
the correct version if it matches all ranges)
+ * (,1.0]: x <= 1.0
+ * [1.0]: Hard requirement on 1.0
+ * [1.2,1.3]: 1.2 <= x <= 1.3
+ * [1.0,2.0): 1.0 <= x < 2.0
+ * [1.5,): x >= 1.5
+ * (,1.0],[1.2,): x <= 1.0 or x >= 1.2. Multiple sets are comma-separated
+ * (,1.1),(1.1,): This excludes 1.1 if it is known not to work in
combination with this library
+
+ TODO: describe the pseudo-lexicographical order used above, using major
version, minor version, incremental version, and qualifier.
+ examples: 1.0.0-SNAPSHOT < 1.0.0 ...
+
*** {Exclusions}
Exclusions explicitly tell Maven that you don't want to include the
Jon
On Sun, Feb 15, 2015 at 10:09 PM, Hervé BOUTEMY
wrote:
> Hi Jon,
>
> Le dimanche 15 février 2015 21:41:52 Jon Harper a écrit :
> > Hi,
> > since there were no answers, I'm not sure I wrote to the correct mailing
> > list for this problem.
> good mailing list, but can of worm :)
>
> > Can anyone direct me to someone who is interested in
> > working on this issue ?
> I can try to work on this once more: perhaps we'll manage to improve
> something
>
> >
> > For info, the docs have been saying the following for 7+ years:
> > "groupId, artifactId, version:
> > These elements are self-explanatory"
> >
> > The version element is *not* self-explanatory, especially regarding
> > interactions between version ranges and *-SNAPSHOTs artifacts.
> you're right: version *in dependencies* is not self explanatory (version in
> Maven coordinates is self explanatory)
> It has a lot of subtle features: preferred vs exact match, version range,
> then
> the question of SNAPSHOTS
>
> >
> > Any thoughts on this matter would be appreciated.
> if you have little patches for the source of the page [1], I can review
> and we
> can work and discuss on it step by step
>
> Regards,
>
> Hervé
>
> [1] https://svn.apache.org/repos/asf/maven/site/trunk/content/apt/pom.apt
>
> > Regards,
> > Jon
> >
> > On Thu, Feb 5, 2015 at 5:52 PM, Jon Harper
> wrote:
> > > Hi,
> > > I'm resurrecting this old thread to ask if it's possible to change
> > > http://maven.apache.org/pom.html to document the current
> implementation
> > > behavior (7+ years old).
> > >
> > > Please see my comment on MNG-3092:
> > >
> http://jira.codehaus.org/browse/MNG-3092?focusedCommentId=362616&page=com.
> > >
> atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-36261
> > > 6
> > >
> > > Jon
> > >
> > > Mark Hobson Fri, 06 Jul 2007 06:53:04 -0700
> > >
> > > > Hi,
> > > >
> > > > Whilst attempting to fix MNG-2994, I discovered MNG-3092 that w
Re: Version ranges and snapshots
Hi Jon, Le dimanche 15 février 2015 21:41:52 Jon Harper a écrit : > Hi, > since there were no answers, I'm not sure I wrote to the correct mailing > list for this problem. good mailing list, but can of worm :) > Can anyone direct me to someone who is interested in > working on this issue ? I can try to work on this once more: perhaps we'll manage to improve something > > For info, the docs have been saying the following for 7+ years: > "groupId, artifactId, version: > These elements are self-explanatory" > > The version element is *not* self-explanatory, especially regarding > interactions between version ranges and *-SNAPSHOTs artifacts. you're right: version *in dependencies* is not self explanatory (version in Maven coordinates is self explanatory) It has a lot of subtle features: preferred vs exact match, version range, then the question of SNAPSHOTS > > Any thoughts on this matter would be appreciated. if you have little patches for the source of the page [1], I can review and we can work and discuss on it step by step Regards, Hervé [1] https://svn.apache.org/repos/asf/maven/site/trunk/content/apt/pom.apt > Regards, > Jon > > On Thu, Feb 5, 2015 at 5:52 PM, Jon Harper wrote: > > Hi, > > I'm resurrecting this old thread to ask if it's possible to change > > http://maven.apache.org/pom.html to document the current implementation > > behavior (7+ years old). > > > > Please see my comment on MNG-3092: > > http://jira.codehaus.org/browse/MNG-3092?focusedCommentId=362616&page=com. > > atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-36261 > > 6 > > > > Jon > > > > Mark Hobson Fri, 06 Jul 2007 06:53:04 -0700 > > > > > 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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Version ranges and snapshots
Hi, since there were no answers, I'm not sure I wrote to the correct mailing list for this problem. Can anyone direct me to someone who is interested in working on this issue ? For info, the docs have been saying the following for 7+ years: "groupId, artifactId, version: These elements are self-explanatory" The version element is *not* self-explanatory, especially regarding interactions between version ranges and *-SNAPSHOTs artifacts. Any thoughts on this matter would be appreciated. Regards, Jon On Thu, Feb 5, 2015 at 5:52 PM, Jon Harper wrote: > Hi, > I'm resurrecting this old thread to ask if it's possible to change > http://maven.apache.org/pom.html to document the current implementation > behavior (7+ years old). > > Please see my comment on MNG-3092: > http://jira.codehaus.org/browse/MNG-3092?focusedCommentId=362616&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-362616 > > Jon > > Mark Hobson Fri, 06 Jul 2007 06:53:04 -0700 > > > 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 > >
Re: Version ranges and snapshots
Hi, I'm resurrecting this old thread to ask if it's possible to change http://maven.apache.org/pom.html to document the current implementation behavior (7+ years old). Please see my comment on MNG-3092: http://jira.codehaus.org/browse/MNG-3092?focusedCommentId=362616&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-362616 Jon Mark Hobson Fri, 06 Jul 2007 06:53:04 -0700 > 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
Re: Version ranges and snapshots
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 <[EMAIL PROTECTED]> wrote: > > On 30/01/2008, Mark Hobson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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 <[EMAIL PROTECTED]> wrote: > > On 30/01/2008, Mark Hobson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
On Thu, 31 Jan 2008 01:56:09 Mark Hobson wrote: > On 30/01/2008, Mark Hobson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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 <[EMAIL PROTECTED]> wrote: > On 30/01/2008, Mark Hobson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Version ranges and snapshots
On 30/01/2008, Mark Hobson <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
On 29/01/2008, Michael McCallum <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
On 23/01/2008, Michael McCallum <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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. 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... 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > > Michael McCallum > > Enterprise Engineer > > mailto:[EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > Michael McCallum > Enterprise Engineer > mailto:[EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Version ranges and snapshots
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
Hi Michael, On 23/01/2008, Michael McCallum <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
gt; 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:[EMAIL PROTECTED] >>> > >>> > - >>> > To unsubscribe, e-mail: [EMAIL PROTECTED] >>> > For additional commands, e-mail: [EMAIL PROTECTED] >>> > >>> > >>> > >>> >>> -- >>> 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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
t; > >> > >> > 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:[EMAIL PROTECTED] >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > >> > >> >> -- >> 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: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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:[EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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:[EMAIL PROTECTED] > > ------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
"..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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
On 10/01/2008, Michael McCallum <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Version ranges and snapshots
It will warn or fail the build. It's a gatekeeper not a negotiator ;-) -Original Message- From: dhoffer [mailto:[EMAIL PROTECTED] 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 > > > enforce-no-snapshots > > > performRelease > true > > > > > > org.apache.maven.plugins > maven-enforcer-plugin > > > enforce-no-snapshots > validate > > enforce > > > > > > No snapshots allowed in releases it breaks build > reproducibility. > > > > true > true > > > > > > > > -- > Michael McCallum > Enterprise Engineer > mailto:[EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 > > > enforce-no-snapshots > > > performRelease > true > > > > > > org.apache.maven.plugins > maven-enforcer-plugin > > > enforce-no-snapshots > validate > > enforce > > > > > > No snapshots allowed in releases it breaks build > reproducibility. > > > > true > true > > > > > > > > -- > Michael McCallum > Enterprise Engineer > mailto:[EMAIL PROTECTED] > > --------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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:[EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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 enforce-no-snapshots performRelease true org.apache.maven.plugins maven-enforcer-plugin enforce-no-snapshots validate enforce No snapshots allowed in releases it breaks build reproducibility. true true -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
> 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:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
"...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:[EMAIL PROTECTED] > > ----- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
gt; 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:[EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
ot >> repositories >> >> > at build time. >> >> > >> >> > Any thoughts? >> >> > >> >> > Mark >> >> > >> >> > >> ------------- >> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> >> > For additional commands, e-mail: [EMAIL PROTECTED] >> > >> > -- >> > Michael McCallum >> > Enterprise Engineer >> > mailto:[EMAIL PROTECTED] >> > >> > - >> > To unsubscribe, e-mail: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > Michael McCallum > Enterprise Engineer > mailto:[EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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: [EMAIL PROTECTED] > >> > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > > Michael McCallum > > Enterprise Engineer > > mailto:[EMAIL PROTECTED] > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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: [EMAIL PROTECTED] >> > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- > Michael McCallum > Enterprise Engineer > mailto:[EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
...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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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. signature.asc Description: OpenPGP digital signature
Re: Version ranges and snapshots
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Version ranges and snapshots
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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
