Or how about getting rid of car files, use a simple xml file and handle all of 
this muck in the server at runtime.... Optionally running a validate on the xml 
durring the build. 

--jason
  

-----Original Message-----
From: David Jencks <[EMAIL PROTECTED]>
Date: Thu, 14 Dec 2006 10:51:41 
To:"Geronimo Dev List (JIRA)" <dev@geronimo.apache.org>
Subject: Car plugin is fighting with maven too much

Ever since we got close to having an m2 build we've been having  
problems with the car plugin overloading the maven scopes to mean  
something in geronimo.  This has caused endless problems, the latest  
of which is that in order to be able to use the car plugin outside  
geronimo, you have to have built geronimo on that machine so all the  
geronimo bits you need are sure to be there.  In more detail this is  
caused by the use of the provided scope to mean "don't stick this  
dependency in the environment".  So, if you mark a builder car as  
provided so it won't get stuck in the environment, maven won't  
download all the bits it needs to run.

This is all caused by our attempt to build the environment plan  
element from the pom.  The main reason I wanted to do that was to be  
sure that if you mentioned something in the environment, maven would  
make sure it was available.  So, maybe it's time to take a more  
direct approach:

How about changing the plugin so it doesn't generate the environment  
element, but instead verifies that all the environment dependencies  
are mentioned in the pom?  Among other things this will give easier  
control over which versions are included in the environment element.

The other possible solutions to this problem I have thought of are:

-- get maven to have an extensible scope system or allow dependency  
annotations like you could do in maven 1.  I think there's no chance  
of this happening before geronimo 3, but I could be wrong.

-- copy the environment dependencies into the car plugin  
configuration.  I think this would end up being harder to deal with  
than validating the environment against the pom.

-- write a maven project that just has dependencies on all geronimo  
artifacts included in any geronimo assembly, so you can build it and  
all the bits will be around for the car plugin to use.


Thanks to gnodet for pointing out this problem and discussing  
possible solutions.

Any thoughts?

thanks
david jencks

Reply via email to