geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <ammul...@alumni.princeton.edu>
Subject Re: car plugin changes... geronimo-plugin.xml, etc.
Date Sat, 12 Aug 2006 15:05:30 GMT
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 <ammulder@alumni.princeton.edu> 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 <jason@planet57.com> 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
> >
> >
> >
>

Mime
View raw message