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,
Paul
