Yeah, I too ran into the version range bug, where it would resolve to snapshots when it was not supposed to...in Maven2. It was such a big problem it forced us to not use version ranges at all in Maven2, which is unfortunate because it could have been an elegant solution.
I know jira issues were created and there were lots of discussions at that time...now that Maven3 is out...I was hoping that version ranges would be fixed but I don't know if that's the case or not...since we have worked around them I haven't looked at this issue for years now. (Apparently not if your using Maven3.) However in your case I don't think you need version ranges, can't you just specify the actual version you want to use in your depedencyManagement section? -Dave On Mon, Sep 3, 2012 at 5:31 AM, tobias maslowski <[email protected]> wrote: > Hello, > > as far as I understand your message, there are two problems. > First: > Your project C (depending on A and B) needs to resolve the transitive > ano-util artifact to version 1.0.14 instead of 1.0.8. In my experience it's > the easiest way to explicitly declare this dependency in project C. (It > makes logically sense, since it incoorperates A and B by providing the > correct version of ano-util) > If you do not want to do this, you might want to read about the > dependency-mechanisms ( > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html) > Or to put it short: in C you'll probably have declared the dependency to A > above the one to B, so the version declared in A will be considered. > > Second Problem: > In your place I would try to avoid using dependency-ranges. I dont think > you need them and it makes things far more complicated than they need to be. > But you are right, they should not resolve to a snapshot version, if you > did not configure the versions plugin to do so. If you did not do so, I'm > afraid I can't help you with this one. > > regards. > > > 2012/9/3 Leon Rosenberg <[email protected]> > >> Hello, >> >> I have two modules, say A and B, which are using the same library, one >> is using 1.0.8 and one 1.0.14: >> <dependency> >> <groupId>net.anotheria</groupId> >> <artifactId>ano-util</artifactId> >> <version>1.0.14</version> >> </dependency> >> >> A third module (a web-app) uses both A and B. After I built the third >> module, it wasn't able to start, because it had the wrong version, >> 1.0.8 in the WEB-INF/lib. The eclipse dependency analysis showed, that >> 1.0.14 was omitted in conflict with 1.0.8 (why?!). >> >> I thought ok, than i can work with ranges now. I opened the pom of >> project A and changed 1.0.8 to 1.0.14 and added a range to it, to >> prevent such problems in the future: >> <dependency> >> <groupId>net.anotheria</groupId> >> <artifactId>ano-util</artifactId> >> <version>[1.0.14,)</version> >> </dependency> >> >> After I rebuilt everything, what do you think I got? 1.0.14? No, >> 1.0.16-SNAPSHOT ???? >> >> Google leads me to this page: >> >> http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges >> >> which states: >> Resolution of dependency ranges should not resolve to a snapshot >> (development version) unless it is included as an explicit boundary. >> >> So why am I getting a SNAPSHOT version? >> And how can I state that the LATEST RELEASED version is what I >> actually want as conflict resolution scenario (isn't it self-evident >> actually??). >> >> regards >> Leon >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
