You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by anita kulshreshtha <a_...@yahoo.com> on 2006/04/03 15:33:30 UTC
Re: Questions about the packaging plugin
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_...@yahoo.com> wrote:
> David J,
> Thanks. Comments inline...
>
> --- David Jencks <da...@yahoo.com> wrote:
>
> >
> >
> > anita kulshreshtha <a_...@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
Re: Questions about the packaging plugin
Posted by Dain Sundstrom <da...@iq80.com>.
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 <da...@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_...@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_...@yahoo.com> wrote:
>>>>
>>>>> David J,
>>>>> Thanks. Comments inline...
>>>>>
>>>>> --- David Jencks <da...@yahoo.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> anita kulshreshtha <a_...@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
>>
>>
Re: Questions about the packaging plugin
Posted by Prasad Kashyap <go...@gmail.com>.
The assembly plugin is waiting for the merge too. When is it planned for ?
Cheers
Prasad
On 4/5/06, Dain Sundstrom <da...@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_...@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_...@yahoo.com> wrote:
> >>
> >>> David J,
> >>> Thanks. Comments inline...
> >>>
> >>> --- David Jencks <da...@yahoo.com> wrote:
> >>>
> >>>>
> >>>>
> >>>> anita kulshreshtha <a_...@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
>
>
Re: Questions about the packaging plugin
Posted by anita kulshreshtha <a_...@yahoo.com>.
David and Jacek,
This is from an earlier mail. I am attaching the output produced by
m2 packaging plugin for configs/j2ee-system. I am adding
commons-logging as one of the urls in the builderClassPath at the
following line of PackageBuilderShell -
classLoader = new URLClassLoader(builderClassPath, ClassLoader
.getSystemClassLoader());
}
return classLoader.loadClass(PackageBuilder.class.getName())
.newInstance();
The PackageBuilder code is unchanged. I know once I get past this
line, it will scream about repo etc. At this point somehow more than
one version of commons-logging is visible. The tranql and axion seem to
be using another version as indicated by
tranql:tranql:jar:1.2.2 (selected for runtime)
[DEBUG] commons-logging:commons-logging:jar:1.0.3 (removed -
nearer found: 1.0.4)
[DEBUG] axion:axion:jar:1.0-M3-dev (selected for runtime)
[DEBUG] commons-logging:commons-logging:jar:1.0 (removed -
nearer found: 1.0.4)
M2 has removed the other versions. What does this remove mean? Why
is it still visible? David, Since you have been dealing with this code
recently, I thought I could ask this question now.
Thanks
Anita
> 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?
>
................
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Questions about the packaging plugin
Posted by Prasad Kashyap <go...@gmail.com>.
I have used the "provided" scope in almost all the application poms.
The scope prevents from bundling all dependencies jars from the pom
into app's WEB-INF/lib. Only those jars that are really needed to be
bundled are explictly specified in the pom with no scope element set.
Cheers
Prasad
On 4/9/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> On 4/6/06, anita kulshreshtha <a_...@yahoo.com> wrote:
> > Dain,
> > Thanks! I need to sort out the dependencies anyway. IIUC, currently
> > we are including the dependencies referenced by the plans, i.e. the
> > ones needed by GBeans. We are including few extra ones. The maven
> > transitive dependency list is very large compared to what we add
> > currently. I think we should only add the dependencies needed for the
> > GBeans.For example if we have a GBean :
> > <gbean name="ConfigurationManager"
> > class="org.apache.geronimo.kernel.config.EditableConfigurationManagerImpl">
> > we should add geronimo-kernel as a dependency.
>
> Hi,
>
> I don't know whether it works or not, but I've come up with a weird
> idea. I've been struggling with it for a while and since I could not
> yet test it out I'll describe it here.
>
> The idea boils down to using the scope - provided - for all our
> modules' dependencies. I do mean 'all'. As transitive dependency
> mechanism doesn't apply in this case (when the scope is 'provided'),
> it sets up Maven2 not to download other transitive dependencies and it
> *might* mimic the work of M1 that only downloads the dependencies
> listed in the pom (project.xml). We could list all of the dependencies
> in the parent pom as compile (default) and override some in the
> modules.
>
> The caveat is that we will likely duplicate/do the work Maven2 could
> do for us, i.e. maintain the transitive dependencies, but once we have
> migrated to M2, we could think about it again how to work it out. It's
> a kind of a workaround to finish the migration.
>
> Does it really seem to be 'weird'? Could it work?
>
> > Anita
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.org.pl
>
Re: Questions about the packaging plugin
Posted by anita kulshreshtha <a_...@yahoo.com>.
Jacek, and others
I have been thinking about what to include in the plan.xmls that
will provide an overview of the dependencies needed by a configuration.
Earlier I was leaning towards only listing the direct dependencies, but
that would not be a great documentation! For example in system
configuration in addition to listing
1. geronimo-kernel,
2. geronimo-system, and
3. geronimo-common
we should also list mx4j, log4j, commons-logging, and cglib. Maven1
list is very close to this.
To achieve this the config's pom.xml would only include 1, 2, 3. If
a configuration has been declared as a parent, i.e. it has
geronimo.import set in project.xml, it will be added as a dependency
with 'provided' scope. Thus the plan.xml will not include its
dependencies. If someone wanted to know what dependencies are needed by
the parent, one must look up parent's plan.xml. I will be testing this
next with j2ee-server.
The geronimo-gbean-deployer (boot) configuration is a special case.
It will not be listed as <import> in the plans (same as Maven1). To
avoid listing its dependency, it could be added as a plugin dependency.
If this is the right approach, we can proceed forward with the
conversion of the rest of the configurations. It involves following
steps:
1. Carefully prune the dependencies in the modules. I have done few and
are included in the patch.
2. A dependency of type 'car' with geronimo.import set goes to pom.xml.
3. geronimo-gbean-deployer (see configs/j2ee-system/pom.xml).
4. Add only geronimo-* dependencies from the project.xml to pom.xml.
5. Use scope as 'provided' in modules (see specs in util/pom.xml) to
avoid a dependency from appearing in a car.
I am using the above set of dependencies to construct the
classloader for packaging the car. Maven1 is using the same set. Some
of this is likely to change when we actually test the packaging with
the new repository.
I am updating the patches to accomplish this.
More comments inline..
--- Jacek Laskowski <ja...@laskowski.net.pl> wrote:
> On 4/6/06, anita kulshreshtha <a_...@yahoo.com> wrote:
> > Dain,
> > Thanks! I need to sort out the dependencies anyway. IIUC,
> currently
> > we are including the dependencies referenced by the plans, i.e. the
> > ones needed by GBeans. We are including few extra ones. The maven
> > transitive dependency list is very large compared to what we add
> > currently. I think we should only add the dependencies needed for
> the
> > GBeans.For example if we have a GBean :
> > <gbean name="ConfigurationManager"
> >
>
class="org.apache.geronimo.kernel.config.EditableConfigurationManagerImpl">
> > we should add geronimo-kernel as a dependency.
>
> Hi,
>
> I don't know whether it works or not, but I've come up with a weird
> idea. I've been struggling with it for a while and since I could not
> yet test it out I'll describe it here.
>
> The idea boils down to using the scope - provided - for all our
> modules' dependencies. I do mean 'all'. As transitive dependency
> mechanism doesn't apply in this case (when the scope is 'provided'),
> it sets up Maven2 not to download other transitive dependencies and
> it
> *might* mimic the work of M1 that only downloads the dependencies
> listed in the pom (project.xml). We could list all of the
> dependencies
> in the parent pom as compile (default) and override some in the
> modules.
>
> The caveat is that we will likely duplicate/do the work Maven2 could
> do for us, i.e. maintain the transitive dependencies, but once we
> have
> migrated to M2, we could think about it again how to work it out.
> It's
> a kind of a workaround to finish the migration.
>
> Does it really seem to be 'weird'? Could it work?
This should work too. Since we are waiting for the repo, we could
spend some time pruning the dependencies in the modules. We can start
converting the configs as described above and make sure that the
dependency list from m1 and m2 is same. If needed I can submit the
patch to display the list used in m1.
Thanks
Anita
>
> > Anita
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.org.pl
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Questions about the packaging plugin
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 4/6/06, anita kulshreshtha <a_...@yahoo.com> wrote:
> Dain,
> Thanks! I need to sort out the dependencies anyway. IIUC, currently
> we are including the dependencies referenced by the plans, i.e. the
> ones needed by GBeans. We are including few extra ones. The maven
> transitive dependency list is very large compared to what we add
> currently. I think we should only add the dependencies needed for the
> GBeans.For example if we have a GBean :
> <gbean name="ConfigurationManager"
> class="org.apache.geronimo.kernel.config.EditableConfigurationManagerImpl">
> we should add geronimo-kernel as a dependency.
Hi,
I don't know whether it works or not, but I've come up with a weird
idea. I've been struggling with it for a while and since I could not
yet test it out I'll describe it here.
The idea boils down to using the scope - provided - for all our
modules' dependencies. I do mean 'all'. As transitive dependency
mechanism doesn't apply in this case (when the scope is 'provided'),
it sets up Maven2 not to download other transitive dependencies and it
*might* mimic the work of M1 that only downloads the dependencies
listed in the pom (project.xml). We could list all of the dependencies
in the parent pom as compile (default) and override some in the
modules.
The caveat is that we will likely duplicate/do the work Maven2 could
do for us, i.e. maintain the transitive dependencies, but once we have
migrated to M2, we could think about it again how to work it out. It's
a kind of a workaround to finish the migration.
Does it really seem to be 'weird'? Could it work?
> Anita
Jacek
--
Jacek Laskowski
http://www.laskowski.org.pl
Re: Questions about the packaging plugin
Posted by anita kulshreshtha <a_...@yahoo.com>.
Dain,
Thanks! I need to sort out the dependencies anyway. IIUC, currently
we are including the dependencies referenced by the plans, i.e. the
ones needed by GBeans. We are including few extra ones. The maven
transitive dependency list is very large compared to what we add
currently. I think we should only add the dependencies needed for the
GBeans.For example if we have a GBean :
<gbean name="ConfigurationManager"
class="org.apache.geronimo.kernel.config.EditableConfigurationManagerImpl">
we should add geronimo-kernel as a dependency.
Thanks
Anita
--- Dain Sundstrom <da...@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_...@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_...@yahoo.com> wrote:
> >>
> >>> David J,
> >>> Thanks. Comments inline...
> >>>
> >>> --- David Jencks <da...@yahoo.com> wrote:
> >>>
> >>>>
> >>>>
> >>>> anita kulshreshtha <a_...@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
> >>
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Questions about the packaging plugin
Posted by Dain Sundstrom <da...@iq80.com>.
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_...@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_...@yahoo.com> wrote:
>>
>>> David J,
>>> Thanks. Comments inline...
>>>
>>> --- David Jencks <da...@yahoo.com> wrote:
>>>
>>>>
>>>>
>>>> anita kulshreshtha <a_...@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
Re: Questions about the packaging plugin
Posted by anita kulshreshtha <a_...@yahoo.com>.
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_...@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_...@yahoo.com> wrote:
>
> > David J,
> > Thanks. Comments inline...
> >
> > --- David Jencks <da...@yahoo.com> wrote:
> >
> > >
> > >
> > > anita kulshreshtha <a_...@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