geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Questions about the packaging plugin
Date Wed, 05 Apr 2006 19:07:32 GMT
Branch 1.1 uses the m2 repository layout for the main geronimo  
repository, so you could grab the code from there.  I personally  
would perfer if we could let this problem sit until we merge branch  
1.1 into HEAD, since we made major changes to this code in branch 1.1.

-dain

On Apr 5, 2006, at 8:47 AM, anita kulshreshtha wrote:

> 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