geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul McMahan <>
Subject Re: Make <useMavenDependencies> default true ?
Date Wed, 10 Oct 2007 16:51:19 GMT
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.

Best wishes,

View raw message