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 Wed, 05 Apr 2006 15:47:19 GMT
David J,
     o.a.g.system.repository.ReadOnlyRepository has a method
 'public boolean hasURI(URI uri)', which is maven version dependent.
Should I try to change it so that it works on both versions, i.e. m1
and m2? How is the implementation defined in the packaging plugin
'public class MavenRepository implements Repository' being used?

Thanks
Anita

--- anita kulshreshtha <a_kulshre@yahoo.com> wrote:

> David,
>    I am encountering a strange problem probably
> because I am doing something wrong. When I add
> commons-logging to the urls used for constructing the
> classloader for PackageBuilder. I get error :
>
----------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO]
>
----------------------------------------------------------------------------
> [INFO] null
> Invalid class loader hierarchy.  You have more than
> one version of 'org.apache.commons.logging.Log'
> visible, which is not allowed.
> 
>     If I do not add it I get this error :
> 
> [INFO]
>
----------------------------------------------------------------------------
> [ERROR] FATAL ERROR
> [INFO]
>
----------------------------------------------------------------------------
> [INFO] org/apache/commons/logging/LogFactory
> [INFO]
>
----------------------------------------------------------------------------
> [INFO] Trace
> java.lang.NoClassDefFoundError:
> org/apache/commons/logging/LogFactory
>         at
>
org.apache.geronimo.plugin.packaging.PackageBuilder.<clinit>(PackageBuilder.java:49)
>         at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>         at
>
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:
>    What is this due to?
> 
> Thanks
> Anita
> 
> --- anita kulshreshtha <a_kulshre@yahoo.com> wrote:
> 
> > 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 
> > 
> 
> 
> __________________________________________________
> 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