On Fri, Feb 19, 2010 at 4:42 PM, krats <princekart...@gmail.com> wrote: > [...] directly use javac to compile , the behavior is what I would expect. So > for > example in the case I mentioned, assuming source structure src\f1\f1.java > and src\f2\f2.java, if I already create f1.jar and put it in lib, and > assuming f2.java imports a class in f1.java, if I do > > javac -classpath lib\f1.jar f2\f2.java > > then, it doesnt create f1\f1.class. Instead it uses the import f1 class from > the jar file.
In the pure Javac case, any dependent classes necessary to compile the .java files explicitly on the command line must be available either on the -classpath *or* a source file for that class be found relative to one of the -sourcepath entry, in which case that dependent .java file, despite not being on the Javac command line, will also be "greedily" compiled by Javac. <javac> implicitly adds a sourcepath arg to Javac, thus the difference in behavior in Ant and on the command line. You can explicitly say <javac sourcepath="" ...> to "reset" the sourcepath to nothing, "turning off" Javac greedy behavior, That's a classic technique <compilewithwalls> [1] uses to verify cross-package dependency in a single source tree for example. Run Ant with -verbose to see which arguments are actually passed to Javac, if you want to understand how the use of <javac> attributes and nested elements affect the "command line" for Javac. --DD [1] http://ant-contrib.sourceforge.net/tasks/tasks/compilewithwalls.html --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
