Couldn't you just use shade and/or uber jar to combine into a new one and depend on that?
-----Original Message----- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 7:52 AM To: Maven Developers List Subject: Re: Dep to same artifact in different versions On 26 Apr 07, at 6:05 AM 26 Apr 07, Arik Kfir wrote: > IMO, if the project claims to be backwards-compatible, then it should > include the older classes. If they can exist side-by-side, there > should be > no issue. > I don't think you can force every project to do this, and I think that users would intuitively users expect that two versions of, say, junit that are declared should show up. So what Jorg is asking for is not unreasonable and I'm really just trying to think of the repercussions of allowing multiple versions i.e. do we have any plugins keying off special versions of classes: the surefire plugin for example. I think the JMock example is perfectly valid and is something that could be addressed in 2.1 but here is my concern and generally why we took the strategy of not allowing this to begin with: The classpath order is now derived from the order of the listing of the dependencies. So in a particular project what if one case requires class C1 from version 1.0 of JMock, and another case that requires class C1 from version 2.0 of JMock? How are you going to satisfy those two conditions and in general how are you going to protect against classes that have the same name in different versions of the JAR where both are needed?. When this case arises you are going to need a form of paritioning, yes? Because you're going to end up requiring features from the new version which means using the newer classes. If you are going to need some way to say "for this group of tests use this version of JMock" and "for this other set of tests use that version of JMock" then you've gotten yourself into a case that cannot be satisfied easy. If projects could guaranteed that version N and the next major upgrade guaranteed compatibility of the intersection of classes in the different versions and additions were a superset of that then adding both versions would be fine. But this is often not the case and you get into real problems because the general rule for major version number changes is that the API can break which means that a class in 2.0 could be significantly different in API and structure then its equivalent in 1.0. In Ant you might create a separate classpath with different JARs and apply that to a different set of classes. We avoid this by simply saying, this is just too complicated and take your tests, create another module that uses the new version of JMock and be done with it. What is easier: creating a separate module which has this simple rule of allowing only one version of a dependency and using all the same patterns of every other type of Maven module. Or allow multiple versions and then start trying to rig up ways to defend against incompatibilities and partitioning sets of classes for use with a particular dependency? I think just making another module is easier. Are you sure you can defend against and cope with the two versions of JMock without any problem? Nat is a bright guy, and is probably very careful about changes between versions but lots of project are not and we decided not to allow multiple versions to protect people from less then stringent practices that generally happen in real life. We tried to make the rules for a single module simple, and make it simple to create new one. It's just so much easier for the rest of the tool chain to understand then trying to deal with the innumerable variations that occurs when multiple anything is allowed: multiple versions, multiple source trees, and multiple artifacts per unit of work which is a POM/module in Maven. That's the not so short answer, but the reason why we do what we do. I know what users expect to happen, but try to think of the counter examples where things might go wrong by using multiple versions in the same module. Jason. > I see your point, though - I just don't think it is methodology- > correct to > use different versions of the same project in one place, regardless > of the > saying that "it works", because it just doesn't seem "right" to me... > > anyway - just my 2 cents; I have no real objection for Maven to > support > declaring two dependencies of the same artifact with different > version. > > cheers, > Arik. > > On 4/26/07, Jörg Schaible <[EMAIL PROTECTED]> wrote: >> >> Grzegorz Slowikowski wrote on Thursday, April 26, 2007 10:47 AM: >> >> > Hi >> > >> > Look at hibernate2 and hibernate3 artifacts. They have >> "hibernate" and >> > "org.hibernate" >> > groupIds respectively, so they can be used together (java package >> > names are different too). >> > This is IMO the proper way to do this. >> > >> > While writing this mail I found: >> > http://jira.codehaus.org/browse/MAVENUPLOAD-1500#action_94054 >> > >> > which confirms what I have written above. >> >> You simply acknowledge that the problem exists! The fact that >> jMock will >> now switch groupId form jmock to org.jmock is exactly driven by this >> limitation. The first question I received from Nat of jMock was: >> "And what >> will happoen next time?". And I would rather think about the >> consequences >> regarding M2.1 now instead of putting my head into the sand. >> >> - Jörg >> >> --------------------------------------------------------------------- >> 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
