Re: Make useMavenDependencies default true ?
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 [EMAIL PROTECTED] wrote: On Oct 10, 2007, at 3:32 PM, David Jencks wrote: Indeed it might. AFAIK no one has found an actual use for importservice/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 useMavenDependencies default true ?
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: On Oct 10, 2007, at 3:32 PM, David Jencks wrote: Indeed it might. AFAIK no one has found an actual use for importservice/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 useMavenDependencies default true ?
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 importservices/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 importall/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 useMavenDependencies default true ?
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 artifactIdplugin1/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 artifactIdcar-maven-plugin/artifactId configuration dependency artifactIdplugin2/artifactId importservice/import /dependency /configuration /plugin /build /project Best wishes, Paul
Re: Make useMavenDependencies default true ?
On 10/10/07, David Jencks [EMAIL PROTECTED] 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 [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 importservices/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 importall/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
Re: Make useMavenDependencies default true ?
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 artifactIdplugin1/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 artifactIdcar-maven-plugin/artifactId configuration dependency artifactIdplugin2/artifactId importservice/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 useMavenDependencies default true ?
On Oct 10, 2007, at 11:50 AM, David Jencks wrote: project artifactIdplugin1/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 artifactIdcar-maven-plugin/artifactId configuration dependency artifactIdplugin2/artifactId importservice/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 importservices/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 importservices/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 useMavenDependencies default true ?
On Oct 10, 2007, at 9:51 AM, Paul McMahan wrote: On Oct 10, 2007, at 11:50 AM, David Jencks wrote: project artifactIdplugin1/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 artifactIdcar-maven-plugin/artifactId configuration dependency artifactIdplugin2/artifactId importservice/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 importservices/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 importservices/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 importservice/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 useMavenDependencies default true ?
On Oct 10, 2007, at 3:32 PM, David Jencks wrote: Indeed it might. AFAIK no one has found an actual use for importservice/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
Make useMavenDependencies 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 useMavenDependencies default true ?
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 importservices/ 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
Re: Make useMavenDependencies default true ?
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 importservices/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 importall/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 useMavenDependencies default true ?
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 importservices/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 importall/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
