This is why version ranges are not a good idea if you have production
software that you need to maintain and do quick bug fixes that have a
constrained risk and require minimal testing.
If your build is not repeatable because you have not specified the
version of third party libraries, you have a big job to test even the
smallest change to a single class.
Nothing is more disruptive that a bug fix that causes a whole lot of
errors in parts of the code that was known to work, not changed but now
exhibits changed behaviour.
We do not allow version ranges and furthermore have central control over
the version of third party libraries so that it is a conscious decision
to upgrade a library.
Maven helps detect version conflicts with the dependency graph or tree.
We remove these in our library projects by "exclusion" so that unwanted
libraries are not dragged in.
Early in the development process for a new release, we settle on the
versions that will be used for all of the 70-100 3rd party libraries
that we will use either explicitly or through transitive dependency.
This is no longer a big job since we have the POMs already set up. It
took a few days to set up the 50+ (now 70+) application modules and the
10+ library modules but now it is a piece of cake to keep them current
as each new version of the application is developed.
If a new version of a third party library is required to support new
development or fix a bug, we make the change explicitly and do an impact
analysis to ensure that the testing is appropriate and deals with the
possibility that the new version of the library may have consequences
outside the actual code that we are changing.
We merely have to look at the modules with exclusions on this library to
identify where it is used through transitive dependency.
Ron
On 13/04/2011 8:17 AM, Julien HENRY wrote:
Hi,
This problem is not specific to Maven, but this is a Java issue.
Running javac on P with -classpath=A.jar, B.jar, X-2.0.jar, X-1.0.jar will not
work nor -classpath=A.jar, B.jar, X-1.0.jar, X-2.0.jar
If you want to be able to use two versions of the same class side by side... you
have to rename package/or class name (eg: com.acme.x1.TheClass and
com.acme.x2.TheClass).
Translated to Maven it means you will have different artifacts: com.acme:X:1.0
and com.acme:X2:1.0.
P -> A -> X2 1.0
-> B -> X 1.0
This is how it works in Linux distributions with packages management. As long as
a package is a replacement for another you can simply change version. But if you
want to keep ability to use two artifacts at the same time => change
artifactId.
Here is an example from my distrib:
S | Name | Type | Version | Arch | Repo
--+----------------------+--------+--------------+--------+------------------
| libdb_java-4_5 | paquet | 4.5.20-108.2 | x86_64 | openSUSE-11.4-Oss
| libdb_java-4_8 | paquet | 4.8.30-2.2 | x86_64 | openSUSE-11.4-Oss
My advice is to avoid this situation as it leads to a big mess. In some
situation you may want to use maven-shade-plugin as a workaround [1].
Regards,
Julien
[1]
http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html
----- Message d'origine ----
De : Tom Eugelink<[email protected]>
À : Maven Users List<[email protected]>
Envoyé le : Mer 13 avril 2011, 13h 56min 06s
Objet : Re: breaking backwards compatibility
It is hard to make it clearer; suppose a version 2.0 of some library X got
all @deprecated methods from 1.0 removed. A clean up. The project could have
two dependencies that both refer to this library:
P -> A -> X 2.0
-> B -> X 1.0
If this is resolved, then indeed X 2.0 is included, however B expects the 1.0
version and may be using a @deprecated method that is no longer present. The
end project will crash.
Is it possible to tell Maven that 2.0 is not a substitute for 1.0?
On 13-4-2011 13:42, Benson Margulies wrote:
There is perhaps a communications problem here. I don't think this is
about ranges. I suspect that it is about:
- project g:A version 1 depends on x:y:2.0
- project g:B version 1 depends on g:A:1 and x:y:1.0
What ends up in the classpath of B? x:y:2.0, I think.
On Wed, Apr 13, 2011 at 7:17 AM, Schrecker, Wolfgang
<[email protected]> wrote:
Maybe http://maven.apache.org/enforcer/enforcer-rules/index.html
could help.
Wolfgang
-----Ursprüngliche Nachricht-----
Von: Jörg Schaible [mailto:[email protected]]
Gesendet: Mittwoch, 13. April 2011 11:55
An: [email protected]
Betreff: Re: breaking backwards compatibility
Hi Tom,
Tom Eugelink wrote:
I know Maven version management can be, ah, challenging, so I stick to
Maven compatible versioning. Maybe not to the deepest level
(1.0.0-b01),
but surely in a very common accepted style (1.0). I am not having any
problems with Maven using the wrong versions.
My question is with how to tell Maven two releases are no longer
compatible. So if one dependency uses 1.x and the other uses 2.x, and 2.x
is "declared" not backwards compatible to 1.x, then Maven should either:
1. report a build error on a version conflict 2. or include both versions
of the artifact.
What means "not compatible" for a single artifact? If my application only
uses a constant defined in some class, the dependency is only
incompatible
if this constant is no longer available, has a different type or a value
that causes a failure situation in my own app.
You can define real incompatibility only from the consumer side. So what
could Maven actually report by default?
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--------------------------------------------------
Atos Worldline GmbH
Hahnstraße 25
60528 Frankfurt/Main
Germany
Phone: +49 69/6657-1176
Fax:
Mobile:
mailto: [email protected]
http://www.atosworldline.com
Geschäftsführer: Wolf Kunisch
Aufsichtsratsvorsitzender: Didier Dhennin
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister: Frankfurt/Main HRB 40 417
* * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
This e-mail and the documents attached are confidential and intended solely
for the addressee; it may also be privileged. If you receive this e-mail by
error, please notify the sender immediately and destroy it. As its integrity
cannot be secured on the internet, the Atos Origin group liability cannot be
triggered for the message content. Although the sender endeavours to maintain a
computer virus-free network, the sender does not warrant that this transmission
is virus-free and shall not be liable for any damages resulting from any virus
transmitted.
* * * * * * * * L E G A L D I S C L A I M E R * * * * * * * *
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
*Tom Eugelink*
Senior software engineer
+31 (0)6 - 47 93 85 92
[email protected]<mailto:[email protected]>
*KnowledgePlaza<http://www.knowledgeplaza.nl>*
Sutton 15
7327 AB Apeldoorn
Tel: +31 (0)55 - 526 3887
Fax: +31 (0)55 - 526 3950
[email protected]<mailto:[email protected]>
Disclaimer: The information contained in this message is for the intended
addressee only and may contain confidential and/or privileged information. If
you are not the intended addressee, please delete this message and notify the
sender; do not copy or distribute this message or disclose its contents to
anyone.
---------------------------------------------------------------------
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]
