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]
