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. > > thanks > david jencks Cheers Prasad > > > > > > Best wishes, > > Paul > >
