Ralph Goers wrote:
Carlos Sanchez wrote:
Yes you can, it's not the best way to do it but you can, by adding
explicitly the dependency with the versoin you want to your pom. In
the very worst case you have to add all transitive deendencies to your
pom, like in Maven 1.
That is so impractical as to be nonsensical. Our Configuration
Management folks require that all projects use the same dependencies
from the top to the bottom. For example, we build our base set of
frameworks with one multiproject build, then a higher level of
frameworks, and then finally the product itself. Each of these must be
built and unit tested with the same third party jars. Furthermore, the
product can consist of a war and one or more ejb's which may all be
packaged in an ear. These must also all have all the same versions of
the jars. The solution you propose makes that tedious, error prone, and
would require our CM folks to manually inspect every pom to insure
nothing is done improperly. At least with Maven 1 we can have a
build.properties that all projects share. In our case, the ideal
solution in Maven 2 would be to have a "master" pom with nothing in it
but a dependencyManagement section (with something like override="true"
set as an attribute) that all our projects would reference.
FYI, using the maven tasks in ant, I create my own pom files based on
the values in a shared properties file. The poms are then fed in to the
tasks and used to publish the artifacts themselves. This lets me do two
things
-have a single library.properties file to control the version of things
-have developer-specific build.properties driven overrides of
versions, and know that those versions get picked up everywhere.
This isn't a perfect process, as it is fairly verbose, but it does
ensure consistency. It would be easier with a task that did both the pom
file creation and path setup in one go.
I run the tasks with verbose=true so I get to see what is happening
w.r.t dependency inference, something like this:
ready-to-declare-classpaths:
core-libraries:
unspecified:unspecified:jar:0.0 (selected)
commons-lang:commons-lang:jar:2.1 (selected)
commons-logging:commons-logging:jar:1.0.4 (selected)
log4j:log4j:jar:1.2.6 (selected)
log4j:log4j:jar:1.2.6 (removed - nearer found: 1.2.13)
log4j:log4j:jar:1.2.13 (selected)
smartfrog-modules-classpath:
unspecified:unspecified:jar:0.0 (selected)
org.smartfrog:sf-cdl:jar:3.08.steve-private (selected)
[m2:libraries] [INFO] snapshot org.ggf:cddlm:ggf16-SNAPSHOT: checking
for updates from remote
org.ggf:cddlm:jar:ggf16-SNAPSHOT (selected)
commons-logging:commons-logging-api:jar:1.0.4 (selected)
org.smartfrog:sf-xml:jar:3.08.steve-private (selected)
xerces:xmlParserAPIs:jar:2.6.2 (selected)
xerces:xercesImpl: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)
org.smartfrog:sf-www:jar:3.08.steve-private (selected)
org.smartfrog:sf-m32:jar:3.08.steve-private (selected)
commons-httpclient:commons-httpclient:jar:3.0 (selected)
commons-codec:commons-codec:jar:1.2 (selected)
servletapi:servletapi:jar:2.3 (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)
xerces:xercesImpl:jar:2.6.2 (selected)
org.smartfrog:sf-jetty:jar:3.08.steve-private (selected)
org.smartfrog:sf-loggingservices:jar:3.08.steve-private (selected)
org.smartfrog:smartfrog:jar:3.08.steve-private (selected)
log4j:log4j:jar:1.2.13 (selected)
org.smartfrog:sf-xml:jar:3.08.steve-private (selected)
smartfrog-core-classpath:
unspecified:unspecified:jar:0.0 (selected)
org.smartfrog:smartfrog:jar:3.08.steve-private (selected)
org.smartfrog:sfServices:jar:3.08.steve-private (selected)
jetty-classpath:
unspecified:unspecified:jar:0.0 (selected)
jetty:jetty:jar:4.2.24 (selected)
servletapi:servletapi:jar:2.3 (selected)
declare-compile.classpath:
declare-exec.classpath:
smartfrog-testharness-classpath:
unspecified:unspecified:jar:0.0 (selected)
org.smartfrog:sf-testharness:jar:3.08.steve-private (selected)
unspecified:unspecified:jar:0.0 (selected)
org.smartfrog:sf-testharness:jar:3.08.steve-private (selected)
junit:junit:jar:3.8.1 (selected)
Everything with steve-private is tagged as a release for me only; built
locally and never saved up to the net. I am just using the local cache
as a way of sharing artifacts.
One problem with this (ant-centric, obviously) approach is that I'm
building up multiple graphs of dependencies, and the version logic only
works in the scope of one graph, but ant lets me merge them. In an ideal
world, you'd have the ability to merge two dependency graphs and have
the resolution thing kick in again. I suppose if I had a separate pom
for each path I could do that. But this is a single artifact that goes
through some phases, like unit tests, local functional tests, then full
distributed-junit deployment of the interop test suites on four
processes at the same time, each hitting a different endpoint.
From a m2/pom perspective, a good tactic may be to create poms that
dont serve up any artifacts, just dependencies of stuff known to work
together. Like mail+attachments, the ejb3 spec+jta, or an apache-xml-api
(dom, xsl, stax apis), and an apache-xml-implementation. So you have
single poms to change the rules for these packages, and yet have bigger
things depend upon the combinations without having to relist them. That
is, using the metadata files as artifacts in their own rights.
-steve
ps, look at Xom:
xom:xom:jar:1.1 (selected)
xom:xom:jar:1.0b3 (removed - causes a cycle in the graph)
that can't be right, surely? I depend on an older version of myself.
That is something that pom validation logic should catch at pom upload
time. Here it's coming in from jaxen-1.1-beta8 that also pulls in a copy
of dom4j that I don't need.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
