Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
Just to follow up on this, it looks like the two main options are: 1) Add an endorsed scope. What would be involved with that? What would happen when a 2.0.10/2.2.1 maven version hits such a scope?This seems to be a maven core thing with updates needed to a bunch of core things. Not a BAD thing, especially for 3.0 or something, but increases the complexity. 2) maven-endorsed-plugin - similar to the toolchains thing, but provides special endorsing capabilities. Would be done in parts. The plugin plus updates to surefire and compiler (and others that may need it). (2) can definitely be made to work with existing versions of maven, but (1) definitely seems cleaner. (1) would also allow endorsements to be handled from transitive deps, although I'm not sure if that's a good thing or not. :-) Anyway, what are peoples thoughts? I think after thanksgiving, I may need to start working on bits of this so I'd like to get peoples thoughts and ideas before then. Dan On Mon November 9 2009 4:55:17 pm Daniel Kulp wrote: While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. Basically, we're going to need a mechanism to easily endorse a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their fork mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. 2) Require all devs to copy the jars someplace and add -Djava.endorsed.dirs=.. to their MAVEN_OPTS.Also sucks. 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration endorsedArtifacts endorsedArtifact groupId.../groupId artifactId.../artifactId version/version /endorsedArtifact /endorsedArtifacts /configuration /plugin and similar configuration for surefire. Maybe make version optional and it would pick up a version from a dependency. 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. Anyway, does anyone have any other thoughts? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
Is it possible to add endorsed libraries programatically? I thought the JDK grabbed all its endorsements from jdk_home\lib\ext Paul On Thu, Nov 12, 2009 at 12:48 PM, Daniel Kulp dk...@apache.org wrote: Just to follow up on this, it looks like the two main options are: 1) Add an endorsed scope. What would be involved with that? What would happen when a 2.0.10/2.2.1 maven version hits such a scope? This seems to be a maven core thing with updates needed to a bunch of core things. Not a BAD thing, especially for 3.0 or something, but increases the complexity. 2) maven-endorsed-plugin - similar to the toolchains thing, but provides special endorsing capabilities. Would be done in parts. The plugin plus updates to surefire and compiler (and others that may need it). (2) can definitely be made to work with existing versions of maven, but (1) definitely seems cleaner. (1) would also allow endorsements to be handled from transitive deps, although I'm not sure if that's a good thing or not. :-) Anyway, what are peoples thoughts? I think after thanksgiving, I may need to start working on bits of this so I'd like to get peoples thoughts and ideas before then. Dan On Mon November 9 2009 4:55:17 pm Daniel Kulp wrote: While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. Basically, we're going to need a mechanism to easily endorse a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their fork mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. 2) Require all devs to copy the jars someplace and add -Djava.endorsed.dirs=.. to their MAVEN_OPTS. Also sucks. 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration endorsedArtifacts endorsedArtifact groupId.../groupId artifactId.../artifactId version/version /endorsedArtifact /endorsedArtifacts /configuration /plugin and similar configuration for surefire. Maybe make version optional and it would pick up a version from a dependency. 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. Anyway, does anyone have any other thoughts? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
On Thu November 12 2009 2:22:51 pm Paul Benedict wrote: Is it possible to add endorsed libraries programatically? I thought the JDK grabbed all its endorsements from jdk_home\lib\ext When you fork a jvm (javac fork or surefire set to fork), you can specify a system property of other places to look. Thus, then endorsed stuff would only apply when those are set to fork. Dan Paul On Thu, Nov 12, 2009 at 12:48 PM, Daniel Kulp dk...@apache.org wrote: Just to follow up on this, it looks like the two main options are: 1) Add an endorsed scope. What would be involved with that? What would happen when a 2.0.10/2.2.1 maven version hits such a scope?This seems to be a maven core thing with updates needed to a bunch of core things. Not a BAD thing, especially for 3.0 or something, but increases the complexity. 2) maven-endorsed-plugin - similar to the toolchains thing, but provides special endorsing capabilities. Would be done in parts. The plugin plus updates to surefire and compiler (and others that may need it). (2) can definitely be made to work with existing versions of maven, but (1) definitely seems cleaner. (1) would also allow endorsements to be handled from transitive deps, although I'm not sure if that's a good thing or not. :-) Anyway, what are peoples thoughts? I think after thanksgiving, I may need to start working on bits of this so I'd like to get peoples thoughts and ideas before then. Dan On Mon November 9 2009 4:55:17 pm Daniel Kulp wrote: While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. Basically, we're going to need a mechanism to easily endorse a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their fork mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. 2) Require all devs to copy the jars someplace and add -Djava.endorsed.dirs=.. to their MAVEN_OPTS.Also sucks. 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration endorsedArtifacts endorsedArtifact groupId.../groupId artifactId.../artifactId version/version /endorsedArtifact /endorsedArtifacts /configuration /plugin and similar configuration for surefire. Maybe make version optional and it would pick up a version from a dependency. 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. Anyway, does anyone have any other thoughts? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
Yes, then it is probably appropriate for the Maven Compiler plugin to support endorsed libraries. I can't remember if it always forks, but if forking isn't specified, an error should be thrown when endorsed libraries are used. Paul On Thu, Nov 12, 2009 at 3:19 PM, Daniel Kulp dk...@apache.org wrote: On Thu November 12 2009 2:22:51 pm Paul Benedict wrote: Is it possible to add endorsed libraries programatically? I thought the JDK grabbed all its endorsements from jdk_home\lib\ext When you fork a jvm (javac fork or surefire set to fork), you can specify a system property of other places to look. Thus, then endorsed stuff would only apply when those are set to fork. Dan Paul On Thu, Nov 12, 2009 at 12:48 PM, Daniel Kulp dk...@apache.org wrote: Just to follow up on this, it looks like the two main options are: 1) Add an endorsed scope. What would be involved with that? What would happen when a 2.0.10/2.2.1 maven version hits such a scope? This seems to be a maven core thing with updates needed to a bunch of core things. Not a BAD thing, especially for 3.0 or something, but increases the complexity. 2) maven-endorsed-plugin - similar to the toolchains thing, but provides special endorsing capabilities. Would be done in parts. The plugin plus updates to surefire and compiler (and others that may need it). (2) can definitely be made to work with existing versions of maven, but (1) definitely seems cleaner. (1) would also allow endorsements to be handled from transitive deps, although I'm not sure if that's a good thing or not. :-) Anyway, what are peoples thoughts? I think after thanksgiving, I may need to start working on bits of this so I'd like to get peoples thoughts and ideas before then. Dan On Mon November 9 2009 4:55:17 pm Daniel Kulp wrote: While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. Basically, we're going to need a mechanism to easily endorse a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their fork mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. 2) Require all devs to copy the jars someplace and add -Djava.endorsed.dirs=.. to their MAVEN_OPTS. Also sucks. 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration endorsedArtifacts endorsedArtifact groupId.../groupId artifactId.../artifactId version/version /endorsedArtifact /endorsedArtifacts /configuration /plugin and similar configuration for surefire. Maybe make version optional and it would pick up a version from a dependency. 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. Anyway, does anyone have any other thoughts? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
endorsing: ToolChain thing or compiler/surefire plugin thing or ....
While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. Basically, we're going to need a mechanism to easily endorse a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their fork mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. 2) Require all devs to copy the jars someplace and add -Djava.endorsed.dirs=.. to their MAVEN_OPTS.Also sucks. 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration endorsedArtifacts endorsedArtifact groupId.../groupId artifactId.../artifactId version/version /endorsedArtifact /endorsedArtifacts /configuration /plugin and similar configuration for surefire. Maybe make version optional and it would pick up a version from a dependency. 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. Anyway, does anyone have any other thoughts? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
2009/11/9 Daniel Kulp dk...@apache.org: While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. I've already hit some interesting poms towards that end of the projects built with maven... though it could be camel, or activemq... whereby the pom helpfully adds dependencies when you compile on java 1.5... which is just plain wrong with toolchains in the mix. Basically, we're going to need a mechanism to easily endorse a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their fork mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. Not a runner, too much will go wrong. 2) Require all devs to copy the jars someplace and add -Djava.endorsed.dirs=.. to their MAVEN_OPTS. Also sucks. Not a runner IMHO 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. Ugly, but works right now 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration endorsedArtifacts endorsedArtifact groupId.../groupId artifactId.../artifactId version/version /endorsedArtifact /endorsedArtifacts /configuration /plugin and similar configuration for surefire. Maybe make version optional and it would pick up a version from a dependency. Might be the easiest way to get this going... but I'd rather get maven-compiler-plugin 2.1 out the door before you go adding it in. and we'd probably run a surefire 2.5 release before too (just to get a baseline, and both of these need releasing. with the maven plugin enforcer we should be ablet to release the core plugins more often) 7) a maven-endorsed-plugin which would hold the configuration of endorsed artifacts, push it into MavenSession and then compiler, surefire, etc could pull the information back out of MavenSession. That would at least reduce the duplication of information... it would also remove the dual-purposing of toolchains 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. I can't see this being as easy. Basically, toolchains gives you a way to define toolchains and to find them again. We could modify the jdk toolchain to allow defining endorsed libs, but it will not do what you are trying to achieve in the maven way, i.e. it would require either serious hacks (exposing the artifacts we need as extensions in within the configuration section of mavev-toolchains-plugin), or rolling a custom config for each project (which is just wrong and makes setting up from checkout difficult)... though with the custom plexus reader we could possibly do something whereby you'd have plugin artifactIdmaven-toolchains-plugin/artifactId configuration jdk version1.5/version endorsed dependency ... /dependency dependency ... /dependency dependency ... /dependency /endorsed It would require changing the JDKToolchain impl to pick up the info and not use it for matching the toolchain but instead for populating the toolchain afterwards. I don;t like that I have to type in the dependency information twice though 6) Add a new scope: endorsed Actually there are a number of valid cases where new scopes are needed. It might be no harm to start looking into adding new scopes. IMHO a scope of endorsed is the right way to solve this problem. I could be convinced that there is a more correct way, but of the solutions on the table, IMHO, this is the best. On the other hand, a scope of endorsed smells a bit too close to system, which we don't want! Plus, there is the prospect of cross-cutting (which we already have), i.e. we have endorsed-compile, endorsed-provided, endorsed-runrtime, endorsed-test-compile, endorsed-test-runtime, etc. It would be good if we could specify multiple scopes in the scope, e.g. comma/space separated values (given that we are somewhat limited by the pom schema)... but that feels like schema hacking Anyway, does anyone have any other thoughts? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail:
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
9) use a new plugin (let's call it maven-java-plugin) to give us namespacing in the pom. you'd add the plugin to the API pom and its configuration section would annotate the pom with information about what jdk versions the dependency is provided in, what versions it shod be endorsed in, what minimum java version it depends on, etc we'd then provide a component to parse the info for a set of dependencies against a specific toolchain to give, eg endorsed config, filter out unnecessary deps, etc. this would also let us decide on what extended info is needed in pom 5.0.0 Sent from my [rhymes with tryPod] ;-) On 9 Nov 2009, at 22:58, Stephen Connolly stephen.alan.conno...@gmail.com wrote: 2009/11/9 Daniel Kulp dk...@apache.org: While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. I've already hit some interesting poms towards that end of the projects built with maven... though it could be camel, or activemq... whereby the pom helpfully adds dependencies when you compile on java 1.5... which is just plain wrong with toolchains in the mix. Basically, we're going to need a mechanism to easily endorse a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their fork mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. Not a runner, too much will go wrong. 2) Require all devs to copy the jars someplace and add - Djava.endorsed.dirs=.. to their MAVEN_OPTS.Also sucks. Not a runner IMHO 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. Ugly, but works right now 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration endorsedArtifacts endorsedArtifact groupId.../groupId artifactId.../artifactId version/version /endorsedArtifact /endorsedArtifacts /configuration /plugin and similar configuration for surefire. Maybe make version optional and it would pick up a version from a dependency. Might be the easiest way to get this going... but I'd rather get maven-compiler-plugin 2.1 out the door before you go adding it in. and we'd probably run a surefire 2.5 release before too (just to get a baseline, and both of these need releasing. with the maven plugin enforcer we should be ablet to release the core plugins more often) 7) a maven-endorsed-plugin which would hold the configuration of endorsed artifacts, push it into MavenSession and then compiler, surefire, etc could pull the information back out of MavenSession. That would at least reduce the duplication of information... it would also remove the dual-purposing of toolchains 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. I can't see this being as easy. Basically, toolchains gives you a way to define toolchains and to find them again. We could modify the jdk toolchain to allow defining endorsed libs, but it will not do what you are trying to achieve in the maven way, i.e. it would require either serious hacks (exposing the artifacts we need as extensions in within the configuration section of mavev-toolchains-plugin), or rolling a custom config for each project (which is just wrong and makes setting up from checkout difficult)... though with the custom plexus reader we could possibly do something whereby you'd have plugin artifactIdmaven-toolchains-plugin/artifactId configuration jdk version1.5/version endorsed dependency ... /dependency dependency ... /dependency dependency ... /dependency /endorsed It would require changing the JDKToolchain impl to pick up the info and not use it for matching the toolchain but instead for populating the toolchain afterwards. I don;t like that I have to type in the dependency information twice though 6) Add a new scope: endorsed Actually there are a number of valid cases where new scopes are needed. It might be no harm to start looking into adding new scopes. IMHO a scope of endorsed is the right way to solve this problem. I could be convinced that there is a more correct way, but of the solutions on the table,
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
I've done something for the javaee6 archetypes at mojo. I suppose you are talking the same problem. Only compilation now, not surefire. It's a solution within current constraints only. When leaving these behind, I would go for endorsed scope. http://svn.codehaus.org/mojo/trunk/mojo/mojo-archetypes/webapp-javaee6/src/main/resources/archetype-resources/pom.xml Milos On Mon, Nov 9, 2009 at 10:55 PM, Daniel Kulp dk...@apache.org wrote: While at ApacheCon last week, I talked to Jarek Gawor a bit and then followed up with a quick conversation with Brett about a problem that is soon going to hit CXF/Axis2/Geronimo. Basically, we're going to need a mechanism to easily endorse a few api jars when we call javac and when surefire runs. I'm ok with limiting the endorsing to when those plugins are in their fork mode. There are a few options that could be pursued: 1) Require all developers to drop some jars in jre/lib/endorsed. That really sucks. Not exactly viable, IMO. 2) Require all devs to copy the jars someplace and add -Djava.endorsed.dirs=.. to their MAVEN_OPTS.Also sucks. 3) In all modules, configure dependency:copy to copy the artifacts into a dir in target, then add the -D thing as system flags for compiler plugin and surefire. This is better than (2) as it can be all automatic in the poms, but it's a ton of configuration if dealing with a lot of poms and projects and such. 4) Add some mechanism to compiler and surefire (and maybe others) to do some of (3) automatically. I'm thinking something like: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration endorsedArtifacts endorsedArtifact groupId.../groupId artifactId.../artifactId version/version /endorsedArtifact /endorsedArtifacts /configuration /plugin and similar configuration for surefire. Maybe make version optional and it would pick up a version from a dependency. 5) Maybe some extension to the ToolChains stuff (which I don't know enough about, need to dig further if this is viable) to handle this. Anyway, does anyone have any other thoughts? -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
