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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
