cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@apache.org>
Subject Re: [RANT] This Maven thing is killing us....
Date Wed, 05 Jul 2006 15:04:32 GMT
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.


Mime
View raw message