The assembly plugin is waiting for the merge too. When is it planned 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 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 <[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 > >
