You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Daniel Kulp <dk...@apache.org> on 2009/11/09 22:55:17 UTC
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>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-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
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or
....
Posted by Paul Benedict <pb...@apache.org>.
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>
>> >> <groupId>org.apache.maven.plugins</groupId>
>> >> <artifactId>maven-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
>> > dkulp@apache.org
>> > http://www.dankulp.com/blog
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
Posted by Daniel Kulp <dk...@apache.org>.
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>
> >> <groupId>org.apache.maven.plugins</groupId>
> >> <artifactId>maven-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
> > dkulp@apache.org
> > http://www.dankulp.com/blog
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or
....
Posted by Paul Benedict <pb...@apache.org>.
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>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-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
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
Posted by Daniel Kulp <dk...@apache.org>.
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>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-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
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....
Posted by Stephen Connolly <st...@gmail.com>.
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.connolly@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>
>> <groupId>org.apache.maven.plugins</groupId>
>> <artifactId>maven-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>
> <artifactId>maven-toolchains-plugin</artifactId>
> <configuration>
> <jdk>
> <version>1.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
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or
....
Posted by Stephen Connolly <st...@gmail.com>.
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>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-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>
<artifactId>maven-toolchains-plugin</artifactId>
<configuration>
<jdk>
<version>1.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
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: endorsing: ToolChain thing or compiler/surefire plugin thing or
....
Posted by Milos Kleint <mk...@gmail.com>.
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>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-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
> dkulp@apache.org
> http://www.dankulp.com/blog
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>