On 10/10/07, David Jencks <[EMAIL PROTECTED]> wrote: > > On Oct 8, 2007, at 7:45 PM, Prasad Kashyap wrote: > > > Comments inline - > > > > Thank you for your patience. > > > > On 10/8/07, David Jencks <[EMAIL PROTECTED]> wrote: > >> 2 replies in one go :-) > >> > >> On Oct 8, 2007, at 2:27 PM, Paul McMahan wrote: > >> > >>> On Oct 8, 2007, at 4:49 PM, Prasad Kashyap wrote: > >>> > >>>> Can we make the c-m-p use the maven dependencies by default ? 58 of > >>>> the 95 configs already use the maven deps. There are approx 15-20 > >>>> configs that need to be converted to plugins. Odds are we'll end up > >>>> with 75% of our configs using maven deps. Thus we should consider > >>>> using the maven deps as default. > >>> > >>> +1, can this setting can be inherited from the parent project like > >>> the other settings such as source-repository currently are? see > >>> configs/pom.xml and plugins/pom.xml > >> > >> we can do this as soon as all the existing configs have been > >> converted to using really using the c-m-p to generate the geronimo- > >> plugin.xml. Before that I believe we will get into big problems, > >> which is why I didn't do it in the first place. > > > > Right, right. We'll get to this after we convert all our configs to > > plugins. > > > >>> > >>>> Also, by default, it should merge the maven deps with the explicit > >>>> deps, IF ANY are specified in the c-m-p configuration. I don't > >>>> see a > >>>> use case for this now, but if there ever is a need to use both > >>>> maven > >>>> deps and an explicit list, this will let us achieve it. > >>> > >>> +1, one use case would be when you want to use the > >>> <import>services</import> environmental setting for a plugin > >>> dependency. I was trying to do that earlier today but it didn't > >>> seem to work right. > >> > >> I don't really understand the behavior you are proposing here. > >> Currently you have a choice between including all the maven > >> dependencies with <import>all</import> or explicitly specifying all > >> the dependencies you want with the import you want. If you > >> explicitly specify the dependencies in the c-m-p config section each > >> one has to be a maven dependency as well. > >> > >> What exactly are you proposing to be different here? > > > > You are right here. It seems like the inherited maven deps are > > included as well. In such a case, yes - the deps explicitly listed in > > the c-m-p are already have a maven dep somewhere (same pom or parent). > > > > However, the use case I was thinking was when you'd need to override > > the import of just one (of the many) maven dep in the c-m-p. In this > > case, you would include the maven deps by default, and then override > > the ones in c-m-p. But I reckon, we may be complicating things here. > > > > So should there never be a case when both the deps listings (maven > > deps and c-m-p deps) need to merge ? So the listings are always > > mutually exclusive ? > > > >> > >>> > >>>> Lastly, the exisiting <useMavenDependencies> parameter can be > >>>> used to > >>>> specifically exclude the maven deps. This will include only the > >>>> explicit deps in the c-m-p configuration. > >> > >> would this match the current behavior when you explicitly > >> configure c- > >> m-p dependencies? > >>> > >>> settings inherited from the parent projects can be overridden. > >> > >> Is this relevant to the preceding? I'm not seeing how yet. > > > > If we do use maven deps as default, then this becomes relevant when > > we need to exclude the maven deps. > > > > However, this was very much relevant when I thought we could merge the > > two listings. But if the 2 listings cannot be merged, then it's > > relevancy gets lost. If c-m-p has a deps explicitly listed, then it > > should automatically exclude the maven deps. Why use this flag at all > > ? > > > >> > >> I'm a little leery of more configuration choices than are absolutely > >> necessary. I wonder if we could get by with one behavior, namely > >> always using the maven dependencies with import type all unless the > >> import type is overridden in the c-m-p config. Are there any cases > >> this wouldn't work for? > > > > Again, if deps cannot be merge, then even if one dep's import type is > > overridden, then all the remaining deps should be listed in the c-m-p, > > right ? > > > >> > >> I think we'd still want the include version flag. > > > > Yes. Me too. > > I'm not sure I understand all of what you are saying but I think you > have pointed out a valuable possible simplification in the c-m-p > configuration. Let me try to restate it: > > 0. As at present, any dependency in the c-m-p config must already be > in the pom dependencies. > > 1. All the (compile, runtime) scoped maven dependencies in the pom > turn into plan dependencies and geronimo-plugin.xml dependencies > > 2. Unless overridden the import type is "all" > > 3. For other import types or other customization a dependency can be > mentioned in the c-m-p config in the pom. > > At this point the "useMavenDependencies" is pointless > > The includeVersion flag is still useful: if it is false but a version > is supplied in the c-m-p config for a particular dependency it should > be included despite the flag. > > Does this make sense? Is it what you were proposing?
Yes David. This is what I was proposing. Cheers Prasad > > many thanks for pushing on this :-) > > david jencks > > > > > >> > >> thanks > >> david jencks > > > > Cheers > > Prasad > > > >>> > >>> > >>> Best wishes, > >>> Paul > >> > >> > >
