geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Make <useMavenDependencies> default true ?
Date Thu, 11 Oct 2007 17:32:58 GMT

On Oct 11, 2007, at 10:07 AM, Prasad Kashyap wrote:

> So in summary, do we keep the lists mutually exclusive ?

You've said mutually exclusive a couple of times and I don't  
understand why.  The list of dependencies in the c-m-p configuration  
has to be a subset of the dependencies in the maven configuration.   
This is required by maven to get the build order right.  What do you  
mean by mutually exclusive?

> Paul, do you
> still see a need for a merge/override option ?

I do.
> If so, I'll slowly deprecate the <useMavenDependency> option. Since
> almost all configs have now been converted to plugins, I think it is
> time we used the maven dependencies as default anyways. The presence
> of any dependencies in the c-m-p configuration will make the c-m-p use
> those deps only and exclude all maven deps.

This is decidedly different from what I thought you proposed and what  
I thought was a good idea.  I thought you proposed always using all  
the qualifying maven dependencies (i.e. leave out provided and test,  
as at present) but modify the <import> type based on the c-m-p  

However, I don't think we should proceed with this refinement until  
all the configs are checked to be generating reasonable geronimo- 
plugin.xml files

david jencks

> Cheers
> Prasad
> On 10/10/07, Paul McMahan <> wrote:
>> On Oct 10, 2007, at 3:32 PM, David Jencks wrote:
>>> Indeed it might.  AFAIK no one has found an actual use for
>>> <import>service</import> dependencies before.... could I inquire
>>> what use you found for it and how you avoided class cast exceptions?
>> I looked into to using it to enforce module startup order.    The
>> console should startup before any console extensions because the
>> console listens for extensions being added to its navigator.  But
>> those extensions should not (necessarily) inherit the console's
>> classloader, especially since the console uses spring for configuring
>> the pluto internals.  The services dependency type didn't work as I
>> had expected while using the c-m-p so I never actually used it in a
>> server to see any class cast exceptions.
>> Best wishes,
>> Paul

View raw message