Re: endorsing: ToolChain thing or compiler/surefire plugin thing or ....

[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 ....

[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