ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: Keeping a non-runtime-added classpath for compiles
Date Tue, 19 Sep 2000 22:47:01 GMT
It seem the correct way here would be for you to subclass Javac and override
what you need in the code to behave differently.

If in the process you need to make some pivate method of Javac protected I
do not think there would be an objection to that (in most cases).
 For example, override getCompileClasspath as:

	... getCompileClasspath(..., boolean addRuntime, ...) ...
      {
	  // Never add runtime classes
	  return super.getCompileClasspath(..., false, ...);
	}

Then just define your new task based on the subclass and VOILA'.
You could add your addruntime attribute just as simply.

Is it possible to redefine core tasks inside a project, that would be really
nice, then you could redefie <javac> to point to your own version.

Jose Alberto
 

> -----Original Message-----
> From: Diane Holt [mailto:holtdl@yahoo.com]
> Sent: Tuesday, September 19, 2000 3:27 PM
> To: ant-dev@jakarta.apache.org
> Subject: Keeping a non-runtime-added classpath for compiles
> 
> 
> I don't know if I'm unique in this need -- and if I am, I won't expect
> this to be added to <javac> generally (especially not on the 
> heels of Ken
> Wood's mail :) -- but I have a need to not have the runtime 
> stuff added to
> the classpath I use to do compiles.  In Javac.java, there's a boolean,
> addRuntime, which is set true for jikes (which I use) (it's hard-coded
> true in the call to getCompileClasspath, in doJikesCompile). As a
> workaround for now, I've changed it to be hard-coded false -- but I'd
> prefer to have an attribute for <javac> (maybe 
> addruntime="no" -- default
> would be "yes").
> 
> If you want to know why I need this, read on. I need to be 
> able to execute
> ant with a JVM >118 in order to have subproject compiles not end up
> causing both the DOS window pop-up thing and large compiles to hit the
> "string too long" error. I also like being able to have my 
> runtime java
> stuff be jdk13 -- it's got the fastest jar for one thing, and I'm
> assuming, since it's latest&greatest, it's just the better one to use.
> But, here's the thing, I cannot have any of the runtime stuff in my
> compile classpath, because compiles will break. The way I 
> have it now, I
> don't have a $CLASSPATH in my environment (I let ant build 
> that for me),
> and I'm passing in a property (compile.classpath) and setting the
> classpath attribute in <javac> to that -- which all works 
> great, unless
> the compile classpath gets the runtime stuff added to it, then it all
> falls down. So I modified Javac.java to turn that off, and 
> all is now well
> -- I get the runtime I want, and the compile env I need. But, 
> it does mean
> having to live with a non-off-the-shelf Ant -- which I can 
> do, if having
> an addruntime attribute is not something anyone else would ever feel a
> need for. (No one else has build-order, either, so I wouldn't 
> be surprised
> if it turned out no else would ever need this. :)
> 
> Thanks,
> Diane
> 
> =====
> (holtdl@yahoo.com)
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Send instant messages & get email alerts with Yahoo! Messenger.
> http://im.yahoo.com/
> 

Mime
View raw message