geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: Make <useMavenDependencies> default true ?
Date Wed, 10 Oct 2007 15:43:03 GMT
On 10/10/07, David Jencks <david_jencks@yahoo.com> 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 <david_jencks@yahoo.com> 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
> >>
> >>
>
>

Mime
View raw message