On Oct 10, 2007, at 7:14 AM, Paul McMahan wrote:
On Oct 10, 2007, at 2:26 AM, David Jencks wrote:
0. As at present, any dependency in the c-m-p config must already
be in the pom dependencies.
1. All the (compile, runtime) scoped maven dependencies in the pom
turn into plan dependencies and geronimo-plugin.xml dependencies
2. Unless overridden the import type is "all"
3. For other import types or other customization a dependency can
be mentioned in the c-m-p config in the pom.
#1-3 look right on. I'm wondering if #0 is really necessary and
desirable. For example, if I create plugin1 that needs a service
type dependency against plugin2 then the pom could look like:
<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?
thanks
david jencks
Best wishes,
Paul
