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]
