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 23:50:04 GMT
Thanks Jason, after the full build and a little IRC help, all is working now!!!

To summarize...

I finished a full build of trunk, and then the car-maven-plugin
started working for me.  The only remaining problem was that it put
too many JARs in the target plan.xml, so I put in a change to ignore
JARs with scope=provided (which it was already doing for CARs) and now
all is good!

There are two longer-term issues:

1) It's annoying that the main JAR/WAR/etc. build and the CAR build
must have different artifact names.  e.g. jetty-builder vs.
jetty-deployer.  For plugins, I'm thinking of using foo-service for
the JAR/WAR and foo for the plugin, since the name for the plugin is
what you're actually going to see when you select and install it.  I
hoped that foo/bar/1.0/jar and foo/bar/1.0/car would be different
enough, but Maven didn't necessarily agree.

2) Currently, the M2 car-maven-plugin works when used to build a
Geronimo 1.1 plugin.  I'd like to keep that capability.  Ideally, we'd
release a version of that plugin with its minimal dependencies
(geronimo-kernel, geronimo-system, etc.) so I could refer to that
specific version when building G 1.1 plugins.  Jason's offered to push
a new SNAPSHOT and I'll try that and see how it goes, but I wish we
could have a proper release.  I'm afraid that if we change some kernel
or deployer interface for 1.2, the updated car-maven-plugin may stop
working for 1.1 plugins. (I use the G 1.2 car-maven-plugin for G 1.1
plugins because they use Maven 2 builds so I can't use the G 1.1 M1
plugins.)  I think I remember in G 1.1 we had certain partial
"releases" like geronimo-kernel-123456.jar that we put out just so the
plugins could refer to them.  Does anyone know more about that?

Thanks,
     Aaron

On 8/12/06, Jason Dillon <jason@planet57.com> wrote:
> Common builds fine... but quartz is complaining:
>
> <snip>
> [INFO]
> ------------------------------------------------------------------------
> ----
> [INFO] Building Geronimo Plugin :: Quartz Scheduler
> [INFO]    task-segment: [install]
> [INFO]
> ------------------------------------------------------------------------
> ----
> [INFO] [clean:clean {execution: default}]
> [INFO] Deleting directory /Users/jason/ws/geronimo/gplugins/quartz/
> plugins/scheduler/target
> [INFO] Deleting directory /Users/jason/ws/geronimo/gplugins/quartz/
> plugins/scheduler/target/classes
> [INFO] Deleting directory /Users/jason/ws/geronimo/gplugins/quartz/
> plugins/scheduler/target/test-classes
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [car:prepare-plan]
> [INFO] Generated: /Users/jason/ws/geronimo/gplugins/quartz/plugins/
> scheduler/target/plan/plan.xml
> Downloading: http://www.ibiblio.org/maven/geronimo/poms/geronimo-
> gbean-deployer-1.1.pom
> [WARNING] Unable to get resource from repository ibiblio-maven-1
> (http://www.ibiblio.org/maven)
> Downloading: http://repo.mergere.com/maven2/geronimo/geronimo-gbean-
> deployer/1.1/geronimo-gbean-deployer-1.1.pom
> [WARNING] Unable to get resource from repository central (http://
> repo1.maven.org/maven2)
> Downloading: http://www.ibiblio.org/maven/geronimo/cars/geronimo-
> gbean-deployer-1.1.car
> [WARNING] Unable to get resource from repository ibiblio-maven-1
> (http://www.ibiblio.org/maven)
> Downloading: http://repo.mergere.com/maven2/geronimo/geronimo-gbean-
> deployer/1.1/geronimo-gbean-deployer-1.1.car
> [WARNING] Unable to get resource from repository central (http://
> repo1.maven.org/maven2)
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
>
> Missing:
> ----------
> 1) geronimo:geronimo-gbean-deployer:car:1.1
>
>    Try downloading the file manually from the project website.
>
>    Then, install it using the command:
>        mvn install:install-file -DgroupId=geronimo -
> DartifactId=geronimo-gbean-deployer \
>            -Dversion=1.1 -Dpackaging=car -Dfile=/path/to/file
>
>    Path to dependency:
>          1) gplugins:quartz-scheduler-plugin:car:0.2.1
>          2) geronimo:geronimo-gbean-deployer:car:1.1
>
> ----------
> 1 required artifact is missing.
>
> for artifact:
>    gplugins:quartz-scheduler-plugin:car:0.2.1
>
> from the specified remote repositories:
>    central (http://repo1.maven.org/maven2),
>    ibiblio-maven-1 (http://www.ibiblio.org/maven)
> </snip>
>
> Also, I notice that these are using 1.1 deps... and I have no idea
> how the 1.2-SNAPSHOT car plugin is going to like that...
>
> --jason
>
>
> On Aug 12, 2006, at 3:49 PM, Aaron Mulder wrote:
>
> > On 8/12/06, Jason Dillon <jason@planet57.com> wrote:
> >> Can you point me at the build for one of these external plugins?
> >
> > OK, first check out and build the prerequisite:
> >
> > https://svn.sourceforge.net/svnroot/gplugins/common/trunk
> >
> > Then check out and build
> >
> > https://svn.sourceforge.net/svnroot/gplugins/quartz/trunk
> >
> > There are several modules in that one, it should build base/scheduler,
> > base/deployer, and base/console (the JAR/WAR artifacts) and then
> > plugins/scheduler (the first CAR artifact which makes a CAR out of the
> > base/scheduler JAR).
> >
> > It's the plugins/scheduler build I'm testing with, which I want to
> > create a CAR file with embedded META-INF/geronimo-plugin.xml file.
> >
> > On the trunk build, I did the clean, and the build is going now.  If
> > it works, I'll look at the output for the welcome app CAR.
> >
> > Thanks,
> >     Aaron
> >
> >> 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 <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.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 <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