geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jarek Gawor <>
Subject Re: Maven compiler & endorsed libraries
Date Wed, 07 Apr 2010 17:20:54 GMT
On Wed, Apr 7, 2010 at 12:31 PM, David Jencks <> wrote:
> On Apr 7, 2010, at 6:24 AM, Jarek Gawor wrote:
>> On Wed, Apr 7, 2010 at 5:47 AM, Rick McGuire <> wrote:
>>> On 4/6/2010 5:23 PM, Jarek Gawor wrote:
>>> I came up with one solution (committed in revision 931319).
>>> In this solution I created a maven-property-plugin which executes in
>>> the "validate" phase and sets "bootClassPath" system property. The
>>> value of "bootClassPath" property is set to
>>> -Xbootclasspath/p:<path><pathSeparator><path>... string where
>>> <path> is the jar file to prepend to boot classpath. The
>>> "bootClassPath" property is then used in maven-compiler-plugin and
>>> maven-surefire-plugin and passed as a java/javac argument.
>>> This seems to work for me but I'm wondering if it works for other
>>> people on different OSes and JVMs (especially on Windows and on
>>> non-Sun JVMs).
>>> What's driving the need for doing this?  Generally, prepending something to
>>> the bootstrap classpath is considered very bad form.  The JVM supported
>>> method for overriding bootstrap classes is the endorsed directory path.  I
>>> took another look at what Yoko does to get around this problem, and it
>>> appears the mavan-compiler-plugin and surefire plugins have all the support
>>> you need.  Here are some snippets from the Yoko core subproject.  To compile
>>> this code, it requires the yoko-corba-spec classes rather than the JVM
>>> provided ones.   The build contains the following build steps:
>> <snip>
>> I am aware of that solution as well and it works great for simple or
>> just a few modules. But as soon as you have to scale this to a large
>> number of modules it sucks because maven-dependency-plugin will keep
>> creating and copying the same files around for each module. We could
>> create some plugin that creates a single shared endorsed directory but
>> then we would have to worry about deleting that directory on maven
>> shutdown, etc.
>> I chose to go with -Xbootclasspath/p since it takes a list of jar
>> files and we don't have worry about copying any files or deleting any
>> directories. The -Xbootclasspath/p is a non-standard option and that
>> is a bit of a concern. However, the most popular JVMs do support this
>> option. If we run into a JVM that we need to support and it does not
>> have this option then I'll guess we will need to re-evaluate.
> Why can't we skip the use of the dependency plugin to copy jars and just set the endorsed
dirs to a list of the desired jars in the local maven repo?  I have no particular objection
to -Xbootclasspath but wouldn't mind understanding whether this would work...

I considered that too. If you're dealing with released artifacts that
should work ok. But if you are dealing with snapshot dependencies, you
might have multiple jars in the same directory with a different
snapshot version. The -Djava.endorsed.dirs would pick up all these
jars and so we wouldn't know exactly which jar is actually used.
That's why a temporary directory would be needed to copy the specific

Once the annotation, jaxws, etc. specs are released it should be
trivial to update the geronimo-property-plugin to return
-Djava.endorsed.dirs property instead of -Xbootclasspath property.

> It does seem like all the maven plugins that start a new jvm need support for endorsed
and ext dirs based from the maven repo.....  is it possible that patching the plugins might
be, long-term, the fastest way to solve the problem?

Sure. The stuff that geronimo-property-plugin is doing is pretty much
what the compiler or surefire plugin would need to do.


View raw message