To be clear: You never have two artifacts in the classpath with same groupId:artifactId, maven uses the "nearer" version always, which is the one closest to your project in the transitive dependency graph, not the most recent version.
On 2/28/06, Steve Loughran <[EMAIL PROTECTED]> wrote: > Ralph Goers wrote: > > Steve, > > > > What you are proposing is to basically bypass maven and "hack" the pom's > > dynamically with the versions required. It seems to me it would be > > easier to have a process to do that in one's local repository. Then you > > only have to do it once. But then you don't have a real copy of what is > > at ibiblio. > > No. I have a properties file that lays down the dependencies for > everything in my project, like log4j, across > about 20 different sub projects. > > These have template pom files that hard code what they depend on, but > the actual version of what they depend on is driven by my > libraries.properties files. At build time, the templates are filled in > to actual pom files, files that declare what they were compiled against. > These are the pom files that are redistributed. > > > > > > > If this is truly the way it works than it certainly can't be claimed > > that Maven supports transitive dependencies as they will almost always > > have to be bypassed. For example, if project A includes myfaces 1.1.1 it > > has dependencies on beanutils 1.7.0 and digester 1.7.0. What is > > interesting is that digester 1.7.0 specifies a dependency of beanutils > > 1.6.0. Now presumably, myfaces specification will override digesters. > > But now, what if project A also specifies digester 1.7.0 as a > > dependency? You will end up with both beanutils 1.6.0 and beanutils > > 1.7.0 in your build target, which is completely unacceptable. The > > solution is for us to scour the pom's we are using and then look at > > their dependencies, etc.? I don't thnik so. Instead, everyone will be > > forced to declare all their dependencies in the parent pom. > > Well, I only really declare dependencies on things I care about, and let > the rest sort it out for themselves. If I cared about everything, then > yes, it would require things at the top to declare their versions. > > This example is slightly wrong though: you should end up with > beanutils1.7.0 on the path, but not 1.6.0. M2 doesnt give you two > versions of the same (Group,artifact), it gives you whichever is of the > highest version and hopes they are backwards compatible. Do a build in > -verbose to see what is going on. Certainly in my builds I see traces like > > [m2-libraries] Resolving dependencies... > unspecified:unspecified:jar:0.0 (selected) > xerces:xmlParserAPIs:jar:2.6.2 (selected) > xom:xom:jar:1.1 (selected) > xom:xom:jar:1.0b3 (removed - causes a cycle in the graph) > jaxen:jaxen:jar:1.1-beta-8 (selected) > jaxen:jaxen:jar:1.0-FCS (removed - causes a cycle in the graph) > jdom:jdom:jar:1.0 (selected) > xalan:xalan:jar:2.5.0 (selected) > xerces:xmlParserAPIs:jar:2.6.2 (removed - nearer found: 2.6.2) > xerces:xercesImpl:jar:2.6.2 (selected) > xalan:xalan:jar:2.7.0 (selected) > > Actually, looking that this I see that two copies of xalan appear to be > selected. not good. I will need to look at this more closely. > > > > I will admit that at the moment few folks are going to run into this > > problem because 1) most maven users are still on maven 1 and 2) most > > poms at ibiblio don't specify dependencies (I would imagine this is > > incorrect). But it only took me 5 minutes of searching to come up with > > the problem above. > > Its part of a broader problem of versioning, which, IMO, is one of the > big hard problems of computer science (nothing gets it right; at least > in java its easier to link against later builds) > > The issue here is: who declares what you run against, and how > > Maven1 and ant say "work it out for yourself" > > Maven2 says "libraries pull in what they were built against, unless you > say otherwise" > > Now, I have mixed feelings about how well it works --the primary problem > I have is not version conflict but unwanted dependencies; you ask for > one thing and before you know it you have three XML parsers and a copy > of junit3.7 on your classpath. You are left with pom overrides that > declare what you don't want. > > But is this actually worse than what went before? Different, yes, but > worse, I'd argue not. > > In smartfrog (http://smartfrog.org/) we have components that will pull > stuff into the repository. But I completely skipped the transient stuff, > partly because it was complex, and partly because I felt that at > deployment time you should be explicit, and all your dependencies can > live under SCM. Also, for security, you get to declare the sha1 or md5 > checksum, though there is a problem there once you start signing JAR > files (it changes the checksum, see) > > The result is you do have to list what you want, but you can use the > inheritance model of .sf descriptors to stop retyping things. This, for > example, is the descriptor to run axis tcpmonitor. > > sfConfig extends Compound { > > library extends Maven2Library { > } > > commons-logging extends JarArtifact { > library LAZY PARENT:library; > project "commons-logging"; > version "1.0.4"; > sha1 "f029a2aefe2b3e1517573c580f948caac31b1056"; > } > > axis extends JarArtifact { > library LAZY PARENT:library; > project "axis"; > artifact "axis"; > version "1.1"; > sha1 "edd84c96eac48d4167bca4f45e7d36dcf36cf871"; > } > > > tcpmonitor extends Java { > classname "org.apache.axis.utils.tcpmon"; > classpath [ > LAZY axis:absolutePath, > LAZY commons-logging:absolutePath]; > } > > } > > -Steve > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
