geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Maven compiler & endorsed libraries
Date Wed, 07 Apr 2010 16:31:58 GMT

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

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?

david jencks

> Jarek

View raw message