geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <>
Subject Re: car-maven-plugin and <useTransitiveDependencies>true</useTransitiveDependencies>
Date Tue, 19 Aug 2008 19:27:23 GMT

I'm confused about something. Let's take framework/configs/j2ee-system
as an example. Its pom.xml defines a dependency on:


The pom.xml of slf4j-log4j12 defines dependencies on slf4j-api and
log4j. Now, the generated geronimo-plugin.xml has a dependency on
slf4j-log4j12 but it's missing slf4j-api and log4j dependencies. That
does not seem right or I'm missing something.


On Thu, Aug 14, 2008 at 7:45 PM, David Jencks <> wrote:
> On Aug 13, 2008, at 3:16 PM, David Jencks wrote:
>> On Aug 13, 2008, at 12:57 PM, Jarek Gawor wrote:
>>> On Wed, Aug 13, 2008 at 2:23 AM, David Jencks <>
>>> wrote:
>>>> I'm suggesting 2 things:
>>>> 1. fix our dependencies so they are correct.  This, by itself, will make
>>>> useTransitiveDependencies=true work properly.  Any problems such as
>>>> unwanted
>>>> inclusions are bugs that have a good chance of producing highly
>>>> undesirable
>>>> behavior in maven if they haven't already done so.
>>>> 2. make the build-time classpath match the run-time classpath by using
>>>> the
>>>> cars to aggregate their dependencies in maven, just like they do in the
>>>> running geronimo server.  This should dramatically reduce the number of
>>>> dependencies in most of the plugin poms.
>>> I agree that we should fix our DM so that build-time classpath matches
>>> the run-time classpath, however, the reality is that no one really
>>> maintains the DM. Things get very quickly out of date and we might end
>>> up pulling in stuff into server that we don't really need. My guess is
>>> that if we go ahead with the transitive dependencies a few days before
>>> the next release somebody will realize that the DM is messed up and
>>> try to fix it which will cause build or maybe even runtime errors. The
>>> point is that if we go ahead with the transitive deps we must pay much
>>> better attention to the DM and/or have better tools to catch the
>>> problems in the DM early.
>> I suspect that we have this kind of problems today and don't know about
>> them and also think that for the most part the reason we don't have more
>> such problems is that I've made most of the dependency changes in all the
>> plugin poms.  This is too much for me to keep doing; we need a better
>> system.  IMO relying more on maven dependencies is the first step.
>> Using maven dependency:analyze on framework modules is proving rather
>> interesting and showing up some surprises.  I think this might make the
>> module poms reasonably accurate.
>> For plugins, I had an idea that might help.  We could have a mojo in c-m-p
>> come up with a list of dependencies for the geronimo-plugin.xml and
>> optionally save it in a file which we would commit to svn.  In any case it
>> would compare the current file with the existing file and if there is a
>> difference either fail or emit a loud warning.  If you want to change the
>> output dependencies you'd have to update the file in svn.
> I've implemented this, see
>  I'm testing to see if
> the build can be done twice without failure, then will commit the history
> files or fix any problems that show up.
> What the new mojo does is like this (from the JIRA):
>    *  keeps historical dependencies in src/main/history/dependencies.xml
>    * if the file is missing, it creates it with current dependency info
>    * if the file is there, it compares with current dependency info and if
> it's changed writes out dependences.added.xml and dependencies.removed.xml
>    * by default it fails on changes, although this can be turned off.
>    * respects current useTransitiveDependencies flag setting.
> The first time it runs it can't fail.  If this causes problems we should be
> able to work around them by removing the history files with
> find . -name dependencies.xml|xargs rm
> thanks
> david jencks
>> Anyone have any other ideas?
>>> Btw, does Maven support artifact substitution? E.g. substitute
>>> commons-logging-api with jcl104-over-slf4j or javax.activation with
>>> geronimo-activation_1.1_spec, etc.?
>>> Won't this also make the DM grow overall (even if we split it among
>>> the modules)? For example, virtually every library has a dependency on
>>> commons-logging or commons-logging-api so we will need to add an
>>> exclusion to each library.
>> I don't know of such a feature
>> thanks
>> david jencks
>>> Jarek

View raw message