You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Prasad Kashyap <go...@gmail.com> on 2007/10/08 22:49:03 UTC
Make default true ?
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.
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.
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.
Thoughts ?
Re: Make default true ?
Posted by Prasad Kashyap <go...@gmail.com>.
Ah.. #2 in your list above hadn't registered well. Sorry.
Anyways, I get it now. But I'll still answer your questions below.
Cheers
Prasad
On 10/11/07, David Jencks <da...@yahoo.com> wrote:
>
> On Oct 11, 2007, at 10:07 AM, Prasad Kashyap wrote:
>
> > So in summary, do we keep the lists mutually exclusive ?
>
> You've said mutually exclusive a couple of times and I don't
> understand why. The list of dependencies in the c-m-p configuration
> has to be a subset of the dependencies in the maven configuration.
> This is required by maven to get the build order right. What do you
> mean by mutually exclusive?
Mutually exclusive is using either the maven dependencies or c-mp
configuration deps but not both. This is what we have at present. The
current <useMavenDep> option makes it mutually exclusive.
>
> > Paul, do you
> > still see a need for a merge/override option ?
>
> I do.
Now I see it. Based on #2 in your note, there is an override option.
So this means we will "merge" the list from maven deps and the c-m-p.
Some deps in the c-m-p may override the ones in the maven deps but the
other deps will be used as is.
> >
> > If so, I'll slowly deprecate the <useMavenDependency> option. Since
> > almost all configs have now been converted to plugins, I think it is
> > time we used the maven dependencies as default anyways. The presence
> > of any dependencies in the c-m-p configuration will make the c-m-p use
> > those deps only and exclude all maven deps.
>
> This is decidedly different from what I thought you proposed and what
> I thought was a good idea. I thought you proposed always using all
> the qualifying maven dependencies (i.e. leave out provided and test,
> as at present) but modify the <import> type based on the c-m-p
> configuration.
This is still on the same veins, where the presence of deps in the
c-m-p will obviate the need for a separate <useMavenDep> option.
>
> However, I don't think we should proceed with this refinement until
> all the configs are checked to be generating reasonable geronimo-
> plugin.xml files
>
> thanks
> david jencks
>
> >
> > Cheers
> > Prasad
> >
> > On 10/10/07, Paul McMahan <pa...@gmail.com> wrote:
> >> On Oct 10, 2007, at 3:32 PM, David Jencks wrote:
> >>
> >>> Indeed it might. AFAIK no one has found an actual use for
> >>> <import>service</import> dependencies before.... could I inquire
> >>> what use you found for it and how you avoided class cast exceptions?
> >>
> >> I looked into to using it to enforce module startup order. The
> >> console should startup before any console extensions because the
> >> console listens for extensions being added to its navigator. But
> >> those extensions should not (necessarily) inherit the console's
> >> classloader, especially since the console uses spring for configuring
> >> the pluto internals. The services dependency type didn't work as I
> >> had expected while using the c-m-p so I never actually used it in a
> >> server to see any class cast exceptions.
> >>
> >>
> >> Best wishes,
> >> Paul
> >>
>
>
Re: Make default true ?
Posted by David Jencks <da...@yahoo.com>.
On Oct 11, 2007, at 10:07 AM, Prasad Kashyap wrote:
> So in summary, do we keep the lists mutually exclusive ?
You've said mutually exclusive a couple of times and I don't
understand why. The list of dependencies in the c-m-p configuration
has to be a subset of the dependencies in the maven configuration.
This is required by maven to get the build order right. What do you
mean by mutually exclusive?
> Paul, do you
> still see a need for a merge/override option ?
I do.
>
> If so, I'll slowly deprecate the <useMavenDependency> option. Since
> almost all configs have now been converted to plugins, I think it is
> time we used the maven dependencies as default anyways. The presence
> of any dependencies in the c-m-p configuration will make the c-m-p use
> those deps only and exclude all maven deps.
This is decidedly different from what I thought you proposed and what
I thought was a good idea. I thought you proposed always using all
the qualifying maven dependencies (i.e. leave out provided and test,
as at present) but modify the <import> type based on the c-m-p
configuration.
However, I don't think we should proceed with this refinement until
all the configs are checked to be generating reasonable geronimo-
plugin.xml files
thanks
david jencks
>
> Cheers
> Prasad
>
> On 10/10/07, Paul McMahan <pa...@gmail.com> wrote:
>> On Oct 10, 2007, at 3:32 PM, David Jencks wrote:
>>
>>> Indeed it might. AFAIK no one has found an actual use for
>>> <import>service</import> dependencies before.... could I inquire
>>> what use you found for it and how you avoided class cast exceptions?
>>
>> I looked into to using it to enforce module startup order. The
>> console should startup before any console extensions because the
>> console listens for extensions being added to its navigator. But
>> those extensions should not (necessarily) inherit the console's
>> classloader, especially since the console uses spring for configuring
>> the pluto internals. The services dependency type didn't work as I
>> had expected while using the c-m-p so I never actually used it in a
>> server to see any class cast exceptions.
>>
>>
>> Best wishes,
>> Paul
>>
Re: Make default true ?
Posted by Prasad Kashyap <go...@gmail.com>.
So in summary, do we keep the lists mutually exclusive ? Paul, do you
still see a need for a merge/override option ?
If so, I'll slowly deprecate the <useMavenDependency> option. Since
almost all configs have now been converted to plugins, I think it is
time we used the maven dependencies as default anyways. The presence
of any dependencies in the c-m-p configuration will make the c-m-p use
those deps only and exclude all maven deps.
Cheers
Prasad
On 10/10/07, Paul McMahan <pa...@gmail.com> wrote:
> On Oct 10, 2007, at 3:32 PM, David Jencks wrote:
>
> > Indeed it might. AFAIK no one has found an actual use for
> > <import>service</import> dependencies before.... could I inquire
> > what use you found for it and how you avoided class cast exceptions?
>
> I looked into to using it to enforce module startup order. The
> console should startup before any console extensions because the
> console listens for extensions being added to its navigator. But
> those extensions should not (necessarily) inherit the console's
> classloader, especially since the console uses spring for configuring
> the pluto internals. The services dependency type didn't work as I
> had expected while using the c-m-p so I never actually used it in a
> server to see any class cast exceptions.
>
>
> Best wishes,
> Paul
>
Re: Make default true ?
Posted by Paul McMahan <pa...@gmail.com>.
On Oct 10, 2007, at 3:32 PM, David Jencks wrote:
> Indeed it might. AFAIK no one has found an actual use for
> <import>service</import> dependencies before.... could I inquire
> what use you found for it and how you avoided class cast exceptions?
I looked into to using it to enforce module startup order. The
console should startup before any console extensions because the
console listens for extensions being added to its navigator. But
those extensions should not (necessarily) inherit the console's
classloader, especially since the console uses spring for configuring
the pluto internals. The services dependency type didn't work as I
had expected while using the c-m-p so I never actually used it in a
server to see any class cast exceptions.
Best wishes,
Paul
Re: Make default true ?
Posted by David Jencks <da...@yahoo.com>.
On Oct 10, 2007, at 9:51 AM, Paul McMahan wrote:
> On Oct 10, 2007, at 11:50 AM, David Jencks wrote:
>
>>> <project>
>>> <artifactId>plugin1</artifactId>
>>> <dependencies>
>>> // a reference to plugin2 is not desirable here, don't
>>> // want maven processing it as a build time dep or
>>> // including its classes in the environment inherited
>>> // by car-maven-plugin
>>> </dependencies>
>>> <build>
>>> <plugin>
>>> <artifactId>car-maven-plugin</artifactId>
>>> <configuration>
>>> <dependency>
>>> <artifactId>plugin2</artifactId>
>>> <import>service</import>
>>> </dependency>
>>> </configuration>
>>> </plugin>
>>> </build>
>>> </project
>>>
>>
>> #0 is necessary to help maven build the modules in a correct
>> order. I believe we have successfully written the c-m-p so the
>> maven dependencies have no effect on the c-m-p environment, only
>> on the configuration that the c-m-p is "compiling" . Basically
>> the c-m-p fires up a small geronimo instance, and the root
>> classloader of that geronimo instance is the root maven
>> classloader, without any of the maven dependencies in it. Then we
>> load dependencies of the module we are constructing into this
>> geronimo instance just like a standalone geronimo server does.
>> So, the only effect these maven dependencies have is to assure
>> build order and to contribute to the geronimo module classloader
>> according to the rules above.
>>
>> make sense?
>
> Yes, makes sense. I didn't realize that the c-m-p was intended to
> behave that way because of a problem I was having using
> <import>services</import> in the c-m-p configuration section.
>
> When I included a reference to plugin2 in the main dependency
> section the gbean deployer invoked by the c-m-p was still trying to
> include plugin2's dependencies even though I overrode that
> dependency with <import>services</import> in the c-m-p's
> configuration section (like shown above). That might actually be
> a problem with the kernel's handling of service type deps though
> and it just surfaced to me through the c-m-p.
Indeed it might. AFAIK no one has found an actual use for
<import>service</import> dependencies before.... could I inquire what
use you found for it and how you avoided class cast exceptions?
thanks
david jencks
>
> Best wishes,
> Paul
Re: Make default true ?
Posted by Paul McMahan <pa...@gmail.com>.
On Oct 10, 2007, at 11:50 AM, David Jencks wrote:
>> <project>
>> <artifactId>plugin1</artifactId>
>> <dependencies>
>> // a reference to plugin2 is not desirable here, don't
>> // want maven processing it as a build time dep or
>> // including its classes in the environment inherited
>> // by car-maven-plugin
>> </dependencies>
>> <build>
>> <plugin>
>> <artifactId>car-maven-plugin</artifactId>
>> <configuration>
>> <dependency>
>> <artifactId>plugin2</artifactId>
>> <import>service</import>
>> </dependency>
>> </configuration>
>> </plugin>
>> </build>
>> </project
>>
>
> #0 is necessary to help maven build the modules in a correct
> order. I believe we have successfully written the c-m-p so the
> maven dependencies have no effect on the c-m-p environment, only on
> the configuration that the c-m-p is "compiling" . Basically the c-
> m-p fires up a small geronimo instance, and the root classloader of
> that geronimo instance is the root maven classloader, without any
> of the maven dependencies in it. Then we load dependencies of the
> module we are constructing into this geronimo instance just like a
> standalone geronimo server does. So, the only effect these maven
> dependencies have is to assure build order and to contribute to the
> geronimo module classloader according to the rules above.
>
> make sense?
Yes, makes sense. I didn't realize that the c-m-p was intended to
behave that way because of a problem I was having using
<import>services</import> in the c-m-p configuration section.
When I included a reference to plugin2 in the main dependency section
the gbean deployer invoked by the c-m-p was still trying to include
plugin2's dependencies even though I overrode that dependency with
<import>services</import> in the c-m-p's configuration section (like
shown above). That might actually be a problem with the kernel's
handling of service type deps though and it just surfaced to me
through the c-m-p.
Best wishes,
Paul
Re: Make default true ?
Posted by David Jencks <da...@yahoo.com>.
On Oct 10, 2007, at 7:14 AM, Paul McMahan wrote:
> On Oct 10, 2007, at 2:26 AM, David Jencks wrote:
>
>> 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.
>
> #1-3 look right on. I'm wondering if #0 is really necessary and
> desirable. For example, if I create plugin1 that needs a service
> type dependency against plugin2 then the pom could look like:
>
> <project>
> <artifactId>plugin1</artifactId>
> <dependencies>
> // a reference to plugin2 is not desirable here, don't
> // want maven processing it as a build time dep or
> // including its classes in the environment inherited
> // by car-maven-plugin
> </dependencies>
> <build>
> <plugin>
> <artifactId>car-maven-plugin</artifactId>
> <configuration>
> <dependency>
> <artifactId>plugin2</artifactId>
> <import>service</import>
> </dependency>
> </configuration>
> </plugin>
> </build>
> </project
>
#0 is necessary to help maven build the modules in a correct order.
I believe we have successfully written the c-m-p so the maven
dependencies have no effect on the c-m-p environment, only on the
configuration that the c-m-p is "compiling" . Basically the c-m-p
fires up a small geronimo instance, and the root classloader of that
geronimo instance is the root maven classloader, without any of the
maven dependencies in it. Then we load dependencies of the module we
are constructing into this geronimo instance just like a standalone
geronimo server does. So, the only effect these maven dependencies
have is to assure build order and to contribute to the geronimo
module classloader according to the rules above.
make sense?
thanks
david jencks
>
> Best wishes,
> Paul
>
Re: Make default true ?
Posted by Paul McMahan <pa...@gmail.com>.
On Oct 10, 2007, at 2:26 AM, David Jencks wrote:
> 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.
#1-3 look right on. I'm wondering if #0 is really necessary and
desirable. For example, if I create plugin1 that needs a service
type dependency against plugin2 then the pom could look like:
<project>
<artifactId>plugin1</artifactId>
<dependencies>
// a reference to plugin2 is not desirable here, don't
// want maven processing it as a build time dep or
// including its classes in the environment inherited
// by car-maven-plugin
</dependencies>
<build>
<plugin>
<artifactId>car-maven-plugin</artifactId>
<configuration>
<dependency>
<artifactId>plugin2</artifactId>
<import>service</import>
</dependency>
</configuration>
</plugin>
</build>
</project
Best wishes,
Paul
Re: Make default true ?
Posted by Prasad Kashyap <go...@gmail.com>.
On 10/10/07, David Jencks <da...@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 <da...@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
> >>
> >>
>
>
Re: Make default true ?
Posted by David Jencks <da...@yahoo.com>.
On Oct 8, 2007, at 7:45 PM, Prasad Kashyap wrote:
> Comments inline -
>
> Thank you for your patience.
>
> On 10/8/07, David Jencks <da...@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
>>
>>
Re: Make default true ?
Posted by Prasad Kashyap <go...@gmail.com>.
Comments inline -
Thank you for your patience.
On 10/8/07, David Jencks <da...@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.
>
> thanks
> david jencks
Cheers
Prasad
> >
> >
> > Best wishes,
> > Paul
>
>
Re: Make default true ?
Posted by David Jencks <da...@yahoo.com>.
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.
>
>> 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?
>
>> 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.
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?
I think we'd still want the include version flag.
thanks
david jencks
>
>
> Best wishes,
> Paul
Re: Make default true ?
Posted by Paul McMahan <pa...@gmail.com>.
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
> 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.
> 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.
settings inherited from the parent projects can be overridden.
Best wishes,
Paul