Hi Conor, What you say is true. And the compilers do do the right thing for these files -- they put them in the directory specified by the -d option. I'm not later moving them into the top-level -- that's where they get compiled into, because these files aren't part of any package. But <javac>, as it stands now, makes an assumption that all files are, and modifies the classfile location accordingly, to do the existence/timestamp check. That's fine for files that do belong to a package (and the ones I have that do, live in the source tree in the subdirs appropriate to their package), but it doesn't work for files that aren't part of a package. Those files should be able to live in the source tree wherever it makes sense for them to, since the compilers don't require they live any particular place -- but currently, <javac> does.
Since the behaviour I added is only turned on when the "flatten" attribute is set to true, it's something you'd have to specifically ask for in order to get. So presumably, people would only ever do that when it was the right thing to do. On the subject of the other change I made: Did you have any feelings about the "listfiles" stuff? It's also behaviour you'd specifically have to ask for, so it seems pretty safe to include. As I said before, it's not something I'd want to have turned on all the time, but it is something I'd want to be able to, from time to time. Thanks, Diane --- Conor MacNeill <[EMAIL PROTECTED]> wrote: > Diane, > > I'm -1 on your patch and I hope I can explain why. The assumption that > the > source tree is structured according to the package structure is not > unique > to ant but is also used by the Sun javac compiler and, I presume, all > other > Java compilers. When a class depends on another class, for which no > class > file exists, Javac can automatically compiler a source file to produce a > class file to satisfy the dependency. It can only do so however, if the > classes and source exist in a directory structure which matches the > package > structure. > > I have attached an example consisting of two classes in two packages, > one of > which is dependent on the other. > > If you try to compile just the class B.java you get the following > > F:\example>javac y\B.java > y\B.java:3: cannot resolve symbol > symbol : class A > location: package x > import x.A; > ^ > y\B.java:6: cannot resolve symbol > symbol : class A > location: class y.B > private A a; > ^ > 2 errors > > Javac cannot satify the class dependencies. If you now try > > F:\example>javac -sourcepath . y\B.java > > You will find that it compiles and that javac has automatically built > x/A.class from x/A.java without you even asking it to do that. It only > could > do that because the source files directory structure matches the package > structure. > > So, there are certain benefits to arranging your source in this way. I > think > a lot of people don't do this and end up with a flat set of Java source > files or files organized according in some other way. In most cases that > will still work, especially if you compile everyting the way ant will. > For > example, the following compiles fine > > F:\example>javac y\B.java x\A.java > > I think the current ant behaviour encourages you to use this layout and, > IMHO, that is a good thing. To allow it to support a flat or unrelated > directory structure would not be a good thing. > > > One problem I was having with <javac> is that I have source files that > > live in subdirs, but that need to be built into the top level of the > build > > tree. > > I have to wonder why that is. At work, we have a number of source trees, > which are subdirectories of a "src" directory. These trees are each > organized along package structure lines and are built with independent > <javac> tasks. > > > The problem was they were always getting rebuilt, since <javac> > > makes the class filename match the path of the source filename, and > looks > > for destdir/srcpath/to/file.class rather than just destdir/file.class > -- > > which is perfectly fine in most cases, just not in all. > > I feel it should be perfectly fine in all cases. Of course, that is easy > to > say without knowing the details of your situation. > > For further info on javac's behaviour, have a read of > http://java.sun.com/products/jdk/1.2/docs/tooldocs/win32/javac.html > > under the section "SEARCHING FOR TYPES" > > Cheers > Conor > > ATTACHMENT part 2 application/x-gzip name=example.zip ===== ([EMAIL PROTECTED]) __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/
