Another issue...
When I run the car-maven-plugin on an external plugin, the execution
fails because the internal deployment can't resolve a dependency (say,
geronimo-security). This can't be listed as a dependency in the POM
because we don't want it to be written into the target plan. But it
has to be in the M2 repository for the car-maven-plugin to work.
My solution so far is to add a bunch of extraneous dependencies to the
module that builds the service JAR in the first place, where the
plugin module is separate and builds a plugin out of the service JAR.
The problem is, there are a *lot* of these dependencies. For a simple
service plugin that depends only on geronimo-gbean-deployer being
listed for the car-maven-plugin, I've run into these and I'm still
going (you disover them one build failure at a time):
- geronimo-core
- geronimo-transaction
- geronimo-security
- geronimo-util
- geronimo-webservices
- howl-logger
I don't know what the right way to do this is, but I'd really like it
if something under the covers caused all the necessary dependencies to
be downloaded so I don't have to clutter up my build with all this
stuff. (web services?!?) I'm tempted to create a dummy build with
all these dependencies that you run once just to suck all the stuff
into your repo and I can leave it out of my real build.
Thanks,
Aaron
On 8/12/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
Uh-oh.
I updated and tried to build just the car-maven-plugin and it failed
with a compile error.
So I ran a full "./build" and it failed with a test error -- some
TransactionContextManager test which I would have thought was
obsolete.
Anyway, I ran a "./build -Dmaven.test.skip=true" and it got further,
but failed in the first config, which I expect means something isn't
quite right with the car-maven-plugin. Results below. It seems to
fail on building the GBean deployer, complaining that the GBean
deployer already exists.
Thanks,
Aaron
[INFO]
----------------------------------------------------------------------------
[INFO] Building Geronimo :: Configs
[INFO] task-segment: [install]
[INFO]
----------------------------------------------------------------------------
[INFO] [site:attach-descriptor]
[INFO] [install:install]
[INFO] Installing /data/cvs/geronimo/configs/pom.xml to
/home/ammulder/.m2/repository/org/apache/geronimo/configs/configs/1.2-SNAPSHOT/configs-1.2-SNAPSHOT.pom
[INFO]
----------------------------------------------------------------------------
[INFO] Building Geronimo Configs :: GBean Deployer
[INFO] task-segment: [install]
[INFO]
----------------------------------------------------------------------------
...
[INFO] [car:prepare-plan]
[INFO] Generated: /data/cvs/geronimo/configs/geronimo-gbean-deployer/target/plan
[INFO] [car:package]
Packaging configuration
/data/cvs/geronimo/configs/geronimo-gbean-deployer/target/plan/plan.xml
ERROR [PackageBuilder] org.apache.geronimo.common.DeploymentException:
Module org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car
already exists in the server. Try to undeploy it first or use the
redeploy command.
org.apache.geronimo.common.DeploymentException: Module
org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car
already exists in the server. Try to undeploy it first or use the
redeploy command.
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:254)
at
org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke(<generated>)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852)
at
org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239)
at
org.apache.geronimo.plugin.car.PackageBuilder.invokeDeployer(PackageBuilder.java:510)
at
org.apache.geronimo.plugin.car.PackageBuilder.execute(PackageBuilder.java:346)
at
org.apache.geronimo.plugin.car.PackageMojo.executePackageBuilderShell(PackageMojo.java:253)
at
org.apache.geronimo.plugin.car.PackageMojo.doExecute(PackageMojo.java:182)
at org.apache.geronimo.plugin.MojoSupport.execute(MojoSupport.java:42)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
09:59:15,785 ERROR [PackageBuilder]
org.apache.geronimo.common.DeploymentException: Module
org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car
already exists in the server. Try to undeploy it first or use the
redeploy command.
On 8/12/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
> I've just finished committing changes that should (I hope) bring back
> the functionality needed to include geronimo-plugin.xml... someone
> please validate that it works as desired.
>
> Maven is now responsible for making the car archives now... the car
> plugin will always spit out into a local repo and then the
> PackageMojo will create an archive out of it using the m2 archiver
> bits, which allows flexible manifest entries... blah blah.
>
> geronimo-plugin.xml is still being filtered using the resources
> plugin... and really anything you drop into src/main/resources will
> be included into the car, and filtering is controlled by the default
> m2 bits in your pom.
>
> Plan files have been updated to use ${pom.version} instead of $
> {pom.currentVersion}... ${pom} is actually the project reference,
> which is closer to what it would be if filtered by resources (which
> we will eventually get to, and drop velocity).
>
> Car files now all have LICENSE.txt and NOTICE.txt included (side-
> effect of using Maven's mech to pick up resources), blah blah
>
> The addition of the startup-jar is no longer hidden... its just
> another resources in src/main/resources.
>
> I also updated the PackageBuilder to take a list of classpath
> elements (that are artifacts, like the dependency plugin) which
> allows for customization of the prefix added to the entry in the
> manifest, which was needed to get lib/endorsed bits (the m2 archiver
> only allows one prefix per set). Right now the list is non-
> transitive... I could not figure how to get that working... need to
> ping the peeps in #maven for help. I will be pruning the list of
> properties we have in the root pom to manage versions, which are
> mostly unused now.
>
> There is still some more dependency clean up that needs to be done,
> but the servers are starting fine.
>
> Please take a moment and check for any strangeness and lemme know if
> you find anything.
>
> May still be a bit more work to get the multiple car muck working...
> but until I have something that is actually using the plugin that I
> can peek at I can't really fix it.
>
> I left the Deployer code asis... though my hunch is that some of this
> is not needed (the jar and manifest bits primarily)... and if someone
> knows if we use those bits anywhere else please speak up, else we
> should drop the unused bits.
>
> --jason
>
>
>
