geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: car-maven-plugin and <useTransitiveDependencies>true</useTransitiveDependencies>
Date Tue, 19 Aug 2008 19:46:17 GMT

On Aug 19, 2008, at 12:27 PM, Jarek Gawor wrote:

> David,
> I'm confused about something. Let's take framework/configs/j2ee-system
> as an example. Its pom.xml defines a dependency on:
>        <dependency>
>            <groupId>org.slf4j</groupId>
>            <artifactId>slf4j-log4j12</artifactId>
>        </dependency>
> 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.

I'm working on it :-)

This is a mistake I found also.  It kinda doesn't matter at the moment  
because these dependencies are all in the manifest classpath entry  
pointing e.g. to the slf4j-api jar in lib.  If we manage to further  
trim down lib and increase boot usage of the repo it will start to  
matter a lot.

I'm working on converting framework/configs to use  
<useTransitiveDependencies>true</useTransitiveDependencies> but its  
showing up some problems with how we are computing the maven  
dependency graph.  I'm not sure yet if these are bugs in the maven  
dependency plugin or how we're trying to use or abuse it.

david jencks

> Jarek
> 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