On 2/24/19 9:27 PM, Karl Heinz Marbaise wrote:
Hi Florian,
On 24.02.19 21:04, Florian Schmaus wrote:
Assume a project which declares a dependency on libFoo version 1.0.0,
now libFoo also declares a dependency on libBar using a dynamic
version specifier [1.0, 2.0).
Now what I expect to happen is that Maven pulls in any, ideally the
latest available release, libBar 1.0 version artifact. What actually
happens is that Maven pulls in libBar 2.0-alpha5, which causes
dynamic linking issues. Gradle, OTOH, pulls in libBar 1.3 when it is
used to build the project.
I have created an example project, using the actual artifacts I
experience this issue with, to demonstrate the different behavior
between Maven and Gradle:
https://github.com/Flowdalic/maven-transitive-dynamic-dependency
The example project is configured to depend on Smack, an FOSS XMPP
client library, version 4.3.2. This Smack version declares jxmpp
[0.6, 0.7) as a dependency.
$ mvn exec:java
…
Smack version: 4.3.2 (4.3.2-4.3 2019-02-22)
jxmpp version: 0.7.0-alpha5
ERROR: jxmpp version does not start with '0.6' as expected. :(
maven-transitive-dynamic-dependency (master)$
~/tools/jdk8u202-b08/Contents/Home/bin/java -jar
~/tools/apache-maven-3.6.0/lib/maven-artifact-3.6.0.jar 0.7 0.7.0-alpha7
Display parameters as parsed by Maven (in canonical form) and
comparison result:
1. 0.7 == 0.7
0.7 > 0.7.0-alpha7
2. 0.7.0-alpha7 == 0.7-alpha-7
That is based on the behaviour in ComparableVersion which handles non
GA as before the final release which is exactly here the case.
Thanks for your reply. I also found
https://issues.apache.org/jira/browse/MNG-6232
which is what am I running into (the issue title could be more precise).
You probably don't have to change the behavior if there is a way to
specify all versions of a version series *without* pulling in
alpha/beta/… releases of the following version (Which is probably the
intention of all people running into MNG-6232).
Is there such a way?
I could possibly workaround that using something like
[0.6, 0.6.1000]
but that does not look very elegant… :(
- Florian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
