geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: car-maven-plugin and <useTransitiveDependencies>true</useTransitiveDependencies>
Date Wed, 13 Aug 2008 22:42:53 GMT

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

There doesn't seem to be such a feature but wendy smoak pointed me to  
this feature of the enforcer plugin:

http://maven.apache.org/plugins/maven-enforcer-plugin/rules/bannedDependencies.html

thanks
david jencks

>
>
> thanks
> david jencks
>
>>
>>
>> Jarek
>


Mime
View raw message