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 20:12:22 GMT
Once 1.1 is done we merge.

-dain

On Apr 5, 2006, at 12:49 PM, Prasad Kashyap wrote:

> The assembly plugin is waiting for the merge too. When is it  
> planned for ?
>
> Cheers
> Prasad
>
> On 4/5/06, Dain Sundstrom <dain@iq80.com> wrote:
>> 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