Conrad O'Dea wrote:
Hi Anders,
it's possible to override the org.omg.* classes used by the JDK using
the endorsed standards override mechanism [1]. This lets you specify
a different set of classes to be used by the JDK. Now, I've no idea
how well this is supported by Maven 2. A mail to the maven-users
mail list may be needed.
rgds
Conrad
javac also has options available for cross compilation, which allows you
to compile code against class versions other than the version being used
to execute the javac code:
http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javac.html#crosscomp-options
Specifying -bootclasspath on javac is different than changing what's
used to run javac.
[1] http://java.sun.com/j2se/1.4.2/docs/guide/standards/
On 28 Mar 2006, at 11:09, Anders Hessellund Jensen wrote:
I'm having quite a bit of trouble getting Yoko to compile.
The problem is the fact that Sun provides org.omg.* classes in the
JDK on the boot class path. I suppose other JDK's behave in a similar
way.
Yoko provides its own org.omg.* classes, but the problem is to use
Yokos classes instead of the ones provided by Sun.
One approach to this is to override the boot class path passed to the
compiler / junit tests. This will require forking the compiler
process, which is currently not possible on Windows XP with maven 2
due to a restriction on the size of the argument list that can be
passed to the compiler. The argument list can be only 8192 characters
long, which is insufficient. Another problem is figuring out the boot
class path in a cross-platform way. With Suns JDK the boot class path
is accessible through the sun.boot.class.path system property.
Another approach might be to require developers on Yoko to create a
modified JDK with the org.omg.* classes ripped out. I would certainly
consider this a last resort fix to the problem.
Any ideas to how we solve this problem?
Best regards,
Anders
