Re: Questions about the packaging plugin

Dain Sundstrom Wed, 05 Apr 2006 13:12:48 -0700

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 itplanned for ?


Cheers
Prasad

On 4/5/06, Dain Sundstrom <[EMAIL PROTECTED]> 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 branch1.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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:

David J,
     Thanks. Comments inline...

--- David Jencks <[EMAIL PROTECTED]> wrote:



anita kulshreshtha <[EMAIL PROTECTED]> 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

Reply via email to