Steve Loughran wrote:
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.
This still sounds like I have to have modified versions of poms at ibiblio.
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"
At least with maven 1 we can control this with maven.jar.override. This
capability has been removed in Maven 2.
Maven2 says "libraries pull in what they were built against, unless
you say otherwise"
Which is OK, if you have a rational way to say otherwise. The
"rational" way is to have a global list of the versions you want to use
wherever they appear in the build. This can actually be a good feature
as Maven could generate warnings when a transitive dependency is greater
than the one declared. It also doesn't require that you actually know
where they are used which aids in simplicity.
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.
I would suggest that if you have a POM where you can exclude something
and it still works has a problem. It is nice that Maven lets you bypass
it, but you should take that up with the author of the POM.
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
Well, I suppose if it works for you... but that seems like an awful lot
of work to create a usable build system.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
