On Apr 7, 2010, at 6:24 AM, Jarek Gawor wrote: > On Wed, Apr 7, 2010 at 5:47 AM, Rick McGuire <rick...@gmail.com> 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? thanks david jencks > > Jarek
