Ah.. #2 in your list above hadn't registered well. Sorry. Anyways, I get it now. But I'll still answer your questions below.
Cheers Prasad On 10/11/07, David Jencks <[EMAIL PROTECTED]> wrote: > > On Oct 11, 2007, at 10:07 AM, Prasad Kashyap wrote: > > > So in summary, do we keep the lists mutually exclusive ? > > You've said mutually exclusive a couple of times and I don't > understand why. The list of dependencies in the c-m-p configuration > has to be a subset of the dependencies in the maven configuration. > This is required by maven to get the build order right. What do you > mean by mutually exclusive? Mutually exclusive is using either the maven dependencies or c-mp configuration deps but not both. This is what we have at present. The current <useMavenDep> option makes it mutually exclusive. > > > Paul, do you > > still see a need for a merge/override option ? > > I do. Now I see it. Based on #2 in your note, there is an override option. So this means we will "merge" the list from maven deps and the c-m-p. Some deps in the c-m-p may override the ones in the maven deps but the other deps will be used as is. > > > > If so, I'll slowly deprecate the <useMavenDependency> option. Since > > almost all configs have now been converted to plugins, I think it is > > time we used the maven dependencies as default anyways. The presence > > of any dependencies in the c-m-p configuration will make the c-m-p use > > those deps only and exclude all maven deps. > > This is decidedly different from what I thought you proposed and what > I thought was a good idea. I thought you proposed always using all > the qualifying maven dependencies (i.e. leave out provided and test, > as at present) but modify the <import> type based on the c-m-p > configuration. This is still on the same veins, where the presence of deps in the c-m-p will obviate the need for a separate <useMavenDep> option. > > However, I don't think we should proceed with this refinement until > all the configs are checked to be generating reasonable geronimo- > plugin.xml files > > thanks > david jencks > > > > > Cheers > > Prasad > > > > On 10/10/07, Paul McMahan <[EMAIL PROTECTED]> wrote: > >> On Oct 10, 2007, at 3:32 PM, David Jencks wrote: > >> > >>> Indeed it might. AFAIK no one has found an actual use for > >>> <import>service</import> dependencies before.... could I inquire > >>> what use you found for it and how you avoided class cast exceptions? > >> > >> I looked into to using it to enforce module startup order. The > >> console should startup before any console extensions because the > >> console listens for extensions being added to its navigator. But > >> those extensions should not (necessarily) inherit the console's > >> classloader, especially since the console uses spring for configuring > >> the pluto internals. The services dependency type didn't work as I > >> had expected while using the c-m-p so I never actually used it in a > >> server to see any class cast exceptions. > >> > >> > >> Best wishes, > >> Paul > >> > >
