You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brian Fox <br...@infinity.nu> on 2010/09/03 03:27:38 UTC
snapshot range changes in m3
Forking this discussion:
On Thu, Sep 2, 2010 at 9:12 PM, Mark Derricutt <ma...@talios.com> wrote:
> Personally I'd still like to see some resolution to the problems introduced
> by the version range resolution change ( no more -SNAPSHOT resolution except
> for on the bounds ).
>
> On one hand I applaud the change from a release standpoint, but it currently
> causes issues for our integration build processes.
>
> Two options come to mind:
>
> 1) Explicit GAV patterns for -SNAPSHOT resolution get defined somewhere
> 2) If a GAV is a particpant in a reactor build, it's -SNAPSHOT should be
> considered kosher for resolution
>
> Option 1 would probably require some form of POM change as I don't think the
> resolution part of a configurable plugin, so most likely can't be done.
>
Not possible for 3.0
> Option 2 should be fine, as when releasing an individual artifact, nothing
> external would be in the reactor, unless it was part of the build chain, so
> no extraneous -SNAPSHOTs would be considered. This should give a fairly
> good compromise between "fixing ranges for release" and "not breaking
> existing builds".
>
Seems logical to me, not sure how much work that is to fix, but
patches would be a good way to ensure this gets in. Certainly I could
see this being a problem that's worth trying to address prior to M3.0
if it's not risky.
> Each time I've brought the subject up I don't seem to see any traction or
> replies/discussion come along, is there room to address this somehow?
>
> --
> Pull me down under...
>
> On Fri, Sep 3, 2010 at 11:34 AM, Brian Fox <br...@infinity.nu> wrote:
>
>> Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty
>> safely call it feature complete. I'd like to propose a few goals to
>> get some things done. We have ApacheCon coming up the first week of
>> November, and it would be great to set that as a target to get Maven
>> 3.0 out the door.
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Mark Derricutt <ma...@talios.com>.
Both options would be nice, but I think I'm leaning more in against
including sub groups in the default set.
A different group is after all, a different group ( and probably a different
group for a reason ).
Mark
--
Pull me down under...
On Tue, Sep 14, 2010 at 10:18 PM, Benjamin Bentmann <
benjamin.bentmann@udo.edu> wrote:
> A detail that could be further discussed/reviewed here is the
> convention/assumption what is actually a "related project". If the current
> project has the groupId X, should the default -sv value only consist of the
> same groupId or also include sub groups, i.e. should Maven assume
>
> --snapshot-versions X or --snapshot-versions X,X.*
>
Re: snapshot range changes in m3
Posted by Benjamin Bentmann <be...@udo.edu>.
Benjamin Bentmann wrote:
> For the common case where one wants to consume snapshots of related
> projects, [...] I suggest to have Maven derive a default value for
> the -sv option by considering the groupIds of all snapshot projects in
> the reactor as inclusions.
A detail that could be further discussed/reviewed here is the
convention/assumption what is actually a "related project". If the
current project has the groupId X, should the default -sv value only
consist of the same groupId or also include sub groups, i.e. should
Maven assume
--snapshot-versions X or --snapshot-versions X,X.*
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Mark Derricutt <ma...@talios.com>.
Having read this a few times I think it sounds solid. I like the default
inclusion of snapshot groups in the build as a default, this will help
existing users move along without really seeing any changes in their
behavior.
Would it be good to also log a warning note to the console to report the
snapshots being pulled in?
+1
Mark
--
Pull me down under...
On Tue, Sep 14, 2010 at 3:13 AM, Benjamin Bentmann <
benjamin.bentmann@udo.edu> wrote:
> For the common case where one wants to consume snapshots of related
> projects, there should be a way to avoid the addition of -sv to the CLI. To
> address this case, I suggest to have Maven derive a default value for the
> -sv option by considering the groupIds of all snapshot projects in the
> reactor as inclusions. This is somewhat a combination of Mark's option 2 and
> my other thought which should make Maven usually do the right thing for
> builds, both during every day development and during a release (where no
> snapshot projects are in the reactor and hence the default -sv value would
> be emtpy and thereby disables any snapshots for ranges).
>
Re: snapshot range changes in m3
Posted by Benjamin Bentmann <be...@udo.edu>.
Hervé BOUTEMY wrote:
> What would be the use case not covered by previous common case?
Well, I assumed it would be the common case that project gid:aid would
want to consume snapshots of other projects from the gid domain. But
that doesn't have to be the case, just because project A shares the same
groupId with project B doesn't necessarily mean project A want to use
B's snapshots.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mercredi 15 septembre 2010, Benjamin Bentmann a écrit :
> Hervé BOUTEMY wrote:
> > Expected SNAPSHOT dependencies should be in the pom IMHO, since each bits
> > of build info should be there so that "mvn compile" is sufficient.
>
> I agree that we need to aim for a short command line but I'm not
> convinced the POM can help us here. To me, it looks like a valid use
> case to build the same project/POM once with and once without snapshots.
> For example, think about a project where the development policy is to
> pick up only released versions of dependencies, e.g. in order to avoid
> destabilizing downstream projects while the dependency snapshots for the
> next versions are in flux. Still, they might want to have some CI build
> that integrates the snapshots to allow for early feedback regarding the
> qualiity of the next release. CI builds from the same sources, this is
> why I was thinking about a CLI option.
yes, there can be multiple builds, then CLI option is necessary (think at a
"Gump-like" CI too, where everything is changed to LATEST)
>
> But something I didn't think about properly are big products that
> consist of artifacts from various different groupIds. When such a
> product build is expected to consume snapshots from all its
> dependencies, the proposed default value for -sv isn't appropriate and
> developers would be required to explicitly list the coordinates. Apart
> from being cumbersome, this makes it harder to synchronize a team of
> developers to have them get the same build results.
+1: that's my point with having something in the pom, which defines the
"normal" build of the team
>
> I have no solution right now and need to think about this some more.
> Maybe the settings.xml can help (my previous concern about using this
> during a release can be easily solved by the rule that non-snapshot
> projects never ever consume snapshot dependencies for ranges).
I have no solution either :(
Hervé
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mercredi 15 septembre 2010, Benjamin Bentmann a écrit :
> Benjamin Bentmann wrote:
> > I have no solution right now and need to think about this some more.
>
> The approach that I could think of to sufficiently address this issue
> requires quite some rework of the settings.xml or better a different
> file in order to not break side-by-side use of Maven 2.x and 3.x. Given
> that we want to release 3.0 soon, I will probably just rollback the
> changes for MNG-3092 and restore 2.x behavior, i.e. always include
> snapshots in ranges, and postpone a more robust solution to 3.1.
+1
thank you
Hervé
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Mark Derricutt <ma...@talios.com>.
+1
Thinking about it - I like the idea of a (for lack of a better name)
~/.m2/resolutions.xml that provides control over the resolver.
First thoughts that come to mind:
- missing or empty file - existing 2.x behaviour, -SNAPSHOTS resolved
across the board.
- profile based (optional?)
Maybe something like:
<resolutions>
<resolution>
<groupId>com.smxemail.*</groupId>
<artifactId>.*</artifactId>
<snapshots>
<enabled>true</enabled>
</snapshots>
</resolution>
<profiles>
<profile>
<id>release</id>
<resolutions>
<resolution>
<groupId>.*</groupId>
<artifactId>.*</artifactId>
<snapshots>
<enabled>false</enabled>
</snapshots>
</resolution>
</resolutions>
</profile>
</profiles>
</resolutions>
As much as I hate mavens use of elements only, the above conforms to the
current "standard" - a somewhat mix between a dependency and a repository
definition. I like the notion of enabling resolution based on profile,
which is already an accepted way of dynamically altering pom resolution.
What do you guys think of something like this? If something like this was
adopted, would it be doable for 3.0? ( having no clue as to how many layers
of maven these things affect ).
mark
--
Pull me down under...
On Thu, Sep 16, 2010 at 1:10 AM, Jason van Zyl <ja...@sonatype.com> wrote:
> > The approach that I could think of to sufficiently address this issue
> requires quite some rework of the settings.xml or better a different file in
> order to not break side-by-side use of Maven 2.x and 3.x. Given that we want
> to release 3.0 soon, I will probably just rollback the changes for MNG-3092
> and restore 2.x behavior, i.e. always include snapshots in ranges, and
> postpone a more robust solution to 3.1.
> >
>
> +1
>
> This is just more consistent with 3.0 being backward compatible, and making
> the whole scenario of SNAPSHOTs for CI and integration and blocking them
> from releases will take some more thinking. Only one person has complained
> but I posit 95% of Maven users aren't going to try Maven 3.x until 3.0 is
> released.
>
Re: snapshot range changes in m3
Posted by Jason van Zyl <ja...@sonatype.com>.
On Sep 15, 2010, at 8:55 AM, Benjamin Bentmann wrote:
> Benjamin Bentmann wrote:
>
>> I have no solution right now and need to think about this some more.
>
> The approach that I could think of to sufficiently address this issue requires quite some rework of the settings.xml or better a different file in order to not break side-by-side use of Maven 2.x and 3.x. Given that we want to release 3.0 soon, I will probably just rollback the changes for MNG-3092 and restore 2.x behavior, i.e. always include snapshots in ranges, and postpone a more robust solution to 3.1.
>
+1
This is just more consistent with 3.0 being backward compatible, and making the whole scenario of SNAPSHOTs for CI and integration and blocking them from releases will take some more thinking. Only one person has complained but I posit 95% of Maven users aren't going to try Maven 3.x until 3.0 is released.
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
To do two things at once is to do neither.
-—Publilius Syrus, Roman slave, first century B.C.
Re: snapshot range changes in m3
Posted by Benjamin Bentmann <be...@udo.edu>.
Benjamin Bentmann wrote:
> I have no solution right now and need to think about this some more.
The approach that I could think of to sufficiently address this issue
requires quite some rework of the settings.xml or better a different
file in order to not break side-by-side use of Maven 2.x and 3.x. Given
that we want to release 3.0 soon, I will probably just rollback the
changes for MNG-3092 and restore 2.x behavior, i.e. always include
snapshots in ranges, and postpone a more robust solution to 3.1.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Benjamin Bentmann <be...@udo.edu>.
Hervé BOUTEMY wrote:
> Expected SNAPSHOT dependencies should be in the pom IMHO, since each bits of
> build info should be there so that "mvn compile" is sufficient.
I agree that we need to aim for a short command line but I'm not
convinced the POM can help us here. To me, it looks like a valid use
case to build the same project/POM once with and once without snapshots.
For example, think about a project where the development policy is to
pick up only released versions of dependencies, e.g. in order to avoid
destabilizing downstream projects while the dependency snapshots for the
next versions are in flux. Still, they might want to have some CI build
that integrates the snapshots to allow for early feedback regarding the
qualiity of the next release. CI builds from the same sources, this is
why I was thinking about a CLI option.
But something I didn't think about properly are big products that
consist of artifacts from various different groupIds. When such a
product build is expected to consume snapshots from all its
dependencies, the proposed default value for -sv isn't appropriate and
developers would be required to explicitly list the coordinates. Apart
from being cumbersome, this makes it harder to synchronize a team of
developers to have them get the same build results.
I have no solution right now and need to think about this some more.
Maybe the settings.xml can help (my previous concern about using this
during a release can be easily solved by the rule that non-snapshot
projects never ever consume snapshot dependencies for ranges).
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 14 septembre 2010, Benjamin Bentmann a écrit :
> Stephen Connolly wrote:
> >> perhaps a special property in the pom.xml too, to avoid CLI-only and
> >> improve reproducibility?
> >
> > would the release plugin therefore have to remote the property during a
> > release and then put it back in again.... also properties are not known
> > until after the model is constructed at which point it's too late
>
> I agree with Stephen, having a special property that other tooling like
> the Release Plugin needs to be aware of sounds like superfluous
> complexity. And whether it's a POM property or later a dedicated POM
> element, the process of model building already involves artifact
> resolution (parents, imports/mixins, extensions) so I really think the
> snapshot resolution behavior should be set up front and not change
> somewhere down the road.
>
> Also, what exactly is the issue with "CLI-only"? I was once thinking
> about an addition to the settings.xml but that doesn't play nicely with
> the release process where you want Maven to never include snapshots.
the idea is that the expected compile command during the development/SNAPSHOT
phase would not be "mvn compile" but "mvn -sv gid,... compile", and if there
is an API change in SNAPSHOT dependencies, "mvn compile" would even fail.
Expected SNAPSHOT dependencies should be in the pom IMHO, since each bits of
build info should be there so that "mvn compile" is sufficient.
Then release plugin would not be in charge of *removing* the property: the
release plugin should only fail if the pom says it needs SNAPSHOT
dependencies, and the developper has to change it to remove these SNAPSHOTs.
Note that I don't know precisely how release plugin detects SNAPSHOT
dependencies: does it do its own pom.xml analysis or use core API to resolve
depencies then checks that no SNAPSHOT has been resolved?
Of course, the idea of a property is just to avoid changing the pom format
until we have a viable solution: adding an element is the real need, property
only a workaround.
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Benjamin Bentmann <be...@udo.edu>.
Stephen Connolly wrote:
>> perhaps a special property in the pom.xml too, to avoid CLI-only and
>> improve reproducibility?
>
> would the release plugin therefore have to remote the property during a
> release and then put it back in again.... also properties are not known
> until after the model is constructed at which point it's too late
I agree with Stephen, having a special property that other tooling like
the Release Plugin needs to be aware of sounds like superfluous
complexity. And whether it's a POM property or later a dedicated POM
element, the process of model building already involves artifact
resolution (parents, imports/mixins, extensions) so I really think the
snapshot resolution behavior should be set up front and not change
somewhere down the road.
Also, what exactly is the issue with "CLI-only"? I was once thinking
about an addition to the settings.xml but that doesn't play nicely with
the release process where you want Maven to never include snapshots.
> I think we need something along the lines of benjamin's proposal, but I'd
> like to see some concrete examples of how it would work, on e.g. a wiki page
Apart from diving into implementation details, my proposal is pretty
detailed. So if something is unclear, please raise concrete questions.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Stephen Connolly <st...@gmail.com>.
On 14 September 2010 06:22, Hervé BOUTEMY <he...@free.fr> wrote:
> > So far I doubt that we can find any magic/heuristic that works for all
> > use cases. Hence I suggest that we go with some explicit configuration.
> > In detail, I propose a CLI option like
> >
> > mvn <goals> --snapshot-versions gid,-gid:aid,*:aid
> >
> > This is meant to give a comma-separated list of glob-like
> > inclusion/exclusion patterns (exclusions marked by prefixing with '-' or
> > '!' like profiles) to denote the groupId:artifactId tuples of
> > projects/artifacts whose snapshots are acceptable for ranges during the
> > build. These patterns would be applied on the set of available versions
> > before the range filters them, i.e. even a range giving snapshots
> > explicitly like "[2.0-SNAPSHOT,)" would not select 2.0-SNAPSHOT unless
> > enabled on CLI for the artifact in question.
> this seems a reasonable approach IMHO
> clearly, it fixes my main concern: version ranges are back to mathematical
> notion
> I don't really understand the use cases where problems happen (even it has
> already been told), then my opinion on this point is not really a good
> indicator
>
> >
> > This new option, -sv in short form, would apply to the entire reactor.
> > If somebody sees a good use case that requires to treat some projects
> > within a reactor differently or to treat project dependency resolution
> > and plugin resolution differently, please speak up.
> >
> > For the common case where one wants to consume snapshots of related
> > projects, there should be a way to avoid the addition of -sv to the CLI.
> > To address this case, I suggest to have Maven derive a default value for
> > the -sv option by considering the groupIds of all snapshot projects in
> > the reactor as inclusions. This is somewhat a combination of Mark's
> > option 2 and my other thought which should make Maven usually do the
> > right thing for builds, both during every day development and during a
> > release (where no snapshot projects are in the reactor and hence the
> > default -sv value would be emtpy and thereby disables any snapshots for
> > ranges).
> perhaps a special property in the pom.xml too, to avoid CLI-only and
> improve
> reproducibility? What would be the use case not covered by previous common
> case?
>
would the release plugin therefore have to remote the property during a
release and then put it back in again.... also properties are not known
until after the model is constructed at which point it's too late
I think we need something along the lines of benjamin's proposal, but I'd
like to see some concrete examples of how it would work, on e.g. a wiki page
-Stephen
> Regards,
>
> Hervé
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: snapshot range changes in m3
Posted by Hervé BOUTEMY <he...@free.fr>.
> So far I doubt that we can find any magic/heuristic that works for all
> use cases. Hence I suggest that we go with some explicit configuration.
> In detail, I propose a CLI option like
>
> mvn <goals> --snapshot-versions gid,-gid:aid,*:aid
>
> This is meant to give a comma-separated list of glob-like
> inclusion/exclusion patterns (exclusions marked by prefixing with '-' or
> '!' like profiles) to denote the groupId:artifactId tuples of
> projects/artifacts whose snapshots are acceptable for ranges during the
> build. These patterns would be applied on the set of available versions
> before the range filters them, i.e. even a range giving snapshots
> explicitly like "[2.0-SNAPSHOT,)" would not select 2.0-SNAPSHOT unless
> enabled on CLI for the artifact in question.
this seems a reasonable approach IMHO
clearly, it fixes my main concern: version ranges are back to mathematical
notion
I don't really understand the use cases where problems happen (even it has
already been told), then my opinion on this point is not really a good
indicator
>
> This new option, -sv in short form, would apply to the entire reactor.
> If somebody sees a good use case that requires to treat some projects
> within a reactor differently or to treat project dependency resolution
> and plugin resolution differently, please speak up.
>
> For the common case where one wants to consume snapshots of related
> projects, there should be a way to avoid the addition of -sv to the CLI.
> To address this case, I suggest to have Maven derive a default value for
> the -sv option by considering the groupIds of all snapshot projects in
> the reactor as inclusions. This is somewhat a combination of Mark's
> option 2 and my other thought which should make Maven usually do the
> right thing for builds, both during every day development and during a
> release (where no snapshot projects are in the reactor and hence the
> default -sv value would be emtpy and thereby disables any snapshots for
> ranges).
perhaps a special property in the pom.xml too, to avoid CLI-only and improve
reproducibility? What would be the use case not covered by previous common
case?
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Benjamin Bentmann <be...@udo.edu>.
Brian Fox wrote:
>> Two options come to mind:
>>
>> 1) Explicit GAV patterns for -SNAPSHOT resolution get defined somewhere
>> 2) If a GAV is a particpant in a reactor build, it's -SNAPSHOT should be
>> considered kosher for resolution
>>
>> Option 1 would probably require some form of POM change as I don't think the
>> resolution part of a configurable plugin, so most likely can't be done.
>>
>> Option 2 should be fine, as when releasing an individual artifact, nothing
>> external would be in the reactor, unless it was part of the build chain, so
>> no extraneous -SNAPSHOTs would be considered. This should give a fairly
>> good compromise between "fixing ranges for release" and "not breaking
>> existing builds".
>>
>
> Seems logical to me [...] Certainly I could
> see this being a problem that's worth trying to address prior to M3.0
> if it's not risky.
Agreed, that issue is a trouble-maker for builds and I wanted to look
into that next now that the other regressions I know about are fixed.
But I think option 2 isn't workable either. For one, I dislike the idea
that a reactor build and an isolated module build behave noticeable
different. Consider this command session from an aggregator project's
basedir:
$ mvn install
$ cd sub-module
$ mvn install
As a user, I would have a very hard time to understand that the initial
"mvn install" picks snapshots while the later "mvn install" on a single
module doesn't, despite just having installed snapshots of all the other
modules. And I think this scenario reflects a common build pattern,
where a developer starts his day with updating the entire code base from
SCM, does a full build of the updated code base and then continues the
rest of his work on only a few modules.
But more importantly, option 2 would not guarantee that a release build
doesn't use snapshots (cf. MRELEASE-216). While during a release the
reactor itself doesn't produce snapshots, a version range could still
select a snapshot from the repos.
Another option that came to my mind was using the current project's
version as the controlling factor. If the project itself is a SNAPSHOT,
allow it to select snapshots for its direct dependencies, otherwise not.
But this is also troublesome, whether one wants to consume snapshots (in
particular of third-parties) should be independent from the current project.
So far I doubt that we can find any magic/heuristic that works for all
use cases. Hence I suggest that we go with some explicit configuration.
In detail, I propose a CLI option like
mvn <goals> --snapshot-versions gid,-gid:aid,*:aid
This is meant to give a comma-separated list of glob-like
inclusion/exclusion patterns (exclusions marked by prefixing with '-' or
'!' like profiles) to denote the groupId:artifactId tuples of
projects/artifacts whose snapshots are acceptable for ranges during the
build. These patterns would be applied on the set of available versions
before the range filters them, i.e. even a range giving snapshots
explicitly like "[2.0-SNAPSHOT,)" would not select 2.0-SNAPSHOT unless
enabled on CLI for the artifact in question.
This new option, -sv in short form, would apply to the entire reactor.
If somebody sees a good use case that requires to treat some projects
within a reactor differently or to treat project dependency resolution
and plugin resolution differently, please speak up.
For the common case where one wants to consume snapshots of related
projects, there should be a way to avoid the addition of -sv to the CLI.
To address this case, I suggest to have Maven derive a default value for
the -sv option by considering the groupIds of all snapshot projects in
the reactor as inclusions. This is somewhat a combination of Mark's
option 2 and my other thought which should make Maven usually do the
right thing for builds, both during every day development and during a
release (where no snapshot projects are in the reactor and hence the
default -sv value would be emtpy and thereby disables any snapshots for
ranges).
WDYT?
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Mark Derricutt <ma...@talios.com>.
I'd had a similar thought initially, but I've not really looked at the
internals of maven yet to know if there is such a distinct thing, or a
pluggable resolver ( I did see that the resolution was on the VersionRange
class so I suspect maybe there isn't ).
Mark
--
Pull me down under...
On Fri, Sep 3, 2010 at 5:40 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> Here are my thought for now: the fix should not have been done in
> VersionRange
> but in a version conflict resolution phase, since a range is a mathematical
> notion we can't alter.
>
Re: snapshot range changes in m3
Posted by Hervé BOUTEMY <he...@free.fr>.
I'm concerned by this "fix" too.
Here are my thought for now: the fix should not have been done in VersionRange
but in a version conflict resolution phase, since a range is a mathematical
notion we can't alter.
but I didn't have time yet to transform these thoughts in code...
Regards,
Hervé
Le vendredi 03 septembre 2010, Brian Fox a écrit :
> Forking this discussion:
>
> On Thu, Sep 2, 2010 at 9:12 PM, Mark Derricutt <ma...@talios.com> wrote:
> > Personally I'd still like to see some resolution to the problems
> > introduced by the version range resolution change ( no more -SNAPSHOT
> > resolution except for on the bounds ).
> >
> > On one hand I applaud the change from a release standpoint, but it
> > currently causes issues for our integration build processes.
> >
> > Two options come to mind:
> >
> > 1) Explicit GAV patterns for -SNAPSHOT resolution get defined somewhere
> > 2) If a GAV is a particpant in a reactor build, it's -SNAPSHOT should be
> > considered kosher for resolution
> >
> > Option 1 would probably require some form of POM change as I don't think
> > the resolution part of a configurable plugin, so most likely can't be
> > done.
>
> Not possible for 3.0
>
> > Option 2 should be fine, as when releasing an individual artifact,
> > nothing external would be in the reactor, unless it was part of the
> > build chain, so no extraneous -SNAPSHOTs would be considered. This
> > should give a fairly good compromise between "fixing ranges for release"
> > and "not breaking existing builds".
>
> Seems logical to me, not sure how much work that is to fix, but
> patches would be a good way to ensure this gets in. Certainly I could
> see this being a problem that's worth trying to address prior to M3.0
> if it's not risky.
>
> > Each time I've brought the subject up I don't seem to see any traction or
> > replies/discussion come along, is there room to address this somehow?
> >
> > --
> > Pull me down under...
> >
> > On Fri, Sep 3, 2010 at 11:34 AM, Brian Fox <br...@infinity.nu> wrote:
> >> Now that Maven 3 beta 3 is out with Guice and Aether, we can pretty
> >> safely call it feature complete. I'd like to propose a few goals to
> >> get some things done. We have ApacheCon coming up the first week of
> >> November, and it would be great to set that as a target to get Maven
> >> 3.0 out the door.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Hervé BOUTEMY <he...@free.fr>.
I created a Wiki page to be able to share pointers:
http://docs.codehaus.org/display/MAVENUSER/SNAPSHOT+Resolution
regards,
Hervé
Le vendredi 03 septembre 2010, Mark Derricutt a écrit :
> Any pointers to where in the code base I should start looking/hacking if I
> wanted to try and write such a patch?
>
> As I'm the main one arguing for this improvement, I'm willing to at least
> try and solve it :)
>
> > Seems logical to me, not sure how much work that is to fix, but
> > patches would be a good way to ensure this gets in. Certainly I could
> > see this being a problem that's worth trying to address prior to M3.0
> > if it's not risky.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: snapshot range changes in m3
Posted by Mark Derricutt <ma...@talios.com>.
Any pointers to where in the code base I should start looking/hacking if I
wanted to try and write such a patch?
As I'm the main one arguing for this improvement, I'm willing to at least
try and solve it :)
--
Pull me down under...
On Fri, Sep 3, 2010 at 1:27 PM, Brian Fox <br...@infinity.nu> wrote:
> Seems logical to me, not sure how much work that is to fix, but
> patches would be a good way to ensure this gets in. Certainly I could
> see this being a problem that's worth trying to address prior to M3.0
> if it's not risky.
>