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 Wed, 10 Oct 2007 19:32:22 GMT

On Oct 10, 2007, at 9:51 AM, Paul McMahan wrote:

> On Oct 10, 2007, at 11:50 AM, David Jencks wrote:
>>> <project>
>>>     <artifactId>plugin1</artifactId>
>>>     <dependencies>
>>>            // a reference to plugin2 is not desirable here, don't
>>>            // want maven processing it as a build time dep or
>>>            // including its classes in the environment inherited
>>>            // by car-maven-plugin
>>>     </dependencies>
>>>     <build>
>>>         <plugin>
>>>                 <artifactId>car-maven-plugin</artifactId>
>>>                 <configuration>
>>>                         <dependency>
>>>                               <artifactId>plugin2</artifactId>
>>>                               <import>service</import>
>>>                         </dependency>
>>>                 </configuration>
>>>         </plugin>
>>>     </build>
>>> </project
>> #0 is necessary to help maven build the modules in a correct  
>> order.  I believe we have successfully written the c-m-p so the  
>> maven dependencies have no effect on the c-m-p environment, only  
>> on the configuration that the c-m-p is "compiling" .  Basically  
>> the c-m-p fires up a small geronimo instance, and the root  
>> classloader of that geronimo instance is the root maven  
>> classloader, without any of the maven dependencies in it.  Then we  
>> load dependencies of the module we are constructing into this  
>> geronimo instance just like a standalone geronimo server does.   
>> So, the only effect these maven dependencies have is to assure  
>> build order and to contribute to the geronimo module classloader  
>> according to the rules above.
>> make sense?
> Yes, makes sense.  I didn't realize that the c-m-p was intended to  
> behave that way because of a problem I was having using  
> <import>services</import> in the c-m-p configuration section.
> When I included a reference to plugin2 in the main dependency  
> section the gbean deployer invoked by the c-m-p was still trying to  
> include plugin2's dependencies even though I overrode that  
> dependency with <import>services</import> in the c-m-p's  
> configuration section (like shown above).   That might actually be  
> a problem with the kernel's handling of service type deps though  
> and it just surfaced to me through the c-m-p.

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?

david jencks

> Best wishes,
> Paul

View raw message