Re: car-maven-plugin and true

[David Jencks <da...@yahoo.com>]

I've now got most of the server working with useTransitiveDependencies  
turned on so I committed the work.  Its quite a large change so no  
doubt it broke a lot of stuff I don't know about.

Please let me know if you see problems.  In particular for some reason  
I'm not getting reasonable results out of testsuite..... I get only  
failures and hangs according to the console but the reports appear to  
indicate passes.

I also more or less accidently commited a change to  
MultiParentClassloader so toString returns a complete description of  
what's in the classloader.... recursively.

This is rather useful in figuring out what went wrong with  
classloading problems but it might be a good idea to be able to turn  
it off by default.  Comments appreciated.

thanks
david jencks

On Aug 19, 2008, at 12:46 PM, David Jencks wrote:

>
> 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.
>
> thanks
> david jencks
>
>>
>>
>> Jarek
>>
>> On Thu, Aug 14, 2008 at 7:45 PM, David Jencks  
>> <da...@yahoo.com> 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 <david_jencks@yahoo.com 
>>>>> >
>>>>> 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
>>> https://issues.apache.org/jira/browse/GERONIMO-4248.  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
>>>>
>>>
>>>
>