Re: car plugin changes... geronimo-plugin.xml, etc.

Sat, 12 Aug 2006 13:36:47 -0700 

Can you point me at the build for one of these external plugins?

--jason


On Aug 12, 2006, at 8:05 AM, Aaron Mulder wrote:


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.executeGoalWithLi fecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(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
>
>
>

Reply via email to