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