geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Make <useMavenDependencies> default true ?
Date Wed, 10 Oct 2007 06:26:11 GMT

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?

many thanks for pushing on this :-)

david jencks
>
>
>>
>> thanks
>> david jencks
>
> Cheers
> Prasad
>
>>>
>>>
>>> Best wishes,
>>> Paul
>>
>>


Mime
View raw message