Version ranges with non-snapshot bounds can contain snapshot versions

Started discussion on the suggested fix:
http://www.mail-archive.com/dev@maven.apache.org/msg68512.html

I think this is same/similar to MNG-3001, you might want to compare this patch to the patch submitted in MNG-3001.

Thanks for the pointer - I've linked that issue in. I had a look at that patch and it appears to be a subset of this one, since:

• the MNG-3001 patch fails two tests in this patch: testSnapshotRangeBoundsCanContainSnapshots and testSnapshotSoftVersionCanContainSnapshot
• this patch passes all tests provided in the MNG-3001 patch

Hence I'd like to mark MNG-3001 as a duplicate of this - is that okay with you?

Yes, a good resolution is all I care about

Cool, I think the best place to discuss the solution is in the thread linked to above - feel free to comment there.

Apparently, I cannot reply to the above mentioned link. I replied via email but it is not on that link.

Since this issue has been closed you might want to watch/vote for MNG-3092 which replaces it.

Oops I didn't mean to add that last comment... What is the status of this issue? I have not been able to post to the above mentioned email thread.

AFAIK this issue is still up for debate. You can reply to the thread by subscribing to the maven-dev mailing list, or alternatively register and use nabble:
http://www.nabble.com/Version-ranges-and-snapshots-tf4035629s177.html

Can we decide what we are going to do regarding this bug? This issue has been going on for a long time and some resolution is needed now.

In the past, we have made manual patches of maven to fix this bug. However now I have found that I need to upgrade to 2.0.8 and I cannot because of this issue (there may also be other places in maven where this needs to be applied as well). I.e. since the release plug-in did not use maven's core to handle version ranges we had to patch it as well, once this is fixed I would assume it should use the core instead of duplicating logic.

I have found that release-plugin 2.0-beta-6 & 2.0-beta-7 are broken with respect to 2.0.8 if using version ranges, refer to MNG-3351.

The current situation at our company is dire; we have spent the last 2 years implementing an enterprise CI build system using maven. Now we find ourselves in a situation were builds do not work anymore and I can find NO workaround. That is, I have deploys that now fail because I (assume) am tripping over transitive dependency bugs that have been fixed but I cannot use because I cannot get to 2.0.8. I cannot go to 2.0.8 because with it most releases fail (again see MNG-3351).

As far as I can tell, all of the failures are caused by usage of version ranges; hence the need for this bug to be fixed.

It seems the main proponent of retaining the current behavior of version ranges, gets around this issue because he does not use snapshots (does not deploy snapshots). He simply replaces snapshot builds with releases and then manually tags the releases with metadata to indicate the good vs. bad releases. I am not convinced that this is the best way to go for an enterprise CI build system. I feel the normal maven usage of snapshots and releases is too great to give up.

I am at a point now that I need to know if this will be fixed or not, if yes you will make us very happy, as we can continue with Maven. However if it cannot be fixed I am forced into either not using version ranges or not using Maven. We are an international company with well over 100 engineers, it would be great to be able to use maven globally but because of this issue we are forced to rethink our maven usage.

First, let me be clear why we are using version ranges. For internally developed components & applications we make a contract with component developers/consumers that we will not (knowingly) break an existing API unless the major version changes, because of this contract we want developers/consumers to always use the latest version of a released component. Not only does always using the latest released version force usage of that component so we can find problems, apply fixes, etc it also is our dependency version management system. We don't need to ever say what version we want to release with because we always want that which version range is supposed to give us, i.e. the latest released version. (Note we always state the range of versions we will accept, i.e. [1.23, 2.0).

Is there a way I can get this behavior without version ranges? I would be happy to use a different syntax if available.

Now my first option (if this cannot be fixed asap) is to not use version ranges. How can I get this behavior without them? I am not familiar with the other mechanisms maven may have for dependency management. Is there some other technique I can use? If I were to fix all versions could I write some plug-in that would/could dynamically look for latest released versions and then rewrite the pom to use what it finds?

Lastly, I hate to say it but we could move to something other than maven. I understand there are maven like systems, i.e. buildr, that attempt at least to not have these problems. How many other large companies find they can use maven across the entire enterprise? I note there are 14 votes to fix this issue, how are the other 13 working around this bug? I suspect that most using maven are not using it internally to create libraries of reusable components that are consumed by others within the same organization. If there are, I would love to hear how they resolve this issue.

Regards,
Dave Hoffer
X-Rite, Inc.

We have worked around this issue in the following way:

1. Setup multiple repositories internally - one for SNAPSHOT builds, and one for release builds. (We use Artifactory)
2. Configured maven profiles to select whether the SNAPSHOT repository is active.
3. Created scripts to rid the local repository of SNAPSHOTS under certain conditions, like when performing a release.

Here is the script we use to perform a release of an artifact.
Notice it just moves one small part of the local repo out of the way.

#!/bin/zsh
[ -z "$2" ] && {
   echo
   echo "Usage: $0 scmCommentPrefix tag [additional maven opts]"
   echo
   echo "Where:"
   echo " scmCommentPrefix should be the JIRA ID of the release issue, like KWE-55"
   echo " tag is the release number, like 1.1"
   echo " optional additional maven opts, like -Paxis"
   exit 1;
}

d=$(dirname `which $0`)
. $d/fixenv.sh

# maven chokes on cygwin svn in path prior to native port... so fix path if on cygwin
[ -d /cygdrive/c/opt/svn-win32-1.4.5/bin ] && PATH="/cygdrive/c/opt/svn-win32-1.4.5/bin:$PATH"

pre=$1
tag=$2
shift 2

# Swap out qa dir of local repo that may have snapshots for one that doesn't
qar=${qar:-~/.qa-release}
qas=${qas:-~/.qa-snaps}
ciq="$ILM2_REPO/com/company/qa"

echo MOVING AWAY SNAPSHOT CONTAMINATED LOCAL REPO
[ -d $qas -a -d $ciq ] && rm -rf $qas
[ -d $ciq ] && mv -v $ciq $qas
[ -d $qar ] && mv -v $qar $ciq

export MAVEN_OPTS="$MAVEN_OPTS -DSNAPS=false"

mvn clean install ${=*} && \
mvn release:prepare -DscmCommentPrefix="$pre " -Dtag=$tag ${=*} && \
mvn release:perform -DscmCommentPrefix="$pre " -Dtag=$tag -Dgoals=deploy ${=*}

# restore qa dir of local repo
echo RESTORING SNAPSHOTS TO LOCAL REPO
[ -d $qar -a -d $ciq ] && rm -rf $qar
[ -d $ciq ] && mv -v $ciq $qar
[ -d $qas ] && mv -v $qas

Good luck-

I'd tend to favor the approach suggested by kenney on the mailing-list thread for this issue. Something like:

[1.1-1.2]{snapshots=false}

would approximate the sort of advice given to regular expressions in other languages (and maybe in java, can't remember), so there is some precedent. IMO, we can't find a "pure" way to switch this behavior on/off using straight range syntax as we've used it before.

Also, it's legitimate to me to exclude snapshots, since by definition snapshots are part of a development effort...as such, they could contain major regressions and other nasty bugs from version to version. So having a range like the above, I'd almost say the default should exclude snapshots, and use something like '{snapshots=true}' to enable them...

I'm happy to put this code in place, but it may have to wait for 2.0.11 so we can have some soak time, to make sure it doesn't hose anything else.

any solution for this will be complex enough to warrant as much "soak" time as possible...would be good to get this in on the front end of the next iteration.

I'd almost say the default should exclude snapshots, and use something like '{snapshots=true}' to enable them...

Yes, the default should be to exclude snapshots.

For most projects the only thing that would possibly include snapshots would be your own internal work, or bleeding edge case stuff.
Otherwise you would using pure releases.

This issue feels a little like being abandonned due to disagreement on the solution. Is there any chance that the given patch is just applied as is?

It is working fine as a solution to the problem at hand. (And yes, that is a mere opinion.)

Our project contains 200+ Maven2 modules. Currently, we have our CI server build SNAPSHOT versions of all modules, with the dependencies

First of all, I would have expected version ranges to discard SNAPSHOTS. I didn't know about this bug until today, so I guess we must have been lucky that our CI server only uses a repository that contains released versions.

Assuming this bug wouldn't exist, this is the setup I'm aiming for: all the dependencies between the modules are defined as version ranges. We let our CI server build a complete release from all the modules using the Maven2 release plugin. In parallel, we have all the modules also built for the latest committed code (SNAPSHOT), but still using the released version of the dependencies. We define the version range for all dependencies in every project as a property in the POM. A developer that needs to integrate changes in a few modules wants to override the version range to pick up their local snapshot, or a remote one if available (work from colleagues for example). A developer can do this by defining an active profile and redefining the version properties for the modules they want to change. Such a scenario is independent of the contents of local and remote repositories. Even the remote repositories may contain snapshot artifacts.

Now what is the impact of this bug: with snapshots being picked up "by mistake", we have no control over the setup of all the developer machines! The first developer could have local snapshots of A, B and C, while another developer has snapshots B, C and D. If both want to build E on their local machine, the first could report failure, while the second one could report success. A see a lot of time getting lost trying to track down such scenarios. Don't forget that only a small subset of the developers have the knowledge of Maven2 and the whole project setup. All the others just install Maven2 and execute the build. They are hired to develop code, not to fiddle with Maven2.

So please, fix this bug!

FYI. We've resorted to using our own Maven build where we've literally applied the patch that this issue started with. Unfortunately.

Can I suggest also that the check for snapshots in the bound includes versions whose qualifier ends with Artifact.SNAPSHOT_VERSION (instead of equality check)? There are many projects out there (including Maven core projects?) that use qualifiers like "alpha-2-SNAPSHOT" or "BUILD-SNAPSHOT".

It does, it tests equality with the version's qualifier: Artifact.SNAPSHOT_VERSION.equals( version.getQualifier() ).

Hi

It seems that this fix has been somewhat forgotten? Is there any update as to when a fix may be available?

This one looks much like, what we like to call a "hot potatoe", in Dutch. Too hot to handle, to much risk, perhaps, of breaking things. I've sort of given up hope for this one to be fixed, and (yes, repeating myself) resorted to patching it ourselves.

Personally, I've given up attempting to use version ranges in Maven 2 due to the numerous bugs surrounding them. Hopefully Maven 3 will be the much needed panacea..

why not make it optional (via a configuration in the pom eg.) if you are too concerned to change the behavior?

I believe that MNG-3092 currently is the only thing that needed patching in our entire set-up for ranges to work. That's why I vote strongly for this one

Of course "to work" refers to our way it's been set-up, and there are many ways, as to say that I'm not implying at all that you are doing it wrong. As for Maven 3... I just hope it never comes out I remember the earlier days of Maven 2. If we'd get a similar amount of growing pains for 3, I'd happily sign for staying with 2.

My current hit list for version ranges is, in addition to this issue: MNG-2994, MRELEASE-262, MRELEASE-318. Maven 3 has a complete rewrite of the dependency resolution code which, after encountering the original version when writing dependency:tree, is definitely a good thing!

Due to this bug we also gave up on version ranges (and might ultimately give up on maven....although we haven't gone there yet).

Is there any change that this issue is going to be fixed soon?

We are also very interested how the status of this very serious issue is. I tested it with a recent subversion snapshot of maven3 and this issue is still consistent. Will there be any fix in the near future or is it already possible with a special configuration?

Applied Mark's patch in r931890.

When using the nightly maven 3 builds from https://grid.sonatype.org/ci/job/maven-3.0.x-bootstrap/jdk=1.5,label=ubuntu I still see version ranges including SNAPSHOT versions ( which for my integration tests is a good thing, but not for releases ).

Can anyone else confirm that this change works in current M3 builds? Is the old behavior able to be reenabled at all?

I still see version ranges including SNAPSHOT versions

As given by the wiki page referenced by the issue description, SNAPSHOTs are only included in a range if they appear as one of the boundaries.

Is the old behavior able to be reenabled at all

No.

Then somethings seriously broken here - my ranges are [1.0,2.0) and that picks up 1.3.12-SNAPSHOT against current nightly builds.

And if Maven 3 is going to magically STOP doing that by default, and silently have large impacting functionality changes then I suspect A LOT of complaints and bug reports will start coming in..

Looks like the nightly SNAPSHOTs are actually broken in respect this
as well, for some reason my machine had reverted its path settings.

Anyway, I've set up a sample repo with two projects that demonstrate
this problem:

http://github.com/talios/maven-versionrange-test

In this repo, the dependency on releasetest-api is set at
(1.0.0,2.0.0) - which should pick up the 1.3.5-SNAPSHOT, and under
2.2.1 it does, but under 3.0 it doesn't.

I can understand the reasoning behind limiting the SNAPSHOT resolution
for day-to-day projects and for releases, but in the instance of a
C.I. build server doing integration tests, you really want those
SNAPSHOTs to resolve and be used.

If I'm working on 2-3 modules locally I'd also want them to pick up
those SNAPSHOTs without having to release things all the time.

If this change is going to go ahead for the final M3 release, how are
we supposed to use ranges in any sane fashion? We tend to stick to a
model of bumping the major version number on "backwards incompatible
API changes", the minor number on "API addition changes" and the 3rd
patch number for general revs of a bundle. If we were to release all
the time just to satisfy ranges, we could be bumping major/minors
quite often...

Look forward to hearing some comments from you all.

As to the specs, the range (1.0.0,2.0.0-SNAPSHOT) should solve your problem?

Nope. My understanding is that the new behavior is to only resolve SNAPSHOTs at the upper/lower bounds IF they're mentioned. i.e. (1.0.0,2.0.0-SNAPSHOT) would resolve 2.0.0-SNAPSHOT correctly as it's explicitly mentioned, but no other SNAPSHOT would be resolved.

Changing the range in my mini project shows this to still not resolve.

My understanding is that the new behavior is to only resolve SNAPSHOTs at the upper/lower bounds IF they're mentioned

Correct.

(1.0.0,2.0.0-SNAPSHOT) would resolve 2.0.0-SNAPSHOT

No, because you specified the right boundary to be not included.

Even using [1.0.0,2.0.0-SNAPSHOT] to include the 2.0.0-SNAPSHOT doesn't work - which is good as you'd NOT want 2.0.0-SNAPSHOT ( assuming you're changing major version numbers for breaking changes to an API ).

If it did, things would be even worse as you're saying "I'm going to allow this major API change to bleed into project, but only if its not released" - one may as well not use ranges in that case.

Ignore most of that last comment, I just noticed you were commenting on that 2.0.0-SNAPSHOT would be resolved with the ], not the 1.3.5-SNAPSHOT in my repo.

Either way, this is a rather nasty regression that'll break A LOT of builds.

After getting Maven 3 running again I retried our builds at $work with it, I did like the lack of -SNAPSHOTs being resolved for working with individual artifacts as it drove me to actually release some long standing 'test support' artifacts. And I see a good upside of this would be much more regular releasing of artifacts across the board.

However, when it came to running our integration tests, which use the maven-dependency-plugin to copy all of our projects artifacts (listed as test dependencies) to the target directory, and deploy them into an OSGi container, it was apparent that we'd have to drop the use of version ranges and modify the test projects dependencies EVERY TIME one of the projects artifacts changed, as the ranges no longer resolve -SNAPSHOTs.

If this change is going to go ahead and stay in maven 3 - is there an alterative way of doing the above, where an integration build wants to pull in all available SNAPSHOT releases.

Ideally, I'd love to see this new behavior the default in Maven 3, but with an override setting to add into the maven-dependency-plugin or somewhere to allow for SNAPSHOTs.

Mark

I thought I'd come up with a work around by deploying my SNAPSHOT's to my local nexus, given that M3 enforces timestamp'd artifacts rather than -SNAPSHOT.jar files. However, as the metadata still says it's a SNAPSHOT the resolution still fails to resolve the artifact.

Further to this, as I've mentioned previously this currently breaks both our build, and our integration tests. The ITs I think I can handle differently, but the build I think should still work.

In our POMs, we refer to say [2.0.0,3.0.0) for all our project dependencies, this is the output of our current build:

[INFO] ------------------------------------------------------------------------
[INFO] Building smx3.statistics.standard 2.1.11-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] artifact smx3:smx3.statistics.api: checking for updates from Nexus
[INFO] artifact smx3:smx3.reporting: checking for updates from Nexus
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] smx3.parent ....................................... SUCCESS [0.590s]
[INFO] smx3.cachesupport ................................. SUCCESS [6.520s]
[INFO] smx3.util ......................................... SUCCESS [8.716s]
[INFO] smx3.rest ......................................... SUCCESS [5.671s]
[INFO] smx3.hibernate .................................... SUCCESS [4.273s]
[INFO] smx3.schema ....................................... SUCCESS [8.838s]
[INFO] smx3.api .......................................... SUCCESS [4.376s]
[INFO] smx3.schema.provider .............................. SUCCESS [1.692s]
[INFO] smx3.entity ....................................... SUCCESS [3.033s]
[INFO] smx3.testing ...................................... SUCCESS [2.681s]
[INFO] smx3.ldap ......................................... SUCCESS [1.865s]
[INFO] smx3.mounting ..................................... SUCCESS [3.074s]
[INFO] smx3.email ........................................ SUCCESS [1.701s]
[INFO] smx3.translation .................................. SUCCESS [3.944s]
[INFO] smx3.validation ................................... SUCCESS [2.773s]
[INFO] smx3.rules ........................................ SUCCESS [9.373s]
[INFO] smx3.partyresource ................................ SUCCESS [16.961s]
[INFO] smx3.statistics.api ............................... SUCCESS [2.117s]
[INFO] smx3.pdf .......................................... SUCCESS [3.588s]
[INFO] smx3.reporting .................................... SUCCESS [6.325s]
[INFO] smx3.statistics.standard .......................... FAILURE [0.900s]
[INFO] smx3.agreement .................................... SKIPPED
[INFO] smx3.statistics.resources ......................... SKIPPED
[INFO] smx3.template ..................................... SKIPPED
[INFO] mock-template-service ............................. SKIPPED
[INFO] smx3.invoicing .................................... SKIPPED
[INFO] smx3.monitoring ................................... SKIPPED
[INFO] smx3.defaultconfiguration ......................... SKIPPED
[INFO] smx3.restfulobr ................................... SKIPPED
[INFO] smx3.mailhosting .................................. SKIPPED
[INFO] smx3.agreement.reports ............................ SKIPPED
[INFO] smx3.entitysearch ................................. SKIPPED
[INFO] smx3.smartrules ................................... SKIPPED
[INFO] smx3.email.resources .............................. SKIPPED
[INFO] SMX3 Maven Modules ................................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:41.178s
[INFO] Finished at: Tue Aug 10 12:49:42 NZST 2010
[INFO] Final Memory: 44M/123M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project smx3.statistics.standard: Couldn't find a version in [1.0.0, 1.0.1, 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6, 1.1.7, 1.1.8, 1.1.9, 1.1.10, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7, 1.2.8, 2.0.1, 2.0.2, 2.1.1, 2.1.2, 2.2.1, 2.3.1, 2.4.1-SNAPSHOT] to match range [2.4.0,3.0.0)
  smx3:smx3.statistics.api:jar:null

In this instance, smx3.statistics.standard-2.4.1-SNAPSHOT is being built as part of a reactor-build, and the unreleased changes in this artifact are being used by later artifacts.

IMHO, a solution to this version range issue would be to have maven resolve a -SNAPSHOT as part of a range ( original behaviour ) IF that artifact is currently involved in the current reactor process.

This way, the build process here would work fine, but releasing each artifact individually would look for the non-SNAPSHOT as its not part of a reactor process.

Would this be an acceptable change?

Reverted in r997380. This needs to be addressed differently in order to satisfy all use cases.

I really like ranges resolving snapshots. Not including snapshots is a process problem not a technical one. Use the enforcer plugin to avoid snapshots in releases.

I use version ranges and have done so for over 3 years, very successfully on large and small projects. Changing this behaviour IMO would make it much harder to implement decent CI testing HEAD to HEAD, HEAD to RELEASE and RELEASE TO RELEASE.

It used to be important for project linking with m2eclipse but not for the last 14 months or so.

A big no vote from me.

p.s. If anyone wants advice on setting up ranges to work properly I can give you some good advice.

Michael, please update the user wiki with your advice.
Then its searchable via google and it can be referenced.

I think the most severe issue is that you can't release anything which contains a version range currently. You just get an error that the release contains a SNAPSHOT version and the release fails. This basically means that the whole version range feature is not usable at all. I wouldn't consider fixing this bug as a regression, because the specification has been clear from the start (SNAPSHOTs shouldn't be included).

+1 for including SNAPSHOTs in the version ranges if the artifact is in the reactor. I also liked the [x,y)

proposal.
I also agree that this is a process problem and should be enforced by the enforcer plugin, rather than maven core itself.

Btw, besides CI builds, another use-case in favor of including SNAPSHOTs in ranges is IDE integration; we have a project consisting of multiple inter-dependant modules and having them resolve to each-other using ranges is very convenient, rather than updating the POMs everytime one of them is released.

I strongly agree with Syvalta.

We are currently using ranges in our projects, and are now only able to perform releases on maven-3.0-beta-1, as this issue was resolved in that version only. As I understand the enforcer-plugin does not solve this problem, it provides only an after-the-fact observation.

The specification has been clear, so why not fix this issue on the short term (3.0.2?)

I wouldn't mind to have to add the [x,y){use-snapshots=false} to explicitly exclude snapshots, while the default behaviour stays as it is now (include snapshots in the range). I also wouldn't mind a command-line option to disable snapshots in ranges explicitly.

But at least I need something to be able to perform a release in combination with version-ranges. With the current state of maven-3, that's not possible (or at least I don't know how).

I want to vote for a clean and intuitive design: [1.5, 1.6) must not include SNAPSHOTs, [1.5, 1.6-SNAPSHOT) must include SNAPSHOTs. This is absolutely intuitive to most Maven beginners I have asked about their feeling, and it is simple to fix for those why rely on snapshots. I do neither like the idea to make it more complex to exclude snapshots as it is SO SIMPLE AND CLEAR TO READ as writing -SNAPSHOT to include them, nor do I like the idea to wait for more months to get a solution finally. Also I want to point out that it is just obvious that if my project is dependent on a third party library, writing [1.5, 1.6) means that I want specification version 1.5 with latest bug fixes but not features in progress, which is the mosty typical use case. The only case I do see when I want to include SNAPSHOTS is when I do have the dependency in the reactor. Why not making just this single difference? Then nobody must learn a new syntax, it would work as designed and intuitive, and it would actually be very intuitive to also include SNAPSHOTs from stuff in my own reactor.

A related use case: Dependency Resolution and Version Range Conflicts

If you consider semantic versioning http://semver.org/ where by using carefully chosen version numbers (enforced by an api analysis tool) and version ranges to specify your dependencies between your components then version ranges need to support some basic ideas.

I have component A [1.0.0] and component B [1.1.0] and component A depends on component B with version range [1.0.0,1.2.0)

A [1.0.0] depends on B [1.0.0,1.2.0)

We start additional development on B so it will initially be B [1.1.1-SNAPSHOT] So A will pull this in it's current dependency i.e. B [1.1.1-SNAPSHOT] as a dependency (the current behaviour of maven 3.0.3)

Work continues on B and someone adds a method to an interface which is used by A, component B's version is increased to [1.2.0-SNAPSHOT] to signal the possible incompatible change since verion B [1.1.0]

If you think about it, this snapshot of B could be incompatible to A so we need to exclude it in our version range i.e. we modify componment A's dependency version range on B to exclude the 1.2.0-SNAPSHOT

A [1.0.0] depends on B [1.0.0,1.2.0-SNAPSHOT)

So already I'm not liking this since I have to specify I don't want the 1.2 SNAPSHOT but I can live with it.

However the dependency pulled in for A will now always be B [1.1.1-SNAPSHOT], there will never be a release of B[1.1.1] made by us, our baseline is B[1.1.0] and we have not made a new baselien release yet for component B

I've concluded but I could be wrong that you need to be able to say whether you want to include or exclude SNAPSHOT in your version ranges. We develop OSGi bundles. Using the PDE analysis API tooling we compare on going development of bundles with a baseline release and update the POM/Bundle-Manifest version as appropriate depending on code changes. So we require to use version ranges with snapshots included when doing CI but do not include SNAPSHOT when doing releases.

I actually would prefer A [1.0.0] depends on B [1.0.0,1.2.0) to actually mean...

"A depends on B from 1.0.0 up to but NOT including 1.2.0 or 1.2.0-SNAPSHOT"

From our point of view, if you do not want 1.2.0 since it will be incompatible then you do not want 1.2.0-SNAPSHOT either since it will also be incompatible.

To be clear B [1.1.1-SNAPHOT] is valid in the range above by default.

However when building a release we would like to set a property or something equivalent (not in the POM, you do not want to have to go through all the POMS) and exclude SNAPSHOT in version ranges.

I suspect other people may require other scenarios so I see some form of pluggable version range strategy being the answer. You plugin the functionality you require. The default behaviour will be what I have outlines

My 10 pence

I agree someone can find some usefulness in resolving a snapshot with neither the lower limit nor upper limit of the range being a SNAPSHOT, but to support these cases we're transforming version ranges in a useless function IMHO.

Resolving a snapshot without any snapshot boundary makes no sense to me. It's against the own concept of ranges. If you declare a range, you are saying that you project WILL work with any version that matches this range, so why people say that the snapshot should be resolved? why would you choose a snapshot if you can choose a release as both match? If you need something that is only on the latest snapshot, you should go to you pom and change the range boundary to say that.

Have such a bug open for this long time, without a workaround, is a shame! If the community don't agree about a solution, so let's use the most voted, the one the project leader decides, or whatever. Do NOTHING just to be backward compatible is the WORST option.

After converting our complete release process to Maven we have stumbled over this problem. Because of the sheer number of dependencies we are forced to use version ranges. But now some projects refering to SNAPSHOTs and we are not able to release anything without touching all the POMs. So whatever solution you prefer, it will be welcome. But it seems the problem is to agree on a solution. So let me add a vote for the [1.0.0,1.2.0-SNAPSHOT) approach...

I can confirm this bug.
I don't see that the discussion is necessary, because the behavior is explained in the specification:

Incorporating SNAPSHOT versions into the specification
Resolution of dependency ranges should not resolve to a snapshot (development version) unless it is included as an explicit boundary. There is no need to compile against development code unless you are explicitly using a new feature, under which the snapshot will become the lower bound of your version specification. As releases are considered newer than the snapshot they belong to, they will be chosen over an old snapshot if found.

It is possible that applications such as Continuum may have a mode that enables always resolving to the snapshot version, but this is external to the POM itself.

Source:http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges

So my vote goes to the implementation according to the specification.

I think most of this discussion does not only apply to SNAPSHOTs but to any kind of qualifier. If I define a version range of [3.0, 4.0), because I expect breaking changes in 4.0, then I don't want any artifact belonging to the 4-series (no '4.0-alpha-1' and no '4.0-SNAPSHOT').
Last time I checked with Maven 3.0.4, '4.0-alpha-1' was included.

In opposition to SNAPSHOTs, other qualified version (like '3.5-beta-2') should be included in the range.

I strongly agree with fixing this so that it conforms to the specification. I don't see how this is even an issue. If the behaviour doesn't need to conform to the specification, then why write it in the first place?

As said above, I don't want a SNAPSHOT version of the next major number to leak into my project, with potentially breaking API changes. I want the stable updates of the current version.
As it is now, the ranges feature is completely useless to us.

This issue is just pain in the neck, and I like to add another strong vote for just implementing the spec right now. As of now we got two options: Do not use ranges (which is quite impossible with more than 40 dependencies in average), or build the snapshot against unstable snapshots (so there is no chance to get a clue about how a final release of that snapshot will behave, because till then everything is build against unstable components (which are build against unstable themselves, and so on). Any solution would be very, very helpful!

I would also like to vote for a fix asap. I made the assumption that the spec was already implemented correctly, and now I have to spend more time figuring out how to set my project up with some workaround. If the spec is not good, write another one. If you can't come to a decision on how this will be implemented, then somebody needs to make the executive decision. What ever the path, this need to be resolved and soon. Original post was 5 years ago... just say'n.

Like Sören Chittka and Niklas Herder said. It makes no sense for the pre-release version of an excluded version to be included in the build.

Just had to work around this myself with using a very high (sub next major) version for the range boundary.

http://www.infoq.com/news/2012/04/osgi-snapshot and it's comments are a very lively recent (mid-2012) discussion that is worth reading in the context of Maven versions and OSGi.

It may be that I'm overlooking something so please point out obvious drawbacks/errors. However; would it not be desirable to:

• IF the project version is a -SNAPSHOT version also resolve dependency ranges to -SNAPSHOT versions
• otherwise ( project is a release version) do not.

edit; I realise that this would make version resolution context dependent which may be (very?) undesireable

Another 3 months and no comment.

I agree with Merlijn. For development, we always want to pull in the latest, greatest module to either build against or run pre-acceptance test against. We have 15+ modules that are loosely-coupled, but developers typically need the latest version of their dependencies. Towards the end of development, things are locked down, but not early on.

Version ranges worked great with 2.2.1, but with 3.0.4 it is abysmal. I'd have everyone stick to 2.2.1, except Maven embeds 3.0.4 and insists on using it for resolving dependencies, hence the problem (even if you associate your 2.2.1 install).

Whatever it is, resolve version ranges so we can at least move forward. Someone in power take a stand and push something - anything - forward so we don't have to wait another 5 years for a solution.

Since it looks like a 3.1 release of Maven is on the horizon, it would be REALLLY nice to get this sorted - or at least a clear direction/plan of a proposed resolution.

yes, Maven 3.1 can be a chance to do something
to me, the question is not "is a snapshot in a range?", because the reply is obvious: yes, a snapshot is in the range since a range is a mathematical notion with two bounds and an order (a comparison algorithm)
but the questionis more: "how does Maven choose the best match when multiple artifacts are available matching restrictions?" (I say "restriction" to avoid "range" and since ranges are only one form of restriction)
then we need a use case with a reproducible simple test to work on it (and I need to look for where is the code that makes this choice)

is somebody interested in working in such a direction?

when I read http://www.infoq.com/news/2012/04/osgi-snapshot, I understand they cannot do SNASPHOT this way:
a SNAPSHOT in Maven is not 1.1.20121108..., but 1.1-20121108...: notice the dash instead of dot, and read the Maven comparison doc "a dash usually precedes a qualifier, and is always less important than something preceded with a dot."

if OSGi can't afford a new separator, they can't do SNAPSHOTs like Maven, or they'll face problem reported by the article: the comparison algorithm is based on a bad trick to change behaviour when a minor number is detected as a timestamp then not treated as a real number

For me the major annoyance in the current resolution mechanism is that [1.1.0, 1.2.0) appears to include 1.2.0-SNAPSHOT, but exclude 1.1.0-SNAPSHOT, which looks completely counter-intuitive to me. In order to make sure that 1.2.0-SNAPSHOT is never resolved to, one needs to change all range specifications to an equivalent of [1.1.0, 1.1.999] in the above case. This does not solve the problem of not resolving to the initial snapshot in the range (1.1.0-SNAPSHOT in our case). When one starts development of a 1.1.x line, they are forced to change range specifications in dependencies to a fixed 1.1.0-SNAPSHOT version until the time 1.1.0 is released.

Another major annoyance is that whenever there is a snapshot in the local repo and that snapshot is resolved from a version range, the release build of a dependent project is doomed to fail. There is no way to force Maven release execution to disregard snapshots and resolve to released versions only. In fact this is almost a blocker, unless one uses a workaround as described below.

We have a very fluid project consisting of lots of applications and lots of internally developed libraries, and we have to use version ranges for internal dependencies, because otherwise keeping tens of projects in sync with their upstream dependencies becomes a living hell. However, because of this very MNG-3092, we had to make special arrangements in our CI environment in order to make our builds stable and predictable.

In our CI environment, we have two completely Maven settings.xml configurations:
a) configuration for snapshot builds, which resolves from both release and snapshot remote repositories and has its own separate local repository;
b) configuration for release builds, which does only resolve from remote release repositories, and has its own separate local repository.
We use configuration (a) for CI jobs that either run "snapshot vs. snapshot" builds, or nightly code analysis builds. We use configuration (b) for CI jobs that run "snapshot vs. release" builds and for releasing new versions of artifacts (effectively "release vs. release"). Only by separating local repositories and by making sure that snapshots never make their way into local release repository we can make sure that our release builds are stable.

Considering the current issue from a wider perspective, I am curious if there's generally a strong use case for fine-grained control on snapshot resolution (on a dependency declaration level), or whether the snapshot resolution strategy must apply to the entire build execution.

Personally I am leaning towards an execution-level control via e.g. a command line option. This way,
a) one could easily switch between "snapshot vs. snapshot" and "snapshot vs. release" configurations in the same build, without having to set up separate environments. This could especially be useful for IDE integration.
b) maven-release-plugin could automatically suppress resolution of version ranges to snapshots in forked maven executions.
c) no additional changes are required for POM model.

To summarise, here's what I believe the desired behaviour would be, with the option turned on or off respectively:

1. mvn --use-snapshots-in-ranges=false
This includes forked Maven executions from maven-release-plugin.
[1.1.0, 1.2.0] resolves to 1.1.0, 1.1.1, ..., 1.2.0
[1.1.0, 1.2.0) resolves to 1.1.0, 1.1.1, ..., 1.1.99999999999
(1.1.0, 1.2.0) resolves to 1.1.1, 1.1.2, ..., 1.1.99999999999
(1.1.0, 1.2.0] resolves to 1.1.1, 1.1.2, ..., 1.2.0

2. mvn --use-snapshots-in-ranges=true
[1.1.0, 1.2.0] resolves to 1.1.0-SNAPSHOT, 1.1.0, 1.1.1-SNAPSHOT, 1.1.1, ..., 1.2.0-SNAPSHOT, 1.2.0
[1.1.0, 1.2.0) resolves to 1.1.0-SNAPSHOT, 1.1.0, 1.1.1-SNAPSHOT, 1.1.1, ..., 1.1.99999999999-SNAPSHOT, 1.1.99999999999
(1.1.0, 1.2.0) resolves to 1.1.1-SNAPSHOT, 1.1.1, 1.1.2-SNAPSHOT, 1.1.2, ..., 1.1.99999999999-SNAPSHOT, 1.1.99999999999
(1.1.0, 1.2.0] resolves to 1.1.1-SNAPSHOT, 1.1.1, 1.1.2-SNAPSHOT, 1.1.2, ..., 1.2.0-SNAPSHOT, 1.2.0

How does that feel?

For the record what is documented here as it pertains to snapshot resolution in ranges is incorrect:

http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification

If there is a range specification there is no special exclusion for SNAPSHOTs currently and right now the behaviour of how snapshots work in ranges works the same in 2.x and 3.x. Maybe not ideal but that is where it stands today.

This issues touches on snapshots and pre-releases in general as well as trying to take the latest version of a semantically compatible set of versions. I'm not sure how to ideally make this work properly for all those use cases with a simple fix.

Right now by limiting the repositories that are available to a build you can block the inclusion of snapshots. I'm not suggesting this is ideal but you can block snapshots from builds if you so choose. I have been looking at this for 2 days now and it's not something I just want to jam into 3.1.0 so I'm pushing it out as the issue now conflates several issues. It will take me a solid week just documenting and trying to figure out what's best and discuss it.

Unfortunately some projects keep publishing pre-releases even into The Central Repository, so it is actually not an option to sort out "pre-release repos", as you would effectively end up with not using Central anymore. The only really clean solution can only be (and this will break backwards compatibility) that pre-releases (hence SNAPSHOTS) are definitively NEVER contained in a range, unless there is a special marker provided to explicitly enable those.

+1 on pushing to 3.1.1 - I'd rather see some good thoughts/docs and consensus before making any changes here. As Herve mentions the problem is not so much the range resolution, but the version selection - an initial thought of mine requires POM schema changes: adding <selection>lowerbound/upperbound</selection> and <snapshots><enabled>true</enabled></snapshots> (or similar) to the <dependency> element - <selection> could be default to upperbound ( existing behaviour ) or even defaulted to that for <compile> scope, lowerbound for test. One could even do that without changing the pom, but it is a change in behaviour.

Since the introduction of the dependency:purge-local-repository goal I've also come to add that to my release plugins prepareGoals, this forces any local -SNAPSHOTs to be removed during a release so only released artifacts get used - this actually solves 90% of my initial "no snapshots in ranges" problems.

Pushing pre-releases into Maven Central is perfectly acceptable. I agree that we need to deal with pre-release filtering but blocking their publication from Maven Central is not the answer. Projects need to be able to share these versions to vet them. It needs to be a filter on the client. So yes, without writing something currently or patching Maven it's not possible to block. So allow a pluggable DependencySelector to Aether is the answer here. But we need to find a way to expose it. I understand your concern.

Snapshots receive special treatment in Maven. For instance, Maven settings and POM model support separation of snapshot and release repositories, there can be multiple timestamped snapshots for the same version, release plugin by default rolls the version from snapshot to release and then to the next snapshot, and so on. Therefore I believe that resolution behaviour for snapshots should be controlled/configured separately from other pre-release versions. I can certainly see a use case for including or excluding pre-releases, betas and milestones from ranges, but although it appears related to the current issue, I would prefer not to mix and mash the two cases together.

this Jira issue is about SNAPSHOTs only, and not only at range bounds but inside the range
pre-release exclusion from upper-bound is done in MNG-5353
and we have no Jira issue for the moment for pre-releases exclusion inside the range

I'm surprised of the focus for excluding snapshots; I see snapshots as being the main use case of ranges, in a development environment as I and at least one other have described.

For a release artifact, I expect it to have well-known, tested, absolute dependencies. I don't want dependencies wandering as, for example, new versions of log4j get released. When the new version of log4j has been tested/approved/certified, then put out a new POM with a slight version modification. And I would never expect (or use) a released artifact that used snapshots.

However, a snapshot artifact should be able to use ranges referring to both snapshot and released artifacts, as necessary.

Instead of flags to determine inclusion/exclusion of snapshots within ranges, can we base on the type of artifact?
-For released artifacts, ranges only include releases and no snapshots in dependency resolution
-For snapshot artifacts, ranges include both release and snapshots in dependency resolution

The other question is to determine where snapshots fall in a version range. If you presume that a released artifact represents finality, then snapshots always are less than the released artifact.

[1.0.0,1.3.0] starts at the 1.0.0 release up through the 1.3.0 release. If the built artifact is a release, then you'd consider all 1.0.x, 1.1.x, 1.2.x releases as well as 1.3.0 itself. If the build is a snapshot, you'd also consider all > 1.0.x snapshots, all 1.1.x snapshots, all 1.2.x snapshots, and all 1.3.0 snapshots.

[1.0.0-SNAPSHOT,1.0.1] implies building a snapshot artifact, discussed previously, and should consider all 1.0.0.x snapshots, 1.0.0 release, all 1.0.1.x snapshots and 1.0.1 release.

[Not comprehensive examples, but hopefully enough to move the conversation forward.]

Now that this has been moved to 3.1.1, how do we continue this conversation so it doesn't die off again until 3.1.1 is next up. This must be dealt with eventually. If no resolution is determined, than at least go back to the functionality as implemented in Maven2. While not perfect, it doesn't break backwards-compatibility.

This ticket is 5.5 years old - what concerns me is version ranges in Maven are utterly broken by this, and as such warnings should be in place everywhere informing users of this fact.

We have invested considerable time in using version ranges to support semantic versioning, only to find our releases are broken.

There seems to be discussion about whether this is a bug or a feature - it's a bug, plain and simple; either in implementation or design.

Please, please fix this.

Another problem we've run into is that the Eclipse m2e plugin forces Maven 3.x for dependency resolution and it can take 40-60 minutes because it looks at each artifact individually, whereas Maven2 is smarter (don't know the details) and finishes in seconds.

I'd propose that the verion-range functionality of Maven2 gets restored in Maven3 until a complete, properly-thought-out, properly-implement solution becomes available.

Caspar, for me it's also clear that it is a bug. We've also spent a lot of time to use version ranges in our projects, and double time to remove all versions from all projects, because of this and other version ranges bugs.

Considering the age of this ticket, and the posts made by maven maintainers (mainly Jason van Zyl) recently, I don't think we'll have a decent fix for this soon. The only short term solution I can see is fork, which unfortunately I don't have resources to do.

We need to resolve this problem, as this is going on since many years. I have made code change in Maven with this assumption that if User keep SNAPSHOT at any place(lower or upper) in range it means user is expecting SNAPSHOT for dependency, if User does not put SNAPSHOT it means User is expecting only release.

Example:
Available jar version : 13.0.0-SNAPSHOT, 13.0.0, 13.0.1-SNAPSHOT, 13.0.1, 13.0.2-SNAPSHOT, 13.1.0-SNAPSHOT (Don't have 13.0.2)

<version>[13.0.0-SNAPSHOT,13.1.0-SNAPSHOT)</version>
Selected : 13.0.2-SNAPSHOT
<version>[13.0.0,13.1.0)</version>
Selected : 13.0.1
<version>[13.0.0-SNAPSHOT,13.1.0)</version>
Selected : 13.1.0-SNAPSHOT
<version>[13.0.0,13.1.0-SNAPSHOT)</version>
Selected : 13.0.2-SNAPSHOT
<version>[13.0.0,13.0.1)</version>
Selected : 13.0.0
<version>[13.0.0,13.0.1]</version>
Selected : 13.0.1
<version>[13.0.0-SNAPSHOT,13.0.2-SNAPSHOT)</version>
Selected : 13.0.1

Looks good to me.

What's the performance look like? As mentioned before, Maven3 was significantly slower in resolving version ranges.

Also, what release would this go into?

Thanks a lot!

@Kunalkumar What you suggested would break my workflow which is to use separate settings.xml while releasing (no snapshot repos and separate local repo). This way release plugin never sees snapshots and ranges can be left untouched. It even encourages to release more often in order to see if something is broken. An identical CI instance that only sees the releases, installs to /dev/null and doesn't deploy anything would make this approach even more robust.

Release plugin would (or at least should) stop working for us with your suggestion because of SNAPSHOT ranges. SNAPSHOT range removal before releasing and resetting after releasing would be tedious and error prone even when using versions plugin.

Tuomas: If you have problems with this approach, what is an approach that works and can address the issues mentioned in this thread? I don't know enough about your workflow, but it would seem that different settings.xml wouldn't require the tedious changes you mentioned in your last paragraph, wouldn't require resetting after releasing.

After 5.75 years, this issue must be addressed. Kunalkumar proposes an approach, instead of finding faults with every approach/suggestion, let's use this as a line-in-the-sand and refine it further. We need a starting point, this seems reasonable in its assumptions. Also realizing that no solution is going to please everyone, what's proposed at least is sensible and is not broken like the current Maven3 range functionality.

Or, let's admit defeat and restore what's in Maven2. Yes, it's broken, but no more so than what's in Maven3 (and probably less so). At that point, instead of rewriting range functionality, small incremental changes can be made, evaluated, extended, etc. But what we have now is ridiculous.

...and this couldn't illustrate any better why outsiders get frustrated with software developers. Even Debian's come out with 2 releases in the same timeframe.

@Scott Sosna - you really need to click the link "workflow" (hint; links to XKCD) =) I reacted the same as you until I realised it should have been posted on April 1st.

Thank you, Caspar, too early in the morning.

Regardless, can we get some positive movement on this?!? I'd rather not be quote <a href="https://www.youtube.com/watch?v=mBmExt184vc">The Maven</a> going forward.

Hi Scott, at least it's Friday. Thanks for the link, my day has taken a strange Dickensian twist now =] Cheers

For the avoidance of doubt, the following comment does not contain or imply any humour or jokes.

I totally agree with Tuomas that Kunalkumar's proposed patch would not solve the problem.

We want to be able to run two different builds: "snapshot vs. snapshot dependencies" and "snapshot vs. release dependencies" on the same project that uses defined dependency ranges, but without the need to mess about with the ranges.

"Snapshot vs. snapshot dependencies" build verifies that the latest changes on the trunk did not break the project. This build must pick up 1.1.2-SHAPSHOT from [1.1.0,1.2.0) range, provided that 1.1.2-SHAPSHOT is the latest available on 1.1.x branch. A complete set of such builds for all projects verifies that the current tree is consistent and all modules are compatible.

"Snapshot vs. release dependencies" verifies that the project can be released at this time using the existing released versions of dependencies. This build must pick up 1.1.1 from the same [1.1.0,1.2.0) range, even if 1.1.2-SHAPSHOT is available. If such build breaks, it indicates that the upstream projects may need to be released first.

At present, the only way to achieve a clear separation of snapshot and release builds is to set up two separate tightly controlled build environments. You can scroll up for my previous comment, where I described how our CI environment is set up a greater detail. I cannot tell whether Tuomas's comment contained a hidden humorous reference to mine, or whether he indeed has a very similar set-up, but I prefer to think it is the latter.

We only ever use version ranges for our internal dependencies, all external dependencies and plugins are always pegged to specific versions and any upgrades are done in a controlled way. My personal preference is that the inclusion of snashots into version ranges needs to be controlled on the build level, outside of the POM, so that they can be turned on and off all at once. For example, it may be a new dedicated command line option or an additional profile in the settings.xml.

@Sergei, everyone has different view to look at the problem. We have gone back and forth on this behavior a couple time.

I totally agree with Tuomas where he has mentioned in last paragraph, it will be very tedious for SNAPSHOT range removal before releasing and resetting after releasing but anyways we are removing the SNAPSHOT while releasing any artifact.

With your thoughts User can pass property in maven command -DuseSnapshotInRange=false and it will exclude all SNAPSHOT from range. The problem what I can see here is if we have range defined in parent POM then you need to ask reference POM to use this new parameter else it will pick latest SNAPSHOT if available in repository.

@Scott Sosna - I'm using snapshot inclusion blocking approach which is already quite well covered by Sergei. For other purposes the less intruding pluggable Dependency Selector approach as Jason suggested might be achievable even today by using javaagent and aspects. This would not require patching/forking nor tampering with current version range semantics.

@Sergei Ivanov/Kunalkumar Somani - For my purposes MNG-3328 would provide a way to combine the two separate settings.xml back to one using a system property or an environment variable (such as IS_M2RELEASEBUILD) so that proposed new CMD line options could be omitted.

PS. I don't mean any disrespect to anyone who has put effort - both in time and/or patience - on to solving this matter. Comic served just as a reminder that every change breaks someones workflow.

This way we will never come to a conclusion.

@Tuomas, the other approach what you have mentioned requires a lot of effort.
I totally disagree to modifying setting.xml file because there is more risk as normally the user does not change this file.
At this moment we are looking for a simple solution and I totally agree with Sergei and Kunalkumar if we give option in CMD line it will be more flexible,easily understood and traceable.

We are stretching the problem to far we just need a simple solution.

@Kunalkumar: can you please illustrate the potential "parent POM" problem with an example? I can't see a problem there, but perhaps I am missing the obvious.

Is there anyone currently discussing this that's been involved from the beginning? Mark Hobson and David Hoffer started this conversation but neither have added anything in quite some time. Could the difficulties in finding a solution be that we've either lost site of the original requirements or that the requirements have changed? With a clear, complete, updated requirements statement, any solution could be vetted against the requirements. As it is now, I'm not sure anyone has the same picture, and we're just going in circles.

Anyone volunteering?

As per Mark Hobson we should disallow snapshots in ranges when they aren't in explicit boundary.

http://www.mail-archive.com/dev@maven.apache.org/msg68512.html

I still disagree with that approach, because it forces maven users to edit poms.

@Sergei Ivanov: What's your alternative? Could profiles alleviate the need for multiple POMs? Is there some other way?

The other point I'd like to point out is that Mark, et al did agree that the previous behavior was theoretically correct. Therefore, if a solution can't be found, the previous behavior should be restored until someone can actually come up with an approach that can gain consensus.

@Sergei, How are you going to remove the SNAPSHOT for your artifact? I mean when we are releasing SNAPSHOT artifact, we keep SNAPSHOT in version and when we are release artifact we remove SNAPSHOT from version. Then whats wrong with it, don't stick with your solution and think more on top of that.

I have already expressed my preference: either a command-line switch to disable snapshot resolution in ranges, or a system property, e.g. -DenableSnapshotsInRanges=false. In order to retain full backward compatibility, snapshots will need to be enabled by default.

The advantages of a build-level control are:
1. it consistently applies to all dependencies within the entire execution of a maven build
2. one does not have to edit the POM files in order to force inclusion or exclusion of snapshots: the same range will be resolved correctly in each case, depending on the switch state. This, for example, will allow to run two CI jobs for the same project: with snapshots enabled and disabled, without the need to use separate local repos and separate settings files.
3. from Maven implementation perspective, it does not require changes to the POM or settings file model

Minor caveat:
At present, one would still need to pass the correct arguments (i.e. disable the snapshots) down to the forked Maven invocation from the release plugin. This can be achieved via plugin configuration right now, but later it can be made an explicit option of the plugin (with snapshots disabled by default in the forked release builds to make sure they never break even if resolvable snapshots are present in the local repo).

@Joniec: the current issue only covers resolution of snapshot dependencies from version ranges. It is not generally applicable to dependencies between reactor modules in the release lifecycle, because normally modules in the reactor use an equivalent of ${project.version} to refer to each other and that will continue to work even when maven-release-plugin rolls the versions of all modules forward (first to the next release version, then to the next snapshot version). Neither will the proposed change impact the ability of maven-install-plugin and maven-deploy-plugin to deliver snapshot versions of a project into the repo.

Again, if you have a concern about a particular edge case, please provide a specific example.

And what about the compile time? You will get latest artifact at compile time including SNAPSHOT too.

Don't you think you need to solve this problem at compile time.

Can you please provide a minimal example. In all honesty, I cannot see what the problem is, if there is a problem.

@Sergei, please find below example...

Available version: 1.0.0, 1.0.1-SNAPSHOT

In POM you have defined version range [1.0.0,1.1.0]

If you pass the parameter -DenableSnapshotsInRanges=false as build time, build will get 1.0.0 and it will build perfectly but while developing your project you will get 1.0.1-SNAPSHOT because you cannot pass the parameter at build automatic process. It only work at build process time and you have to run maven command.

Just curious, who has the final say on this? Normally, I would hope for consensus, but I'm not sure that's possible on this issue after this length of time.

@Scott, it's being many years and no one is responding on it. I like Kunalkumar's solution, it solve our problem and would like Jason to review it and give comments on it. Kunalkumar already attached the patch and want someone from Maven Org to review it.

@Joniec:
Are you concerned about the way it is going to be handled in IDEs? I personally don't see that being a problem, although IDE vendors may need to implement the equivalent of a command line option for embedded Maven engines.

To your example. Let us elaborate on it a bit, so that we can be sure that we are all on the same page.

Suppose we have project A. Local version of project A is 1.0.1-SNAPSHOT, remote repo contains versions 1.0.0 and 1.0.1-SNAPSHOT.

Then we have project B, local version 2.1.0-SNAPSHOT, which depends on A with a defined version range of [1.0.0,1.0.1].

If we build B on command line with -DenableSnapshotsInRanges=false flag, then B picks up A:1.0.0, otherwise it picks up A:1.0.1-SNAPSHOT. If we release project A, then regardless of the flag B will pick up A:1.0.1, because the new snapshot A:1.0.2-SNAPSHOT will fall out of [1.0.0,1.0.1] range.

Now, suppose we open both A:1.0.1-SNAPSHOT and B:2.1.0-SNAPSHOT in an IDE. The default resolution behaviour is that snapshots are included in ranges, thus our projects will be linked together inside the IDE, which is typically the desired outcome. If we only open project B in the IDE, or the local version of project A falls outside of the range defined in project B, then IDE resolves B's dependency from the local/remote repo in a default way (unless the IDE offers some degree of control over it). If we want to peg B's dependency on A, we edit the local POM, which is no worse than the alternative proposal of including snapshot versions in ranges explicitly, and then editing them again before releasing the project.

@Kunalkumar:
Again, I do not see what the problem is with the parent POM. If I understand it correctly, Maven always interpolates the project's POM entirely before attempting to resolve dependencies.

Let's set up the following project structure:

./pom.xml
./child/pom.xml

The POM file contents are below:

<project>
    <modelVersion>4.0.0</modelVersion>

    <groupId>test</groupId>
    <artifactId>parent</artifactId>
    <version>1.0</version>
    <packaging>pom</packaging>
    <modules>
        <module>child</module>
    </modules>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>[3.8.1,4.0)</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</project>

<project>
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>test</groupId>
        <artifactId>parent</artifactId>
        <version>1.0</version>
    </parent>
    <artifactId>child</artifactId>
    <packaging>jar</packaging>

</project>

Now change to child directory and run mvn help:effective-pom. In the output you will see:

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>[3.8.1,4.0)</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

Note that the range is still there. Now, after the project has been interpolated (that is, an effective POM has been built), Maven will attempt to resolve the dependencies. It will apply the same resolution logic to every dependency range it encounters. If snapshots are disabled in ranges via a global build-level option/flag, each range will be guaranteedly resolved to the highest available release version. If snapshots are enabled, we revert to the current behaviour.

The same principle applies to any transitive dependencies. If project A depends on project B:2.0, and project B depends on C:[1.0,2.0), then the range is still resolved using the same build-level resolution strategy. If snapshots in ranges are allowed for the current build execution, then A ends up depending on e.g. C:1.1, otherwise it ends up depending on e.g. C:1.2-SNAPSHOT.

The main advantage of the build-level control that I propose is that by excluding the snapshots from version ranges, the project's direct and transitive dependencies are guaranteedly resolved to release versions only, with the two exceptions below.

With snapshots in ranges turned off, there are only two ways that the project's dependency can resolve to a snapshot:

1. project A depends on B:1.0.2-SNAPSHOT explicitly. In this case there is no range definition, and there is no error.
2. for example, B:[1.0,2.0) contains only 1.0.0-SNAPSHOT and 1.0.1-SNAPSHOT, and the range does not resolve to any release version. This must trigger a build error (unresolved dependency) if snapshots in ranges are disabled.

I like sergei's proposed solution here. Having to edit the poms to switch between release/development mode would a pain. Another plus is that the behaviour will not change from the current state if you choose not to make use of the build flag. I realise my opinion probably has zero influence but may be others could comment/voice an opinion about the issue so we can reach a consensus. It would be sad to see a decision made that most disagree with.

Have we narrowed it down to just these two approaches? And does it solve all the issues in this thread? I see some discussions about versions 4.0-alpha-1 and should it behave like 4.0-SNAPSHOT, I'm concerned we've addressed the happy-path (not that there's anything happy here) and want to make sure everything is addressed (even the statement is "that's silly").

Also, what are the performance impacts on either of these approaches? For my projects, Maven3 is substantially slower in resolving versions, making things like the Eclipse m2e plugin borderline useless. Dependencies need to be resolved as quickly as in Maven2.

If these are the two approaches, who approaches the Maven committers or whomever to get signoff on an approach and get it commited to the branch?

Sergei's proposed solution fits best with a -D command line switch and/or an attribute for the compiler plugin. This would work similar to -DskipTests=true with the junit plugin.

I fully agree with the observations Merlijn highlighted, switching poms between release and development will be a pain or having to have two poms in a project. This diverges from the simplicity maven provides in a build. Also pointed out is that this proposal will not break default behaviour else it would be a breaking change for anyone upgrading.

@Scott: I am deliberately trying to not consider anything but snapshots in the context of this issue. As Herve noted above, resolution of pre-release versions is partially covered by MNG-5353, but it is a much wider and more complex issue. Unless someone from Maven core team volunteers to engineer a complete solution, we may be better off focusing on and solving only the most painful issue, which is this very MNG-3092.

I am proposing a solution that will only affect snapshots and will hopefully remove the major pain that we are experiencing on a daily basis. A solution that allows to reuse the same POM file for building against either snapshots or releases. Without the need to edit ranges in the POM file on a regular basis (and the unwillingness to edit POMs every time the dependency is released is the very reason that we use dependency ranges in the first place).

@Alex: please note that the switch cannot be an attribute of maven-compiler-plugin. Dependency resolution takes place way before the plugins are initialised (at least the ones annotated with @requiresDependencyResolution).

My questions are: will the Maven core team accept a patch that only addresses a portion of this discussion? And if not addressed, how do we avoid extending discussions on this issue another 6 years?!?

I fully agree with wanting to take incremental steps, and hopefully this is acceptable. I also know that the current implementation resolves dependencies magnitudes slower than what was in Maven2. Locking down the behavior is fine, but it doesn't help me if the overall performance doesn't increase as well. I have Eclipse users breathing down my back who want to flat-out ditch Maven because of the Eclipse plug-in problem (the plug-in insists on embedding Maven3 with no way to override it for dependency resolution).

So dealing with just a subset may not be enough, for me, for others, for the core team. And if it's not, the previous functionality of Maven2 (and very early Maven3) should be restored.

@Sergei, you believe we need to change the default behavior of IDE, right? According to you we need to change the IDE behavior first to solve this simple problem.

Here is the example suppose I have project A 1.0.0 and 1.0.1-SNAPSHOT from one Team.

Project B different team is depending on A.

Project B is developing their project and using range [1.0.0,1.1.0] of A, development time you will get 1.0.1-SNAPSHOT but build time you will get 1.0.0 because you are passing parameter.

If you think we need to fix IDE first then we should stop commenting here and ask all IDE to fix it first. Pls don't take it personally.

How many maven command line options exist that affect the build without a corresponding XML element? You can put <skipTests>true</skipTests> in your surefire configuration. Since this cuts across <dependencies> and <dependencyManagement>, it seems to me if this were to be an attribute it would have to be at the top level: http://maven.apache.org/pom.html#Quick_Overview

It seems about 50% of the people on this thread believe a range should never contain a SNAPSHOT. If that's the case it would be nice to put <enableSnapshotsInRanges>false</enableSnapshotsInRanges> in your topmost corporate pom and not have to worry about it going on the command line of every build.

If the solution also needed to cover MNG-5353, it feels like you would need additional options. So maybe
<rangeResolutionAdvice>noSnapshots</rangeResolutionAdvice>
or
<rangeResolutionAdvice>noPreRelease</rangeResolutionAdvice>
or
<rangeResolutionAdvice>...?</rangeResolutionAdvice>

If you wanted different advice for different stages of development, you could put this attribute in a profile you could activate from the command line.

I'm not sure of the technical hurdles to something like <rangeResolutionAdvice>, but in my opinion it seems like the most complete solution. I'm not heavily invested in version ranges at the moment, but thought I'd throw in my $0.02.

Ok so in that case you need to change POM file for release and SNAPSHOT, then what is problem with putting and removing -SNAPSHOT from range and here you don't required more attribute as well and it easy to understand

I'm in the other 50% who require snapshots to be included in ranges for development, and changing that breaks previous behavior. Sure, I can make the change, that's fine, but 50% of the populations going to be inconvenienced, and if they haven't been following this, they'll have no idea why. Potentially dangerous.

Also, I cannot wait n months until all the IDEs support behavior that I'm not convinced could be decently explained to them. We've had almost 6 years to scope this out, and nothing's happened, why does anyone believe it's going to happen now. Let's restore the behavior from Maven2 - regardless of how right or wrong anyone feels it is - and start with a clean slate. At least it was understood and usable, what we have now in Maven3 is neither.

@Scott, that is what I'm asking to all if you go with http://www.mail-archive.com/dev@maven.apache.org/msg68512.html it simply says "We stick to the design docs and disallow snapshots in ranges when they aren't an explicit boundary"

We need this to be resolve ASAP with simple solution until new design finalize

@Joniec
Agreed, it needs to be solved ASAP.

But if it isn't resolved - and it's 3 months short of 6 years - the second possibility listed is to "leave range resolution behaving as it is, then use profiles to enable or disable snapshot repositories at build time." The history on this issue does not lend confidence in trying to implement the design docs as defined, and if we can't then the original Maven2 behavior should be restored.

@Scott
Reverting to dependency management from Maven2 is not an option. Firstly, because Maven3 uses an entirely new dependency management library. Secondly, because dependency resolution that involves ranges is broken in Maven2, and we went through really hard time when we had to adapt our Maven3 project to be usable by another team, who are still on Maven2. Effectively, we ended up providing them with an alternative POM, where all version ranges were removed and versions locked down.

@Joniec
No, the default behaviour of IDEs will not change. Neither will change the default behaviour of Maven. One will need to override it with the new switch to exclude snapshots.
If the team of project B does not override the default behaviour, they will be both building and developing against 1.0.1-SNAPSHOT. If project B starts using features from A:1.0.1-SNAPSHOT that are not available in A:1.0.0, then they will not be able to release (or build with the switch turned on) until project A releases 1.0.1.
They can set up (like we do) two CI builds, one of which will verify that project B still builds against the latest released version of project A (1.0.0), and the other one will check that project B builds against the latest snapshot of project A(1.0.1-SNAPSHOT).
If team B never want to build or develop against snapshots of A, they can control it via repository management. Or they should perhaps not use ranges in the first place (which is probably a good idea if the teams are developing at different paces and want to have better control of their dependencies).
All in all, they will not be worse off than they are now.

@Paul
In an ideal world, yes we'd be able to extend Maven POM model and carry on. Unfortunately, this has a potential to break projects that are still using previous Maven versions. This is the reason why Maven core team are so reluctant to introduce any changes to the model.
I agree, we may want to control it in a finer-grained way. Like specifying the default resolution strategy on the <project> level, and posiibly overriding in on the individual <dependency> level.
In a real world, this MNG-3092 saga has been going on for ages, and the only alternative proposed solution involves modifying the POMs on a regular basis to achieve the desired behaviour. Personally, I do not want to go through tens of related POMs in my project and introduce snapshots in ranges so that I could use them in my IDE, and then revert the changes when I want to release them. This would completely negate any benefits of version ranges. I am proposing a solution that (1) will not break backward compatibility of maven builds by default, (2) will not require changes to POM model, (3) will allow to use the new behaviour without the need to edit POM files (essentially, you can switch between the old and the new behaviour when using the same POM file). I do also desperately want a concrete solution to this six year old problem, and I want a solution that I will be able to start using within my own lifespan.

@Sergei, It's very difficult to explain you... Please understand the problem, First of all Team B does not want to use SNAPSHOT and want to use only release version of A. Whenever team A release incremental version it should picked up by team B without changing anything. But this is very common that team A is also adding new feature and creating SNAPSHOT version before release. In between if team B also working on their app and at that time they will get SNAPSHOT... this is very common situation please understand it.

You two CI model is going to work as it's more work we need to do so please leave that option.

@Sergei, what do you mean by "Are you concerned about the way it is going to be handled in IDEs? I personally don't see that being a problem, although IDE vendors may need to implement the equivalent of a command line option for embedded Maven engines."

Are you saying IDE vendors need to change their implementation?

@Joniec

To your first comment.
I know it may be difficult to explain, that is why I am asking for detailed examples or use cases, so that we all can be sure we understand the problem in the same way.
If team B never wants to pick up snapshots of team A, then this problem can be solved pretty easily without changing Maven a bit. All they need to do is to segregate their repositories (which is generally not a bad idea anyway):
1. Team A sets up separate release and snapshot repositories for their artifacts.
2. Team B sets up a repository group for themselves that only includes the release repo of team A.
This way, team B will only ever see the released versions of artifacts from team A. Done.
As a matter of fact, both teams can even share the same release repository, it is only the snapshot repositories that need to be segregated.

To your second comment.
Yes, obviously if we are going to introduce changes into Maven, IDE vendors will have to support the new functionality eventually. Our implementation choice does not really matter here. By default, however, everything should continue to work the way it is now.

@Sergei, you are making so complicate here.... when you are working with big company it's very difficult to separate out repo team by team.... if Same team is working on different project and want SNAPSHOT version of team C thn.... and more over in same project it self if they want SNAPSHOT version of C and release version of A then this is valid use case.... We can not separate out repo team base we have common repo in entire organization one for SNAPSHOT and one for RELEASE and many company they have only one repo which contain release and SNAPSHOT...
We want to solve this problem for everyone with minimal change.

If you are saying "Yes obviously" to IDE vendors to change their implementation thn please ask them first, are they ready to change?

If we have problem in Maven feature then first we need to solve the problem in Maven without depending on other tools to support us...

Sorry, but I'm not agree with you.

Joniec,

Firstly, I do not see any point in asking IDE vendors for permission. It is their job to follow the trends and changes in the software landscape and constantly adapting to the changes. Can you imagine people from Spring or Hibernate projects begging IDE vendors for permission to make changes in their products? This would be plain silly.

Secondly, if an organisation has a complicated web of project dependencies and they are not willing to invest in a proper repository set-up and management, then they are not doing themselves any favour. I am myself working in a large organisation, and we have tens of teams, lots of projects, and we do maintain many separate Maven repositories. Suppose our team is responsible for a financial application that handles transactions worth £1bn daily, then we would want a complete control over the artifacts that we integrate from other teams, would not we?

I firmly believe that the use case you described can be (and perhaps should be) handled through proper repository set-up. If your project C depends on A:[1.0,1.1) and B:[2.3,2.4), and you do actually need to include snapshots for A, but not for B, then my proposal will not work for you with a vanilla repository set-up. In that case you will need a fine-grained resolution policy on the individual dependency level. And that does not solve the problem with releasing projects when snapshot dependencies are present. If we are forced to edit POM files before release, then what is the point in having version ranges?

Sergei, To solve this problem you are expecting IDE verndors needs to change their implementation and then everyone has to use that IDE to implement this feature..?

This is a bug and not a new feature due to which they need to change this.

Give me answer of below question...

when you want to release your SNAPSHOT what do you do?

And same artifact when you want to release without SNAPSHOT what you do?

Sergei, Suppose I have two dependency defined with version range in my project and one of them I want to use SNAPSHOT and second release, this is again valid use case because many project has on going work for many library and they need SNAPSHOT version of those.

Joniec,

We have already waited for 6 long years and this issue is still unsolved. If we have a solution that works with command line maven and can be used in CI tools, I'll be happy to wait until IDEs catch up. We have already been in such situation with incompatible changes in tools and libraries, and it's part of software evolution.

To your question. Whenever I want to release a SNAPSHOT of one of our projects, I open our Jenkins page, find the release build for the project and press a "Perform Maven Release" button. This in turn kicks off command line maven with the equivalent of mvn -B release:prepare-with-pom release:perform command, with a couple of additional options specific to our build environment.

I do not have to edit the project's POM before release, because for our release builds version ranges are resolved from release repositories only, and the release builds are configured with a separate local repo. I have already described our set-up above. All this hassle is to circumvent this very MNG-3092 and avoid unnecessary editing of POM files.

Neither do I have to constantly edit version ranges in the dependent downstream projects, save for the cases when a major release of upstream dependency is produced and the whole version range needs to be shifted.

I understand that there may be use cases where e.g. project A has version ranges for projects B and C, is happy to use snapshots of B, but only wants releases of C. In that case the project needs finer-grained control over snapshot dependencies, and this may require:

1. changes to the POM model, or
2. changes to the way ranges are defined, or
3. re-interpretation of dependency ranges (as in Kunalkumar's suggestion)

Having thought about that, perhaps we do really need to split this issue in two:

1. Have a master switch that will disable all snapshots in all ranges. Use it by default in maven-release-plugin when starting forked executions. That will solve integration and CI issues for a large group of users, including us.
2. Have a fine-grained control over inclusion of snapshots in ranges, on the level of each individual dependency. That will cover more specific cases like you are describing.

@Sergei
I realize there's a new dependency management library, I also know it flat-out does not perform, and from aether's introduction there were problems. From what I can tell, it was prematurely introduced, some bugs have been fixed, but performance with ranges bites. I don't agree about Maven2, I heavily rely on version ranges with SNAPSHOTs and have no problems, whereas Maven3 is absolutely unusable in its current form. Sure, it appears that reverting to Maven2 is going to be a lot of work, but fixing Maven3 might be more. Don't know how an issue as substantial as this was not addressed prior to the new dependency management library and related changes being released.

To make our projects work in Eclipse, developers run maven outside of Eclipse to resolve the ranges, go back into Eclipse and refresh dependencies. And when they want to get latest/greatest, they have to get a fresh pom.xml and repeat. Royal PITA. And because the m2e project insists that an embedded Maven3 is required for resolving dependencies, there's no workaround other than rewriting the plugin myself (not trivial, do not have the time), and in the meantime I'm dealing with upset developers

Without the issue being resolved soon, I don't believe I'm the only one who will need to consider options outside of Maven.

Our experience was that Maven2 resolved dependencies in a rather unpredictable way when faced a combination of version ranges, transitive dependencies with their own version ranges and dependency management. As far as I remember, the whole idea of Aether was to provide a more correct and deterministic dependency resolution for Maven3. This is not an easy undertaking, and OSGi folks (who are using version ranges a lot) faced it as well: I vaguely remember reading an article that claimed that dependency resolution in OSGi is an NP-complete task. That is, you have to trade speed for correctness.

We have never had problems with dependency resolution in Maven3, and I am not finding it much slower than Maven2, although I must admit I haven't run Maven2 for ages. Most of our in-house maven plugins require features from Maven3, thus we cannot go back to Maven2 even if we wanted to.

Another thing to mention is that we are not using Eclipse in the team. All our team members moved from Eclipse to IntelliJ IDEA simply because Maven support in Eclipse was rubbish, while everything worked out of the box in IDEA. Based on that prior experience, I still do not trust M2E, and I won't be surprised to learn that it may be introducing more problems in addition to the one we are discussing here.

@Scott, Joniec, Kunalkumar and other recent contributors to the discussion

Setting the differences aside, we have got two things in common:

1. all of us want this issue to be resolved in some way
2. none of us are Maven committers

I would like to join Scott in his plea to hear at least something from people who are responsible for pushing Maven forward. The latest comments from Jason were submitted more than 4 months ago, and nothing has been heard since. MNG-3092 probably holds a number of records: as the longest-standing, the most watched and the most voted for issue. It is frustrating to see that nothing is being done about it.

@Sergei Our experience with Maven3 and version ranges is substantially, exponentially slower - going from seconds to minutes, depending on the depth and breadth of versions involved. Straight dependency resolution with absolute version numbers appears normal.

Agree with @Sergei about Eclipse/Maven integration, I actually refuse to use Eclipse but there are some team members who live and die by it, even though IntelliJ Community Version does everything necessary - with absolutely rockin' Maven integration.

@Scott:

I have never seen dependency resolution under Maven3 taking minutes in our environment, even though we are using version ranges for internal dependencies quite extensively (both deep and wide, about 100+ internal applications/libraries in our project all in all). From what we have seen, metadata update is the real performance killer, especially if one runs Maven with -U option to force it checking for new versions in the remote repo. And with version ranges in a fluid environment we are effectively forced to use -U aggressively, otherwise we end up relying on Maven's metadata caching strategies, which introduces an element of uncertainty.

A number of times we ended up with really slow metadata update and dependency resolution. Every time we checked Nexus logs and found out that it was (a) trying to download metadata for internal artifacts from external repos (which is also pretty bad from security point of view), or (b) that some external repos got reconfigured/relocated (happened recently to Netbeans repo), or (c) that some artifacts got relocated or were not accessible anymore. Each time, after fixing repo configuration, routing rules, blacklisting/whitelisting or caching strategies we managed to bring performance of the dependency resolution back to acceptable levels.

If you have not already done so, may I suggest that you analyse the behaviour of your repo manager, and try to make sure that the metadata update checks for your artifacts are not being slowed down by unnecessarily proxying those metadata requests to e.g. Maven Central. If repo manager is not your bottleneck, then it may still be the case that you have genuinely reached the point where performance of Maven3 went downhill because of the complexity of your system.

We use Artifactory, I've looked before and saw nothing in the logs but I'll review again. Regardless, the time spent resolving via Maven2 is substantially less than through Maven3, and what I notice is that on a version range it seems to continually pull down/review all metadata rather than the latest version. For the m2e Eclipse plugin, it can cause simple projects (A depends on B depends on C) to take 45+ minutes to update.

The project dependency graph is fairly simple, no circular loops, just a simple tree (at most 4 levels deep, but mostly 2 or 3). At minimum we have 1 new snapshot per day, but often more than that, each with its own build number. I've tried deleting decently-old snapshots, but hasn't helped performance much. This shouldn't be considered too complex by any stretch of the imagination.

An example using Maven 3.0.5: https://github.com/stapler/stapler-adjunct-codemirror/commit/da995b03a1f165fef7c9d34eadb15797f58399cd shows the workaround for what I take to be this issue. In versions of Jenkins using stapler-adjunct-codemirror 1.1 prior to this change?and plugins depending on those versions of Jenkins?at least one build per day spends a chunk of time (10?20s?) looking for nonexistent SNAPSHOT versions of a transitive dependency.

(Where it gets these version numbers from, I have no idea?the Artifactory mirror makes no mention of such versions in maven-metadata.xml, and the occurrences in my local repo are all freshly created resolver-status.properties and stapler-1.176-SNAPSHOT.pom.lastUpdated files which list only ?errors? and soon get recreated if I delete them.)

Maven 2.2.1 also downloads 1.208-SNAPSHOT, which does exist, but none of these intermediate versions.

I have also encountered builds that failed trying to find one of these nonexistent snapshots, though I cannot now reproduce this problem.

@Scott:

45 minutes is clearly abnormal: it takes me about 5 minutes to refresh all our 100+ Maven3 projects configured within an uber-project in IDEA, or 10 minutes if IDEA needs to rebuild indexes. Either M2E is going around in circles and trying to resolve dependencies thousands of times, or there is something in your environment that causes massive delays.

Please make sure that your settings.xml file has a mirror section that redirects all requests to 'central' to your Artifactory instance. Otherwise Maven may attempt to fall back to looking any missing artifacts in central (it's hardcoded in Maven and cannot be switched off!). If you are behind a proxy server, these requests will be blocked, if you happen to have direct access to the internet, then you'll be hammering central with requests for your internal artifacts, which is bad news for both you (it takes considerable time and creates a security risk) and maven central (it has to handle all those unnecessary requests). Try to activate debug logging in both Artifactory and Maven/M2E and make sure it is not attempting to do any silly things.

For reference, we have got the following sections in settings.xml (all names changed to protect the innocent):

    <mirrors>
        <mirror>
            <id>internal-mirror</id>
            <name>Internal Maven repo, proxying to external repos, including central</name>
            <url>http://our-repo.fm.rbsgrp.net:8081/nexus/content/groups/public</url>
            <mirrorOf>external:*,our-artifact-releases,our-plugin-releases,!our-artifact-snapshots</mirrorOf>
        </mirror>
    </mirrors>

    <profiles>
        <profile>
            <id>our-releases</id>
            <repositories>
                <repository>
                    <id>our-artifact-releases</id>
                    <name>Our Release Repository</name>
                    <url>http://our-repo.fm.rbsgrp.net:8081/nexus/content/groups/public</url>
                    <releases>
                        <enabled>true</enabled>
                    </releases>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                </repository>
            </repositories>
            <pluginRepositories>
                <pluginRepository>
                    <id>our-plugin-releases</id>
                    <name>Our Release Repository</name>
                    <url>http://our-repo.fm.rbsgrp.net:8081/nexus/content/groups/public</url>
                    <releases>
                        <enabled>true</enabled>
                    </releases>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                </pluginRepository>
            </pluginRepositories>
        </profile>
        <profile>
            <id>our-snapshots</id>
            <repositories>
                <repository>
                    <id>our-artifact-snapshots</id>
                    <name>Our Snapshot Repository</name>
                    <url>http://our-repo.fm.rbsgrp.net:8081/nexus/content/repositories/snapshots</url>
                    <releases>
                        <enabled>false</enabled>
                    </releases>
                    <snapshots>
                        <enabled>true</enabled>
                    </snapshots>
                </repository>
            </repositories>
        </profile>
    </profiles>
    <activeProfiles>
        <activeProfile>our-releases</activeProfile>
    </activeProfiles>

Please note that the our-snapshots profile is not active by default. This is to block remote shapshots if one does not want to download them.

@Jesse:

Please keep in mind that Maven3 creates a number of maven-metadata.xml files in the local repo:

1. At groupId/artifactId level it creates a maven-metadata-<repo/mirror name>.xml file for every remote repo or a mirror that is configured in POM or settings.xml. Additionally, it creates maven-metadata-local.xml file that reflects local artifact installs.
2. At groupId/artifactId/version level it creates maven-metadata-local.xml file for local artifact installs only.

Deleting all locally cached snapshot directories under groupId/artifactId directory without updating or purging the top-level metadata files is a recipe for trouble. Stale version references in metadata files will make Maven believe that those snapshots still exist, and it will desperately try to download metadata and artifacts for the "missing" snapshot versions.

I suspect that you may have a cron job that purges snapshots from the local repo daily, but does not do it in a clean way. As a result, "one build per day spends a chunk of time" attempting to fetch these missing snapshots from elsewhere.

@Kunalkumar re: your changed maven code

• can you please share where is it?
• can we collaborate on releasing it?
• can it be incorporated in a form of "extension" (so there is no need for maven 3 re-install)?
  thank you.

@Jason

1) do you think maven should follow OSGI semantic version model more closely?
http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
that could be a base ground for maven ranges rules.

2) do you think version range resolver could be made into an extension
which could be replaced via user plugin?

thank you.

Putting the version range resolver into a user plugin sounds great. Is this feasable?

Hi all, good to see some discussion on this long-standing issue! This is not currently a pressing issue for me, hence my absence, but it's a big thorn in Maven's side that I'd love to see removed.

Re-reading the comments here, I see three main issues:

1) The original problem of not being able to control version ranges resolving to snapshots
2) How to perform CI with projects that use version ranges
3) A degradation of performance in Maven3 when resolving version ranges

The latter performance problem (3) should be raised as a separate issue if one does not exist already. I have witnessed this and doubt that there would be any objections to fixing it.

The CI problem (2) appears orthogonal to the original issue. How to build the latest versions of projects against each other in CI is a problem that currently exists without version ranges. A mechanism to support real continuous integration between project builds sounds like a separate feature request, whether they use soft versions or version ranges.

I don't buy the argument that a flag is required to change version range resolution behaviour just because updating dependency versions in POMs takes too much time. The workflow with version ranges should be the same as with soft versions (snapshot, release, snapshot), only now we're changing the upper bound instead. The release plugin helps automate this currently and there's no reason why it couldn't also help with version ranges too.

This leaves us with the original issue which I believe just needs to be fixed. I'm happy to help discuss this particular issue with the rest of the development team so we can close this long-standing bug. Satisfying everyone's particular workflow is going to be out of scope for this issue, so I'd suggest raising new issues for your specific use-cases.

@Andrei Pozolotin, I have already attached the patch in this thread.

@Mark:

The workflow with version ranges should be the same as with soft versions (snapshot, release, snapshot), only now we're changing the upper bound instead. The release plugin helps automate this currently and there's no reason why it couldn't also help with version ranges too.

I may be missing the point, but please explain to me how the release plugin is supposed to manage dependencies in downstream projects. The release plugin only does update the artifact version in the project that is being released. It does not update dependency versions in the dependent projects (unless they are modules in the same reactor) and never did. Moreover, if project A depends on a snapshot version of project B, the release plugin will fail to release project A until the dependency on B is changed to release version. One of the reasons we are using version ranges is to avoid unnecessary switching between snapshot and release dependencies through editing the POM files.

At the moment, suppose we have the following dependency chain (-> means "depends on"):
A -> B:[2.0,3.0) -> C:[1.3,1.4) -> D:[3.5,4.0)

Suppose one makes a trivial bug fix to upstream library D and wants to test its effect locally in downstream project A before releasing both D and A. At the moment, any change in D is automatically picked up by version resolution in A, as long as the snapshot version of D stays in the defined range.
If we go down the route you are suggesting, does that mean that one would need to change the whole chain of dependencies to the following, and build local snapshots of all 4 projects in the reverse order?
A -> B:[2.0-SNAPSHOT,3.0) -> C:[1.3-SHAPSHOT,1.4) -> D:[3.5-SNAPSHOT,4.0)

Suppose it is not a chain, but a graph of dependencies, which is more like we typically have in the real world. Imagine a typical developer working through the graph, updating dependency versions in POMs to snapshots along the effective dependency path? This is where blind hatred of Maven starts. And how will version resolution work if one branch of the graph allows snapshots in ranges and the other does not?

Again, I apologise if I am missing the point, but can somebody please provide an example of a detailed development and release workflow if we go down the route of explicitly specifying snapshots in version ranges.

@Mark Hobson
Glad you're also seeing performance issues. Do we have any idea in what situations we're seeing degredation? Would rather not just open an issue that says "maven slow, fix please" without any direction. I don't know enough about the aether library to know what it's trying to do or why it was integrated in. But if not, I can just open an issue.

I digged through the Maven Code last week and I'm surprised that no one has mentioned MNG-4751 in any comment of this issue.
On 8/Apr/2010, there was a change by Benjamin Bentmann with MNG-3092 in the commit comment. The change modified the Restriction-class so that SNAPSHOTS would only be allowed if a boundary contained a SNAPSHOT.
The change was reverted on 15/Sep/2010 because of MNG-4751 ("Even with a snapshot dependency in the pom, a release version is included in the classpath for compilation", if another dependency contains a version range with release-boundaries for this artifact).

I therefore think, this issues (MNG-3092) can only be solved by some kind of soft restriction. A range with release-boundary must be able to include SNAPSHOT-dependencies, but release-dependencies should have preference.

@Nils: thanks for reminding of MNG-4751. I do actually remember now that I came across that ill-fated attempt to alter version resolution behaviour a few years ago. What is of particular relevance to our current discussion here is the e-mail thread that is linked from MNG-4751. If you read through the entire e-mail discussion, you'll come across a proposed solution that is astonishingly similar to what I suggested above. Only that the original participants thought it up 2.5 years ago. And it does also look like Benjamin's proposal was driven by the same or very similar use case.
What I do like even more is a separate new ~/.m2/resolutions.xml descriptor proposed by Mark. For one thing, it fits well with the other concepts, e.g. settings or toolchains, where an alternative descriptor can be specified on mvn command line. And additionally, it solves a whole bunch of problems at once:

• there is no need to modify POM file model or introduce new semantics into version range definitions
• there is no need to modify settings.xml model
• there is no need to modify version ranges in the project POM to achieve different resolution behaviour
• complete flexibility to mix and match snapshot/release resolution behaviour for different groups of upstream dependencies
• and also (looking a bit ahead) the same file could be used to specify alternative pluggable version ordering rules for artifacts that deviate from the standard versioning pattern (cf rule definitions in versions-maven-plugin)

What do think abut this proposal:
RFP: Version Range Policy
http://mail-archives.apache.org/mod_mbox/maven-dev/201304.mbox/%3C5165A10F.50107@gmail.com%3E