Re: Hacking Classpath in Eclipse

[Mark Wielaard]

Hi,

On Wed, 2005-12-21 at 19:21 -0700, Tom Tromey wrote:
> Note that this will work for running something, but not if you want
> to compile against that JRE.
> 
> For the latter I think we need to come up with some kind of "fake jdk"
> project.  I actually have the start of one here, but I haven't
> finished polishing it yet.
> 
> Ideally Eclipse would offer the possibility of auto-exporting the
> build results as a .jar.  That would solve this entirely.

Wouldn't it be enough if we could convince eclipse to accept a
"hand-made jre"? I mean one where you can you explicitly set the
individual binaries that make up the tools that eclipse expects? Plus
convincing the built-in eclipse compiler to use a flat (non-jar/zip)
bootclasspath? (I believe ecj can use dirs already, but haven't
checked.)

It feels like eclipse is just trying to be too clever in its "jre
detection". Maybe if the "JRE definitions" preference box had an
"override - I know what I am doing" box, so you could fill in the
individual parts that make up the "StandardVMType" thing.

If you take a quick look at
org/eclipse/jdt/internal/launching/StandardVMType.java it looks like
this class just needs a set of setters and a way to override that auto
detection. Or maybe we need a new subclass of AbstractVMType that
creates an IVMInstall just based on user defined locations that can be
plugged into the standard JRE preferences dialog as override to the
autodetecting StandardVMType?

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part