Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of ammulder@gmail.com designates
 64.233.182.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=OWNfjluqJanSlL/W5q1WUeCKhn9aU2akGsHUbakDpXoE1n9SF24ZwGJHu+GHdrblfLeQNd42lOL3SJ5Ytth2KW2SV0XNIfzRKXH3LKfle7v7DHmLA6HdGd9WknT/dkjhyWyoVJLD/z5avw+auCkuuX1pb2fHle2T8pzlZfil6mA=
Message-ID: <74e15baa0608151504l3093b470j634f059af566812d@mail.gmail.com>
Date: Tue, 15 Aug 2006 18:04:16 -0400
From: "Aaron Mulder" <ammulder@alumni.princeton.edu>
Sender: ammulder@gmail.com
To: dev@geronimo.apache.org
Subject: Re: New car-maven-plugin issue
In-Reply-To: <8F28D3FF-25AF-43B0-8449-6D76DB02E063@planet57.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <74e15baa0608130617k7802470elcaf4771c4597389f@mail.gmail.com>
	 <8F28D3FF-25AF-43B0-8449-6D76DB02E063@planet57.com>

On 8/15/06, Jason Dillon <jason@planet57.com> wrote:
> Did you get this resolved with the jar scope == provided?

The problem with this one appears to be that the car-maven-plugin
class loader can't access JARs inside CARs, so it can't load a proper
class loader for WARs (with WEB-INF/lib/*.jar), RARs (with embedded
JARs), EARs, or service modules that were deployed with a JAR and a
plan.  This is not a problem with the online deployer (the normal
deploy tool) because the CARs it uses are unpacked, but the
car-maven-plugin gets packed CARs from the local M2 repo.

The workaround in my case was to deploy the service modules as
plan-only modules with a dependency on an external JAR.  This wasn't
my preference because it means there are more files to download when
installing the plugin, but it gets past the problem for now (since the
external JARs are not packed they can be added to the class loader
successfully).

As far as I know there really isn't a good workaround for any module
that depends on a WAR, RAR, or EAR.  For example, we may not be able
to auto-generate a plugin that adds a screen to the console, because
it depends on the console EAR.  David J had some thoughts about how to
address this (which I've forgotten, but perhaps a class loader that
silently unpacks modules to temp dirs or successfully reads
JAR-within-JAR entries).  I think Dain has talked about this kind of
this before too.  Still, no ETA.

Thanks,
     Aaron

> On Aug 13, 2006, at 6:17 AM, Aaron Mulder wrote:
>
> > So I can build Plugin A (quartz-scheduler).  But the build for Plugin
> > B (quartz-deployer) which depends on Plugin A fails to create the CAR
> > with an error like this:
> >
> > INFO]
> > ----------------------------------------------------------------------
> > --
> > [ERROR] FATAL ERROR
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> > [INFO] org.gplugins.quartz.QuartzScheduler in classloader
> > gplugins/quartz-deployer/0.3/car
> > [INFO]
> > ----------------------------------------------------------------------
> > --
> > [INFO] Trace
> > java.lang.NoClassDefFoundError: org.gplugins.quartz.QuartzScheduler in
> > classloader gplugins/quartz-deployer/0.3/car
> > ...
> >        at org.apache.geronimo.gbean.GBeanInfo.getGBeanInfo
> > (GBeanInfo.java:76)
> >        at
> > org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeanDa
> > ta(ServiceConfigBuilder.java:295)
> >        at
> > org.apache.geronimo.deployment.service.ServiceConfigBuilder.addGBeans(
> > ServiceConfigBuilder.java:290)
> >        at
> > org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfi
> > guration(ServiceConfigBuilder.java:256)
> >        at
> > org.apache.geronimo.deployment.service.ServiceConfigBuilder.buildConfi
> > guration(ServiceConfigBuilder.java:211)
> >
> > So it's saying that a quartz-deployer GBean can't find a
> > quartz-scheduler class.  Now, both the POM for quartz-deployer and the
> > plan for quartz-deployer include an entry for the quartz-scheduler
> > CAR:
> >
> > POM:
> >
> >        <dependency>
> >            <groupId>gplugins</groupId>
> >            <artifactId>quartz-scheduler</artifactId>
> >            <scope>provided</scope>
> >            <type>car</type>
> >        </dependency>
> >
> > target/plan/plan.xml:
> >
> >      <dependency>
> >        <groupId>gplugins</groupId>
> >        <artifactId>quartz-scheduler</artifactId>
> >        <type>car</type>
> >      </dependency>
> >
> > And when I deploy the quartz-deployer JAR by hand using the plan at
> > target/plan/plan.xml, then it works fine.
> >
> > What I don't understand is, how can service-config-builder not load
> > the quartz-scheduler CAR dependency and then claim that the classes
> > are missing?  If it loaded the dependency, the classes should be there
> > (e.g. it works if deployed to a real server).  If it didn't load the
> > dependency, why didn't it get a missing dependency error?
> >
> > Thanks,
> >     Aaron
>
>