Steve Loughran wrote: > Peter Reilly wrote: >> On 10/17/06, Chavdar Botev <[EMAIL PROTECTED]> wrote: >>> Peter, >>> >>> I repeated the steps you described and I can confirm that with the >>> -classpath argument the compilation fails and without it the >>> compilation succeeds. I also tried running javac on "src/test/*.java" >>> instead of "src/test/Test3.java". In this case, the compilation >>> succeeds with or without -classpath. >>> >>> I think it looks like some dependency problem. >> >> I have just checked the <javac> revision history, >> since the initial checkin (6 years, 9 months), <javac> has always added >> the destination path to the classpath for the javac command. >> >> It does not seem to be necessary? but I do not know if >> we can remove it without something failing. >> Perhaps we can use (yet another) attribute to javac to >> disable this behaviour. >> > > It is probably needed for incremental builds in which all source files > are not in the source tree you specify, such as when you have multiple > <javac> tasks building into the same place. > > I think we have caused a java generics bug to surface here. If > -classpath triggers it on the command line, it is probably a sun > problem. Question is, how to report it, and how to work around it in ant? > We could add an attribute to the javac task in order not to incorporate the destination to the compilation classpath. We could call it : includeclasses or includedest. It would be true by default, so BC would be preserved. So the workaround would be to set it to false in build files/projects affected by this problem.
How to report it : should go to the bug parade I think if it can be reproduced and is really a Sun bug. Regards, Antoine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
