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?
many thanks for pushing on this :-)
david jencks
thanks
david jencks
Cheers
Prasad
Best wishes,
Paul
