geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anita kulshreshtha <a_kuls...@yahoo.com>
Subject Re: Questions about the packaging plugin
Date Fri, 31 Mar 2006 16:07:03 GMT
David J,
     Thanks. Comments inline...

--- David Jencks <david_jencks@yahoo.com> wrote:

> 
> 
> anita kulshreshtha <a_kulshre@yahoo.com> wrote: Hi
> David,
>    I have few questions related to
> geronimo-packaging-plugin:
> 1. The j2ee-server configuration has
> geronimo-gbean-deployer.car declared as a dependency
> whereas rmi-naming.car is an import. IIUC, the first
> one is a parent configuration and each additional
> parent is defined using import. Is this convention
> followed throughout? Why is it necessary to
> distinguish between the two? 
> 
> geronimo-gbean-deployer is a dependency because it
> is needed to run the packaging plugin for this plan.
>  it is definitely NOT a parent, it is not needed to
> start a geronimo server that includes the
> j2ee-server configuration.
     I see.. a lot has changed from the days of
o/a/g/Deployer etc. Now j2ee-server is the base
configuration. What is j2ee-system-experimental
configuration?

Thnaks
Anita
> 
> 2. We add all the imports/dependencies to plan.xml
> for
> constructing the classpath. This classpath is used
> to
> package the car. Sometime the classpath is also put
> in
> MANIFEST.MF (for example j2ee-system). Why is this
> not
> done for j2ee-server?
> 
> The entries in the manifest classpath are only
> needed for the "root" configurations that are used
> to boot a  server.  At present these are the
> j2ee-system and client-system (I might have
> forgotten something used for a tool, perhaps
> shutdown?)  Currently the Daemon (and subclasses
> such as ClientCommandLine) clear the dependency list
> on any configurations they boot (start first). 
> We've wanted for a long time to eliminate the need
> for the manifest classpath, and Dain has some ideas
> how to do it: basically we need to start up a "boot
> repository".  This will also let us remove a lot of
> the jars from lib.  We are putting the dependencies
> into the plan mostly so that all the plans include
> their dependencies generated from project.xml, even
> thought they aren't being used for the boot
> configurations.
> 
> 3. How is the generated plan.xml used later on? If
> we
> put the classpath in the MANIFEST.MF, do we still
> need
> to add imports and dependencies to plan.xml?
> 
> 
> No, but as noted above we are including them as
> documentation and as an inspiration to get rid of
> the need for manifest classpath.
> 
> 
> Thanks
> Anita
> 
<snip>
> thanks
> david jencks
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> http://mail.yahoo.com 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Mime
View raw message