Stefan Bodewig wrote: > > Hi Joseph, > > I'm mixing comments to both parts as I've read them both just today. > > Part 1: > ======= > > (1) includes="**/*.java" is not necessary in <javac>. Ant is even smarter > than you think, <javac> already does exactly this. 8-)
actually, it doesn't, or it didn't anyways. I found that when I had edited a file with joe or emacs, leaving behind an archive of the pre-edit file "x.java~", ant-javac would actually compile that file, and it would compile it AFTER it compiled the matching .java file, so that my older version of my code was the final .class file generated (the same .class file would result because the classes had the same name). hence, my edits seemed not to happen. on other occasions, it would attempt compile .txt or .html files that I'd had in those directories as well. given what you've said, i'm not totally sure that wasn't a bug, and it might have been fixed by 1.4.1 and I was just so in the habit of working around it to notice. Even in open-source, I tend to get used to the idea that bugs never get fixed... I blame Microsoft, of course, but Sun has also been in the forefront of leaving some things broken for extended periods (there's a bug in java.net from 1.0 that is STILL not fixed as far as i'm concerned even in 1.4). > (2) I don't understand the comment regarding paths and <javadoc> > vs. <javac>. <javadoc> has nested <sourcepath> elements that are > equivalent to <javac>'s <src>. On the other hand, <javac> has a > sourcepathref attribute, just like the one you use in <javadoc>. In "javac" for 1.4.1, I see an attribute, srcdir, as one means of specifying it (with the examples that you can (semi-)colon multiple dirs in it), and I see the <src> elements as a human-readable alternative. I see nothing in the docs that say a Path reference of the sourcepathref form, nor in the source code. Its not there, but it IS in the CVS repository. As a new feature, great, and it matches what I wrote: "(I expect that in Ant 2.0, javac's syntax will be modified to match and bring all tasks into conformity.)" It just happened earlier than 2.0. ;) I realize Ant's cleaner than most in terms of environment effects (just set ANT_HOME and PATH and go), so cleaning up to an older version is easy compared to, say, mozilla for Windows, but I still tend not to play with "nightlies" if I can avoid it, and so I wrote specifically what I saw happen in 1.4.1. > Part 2: > ======= > > (3) it would be nice if you'd correct the statement about <javadoc> > not supporting wild cards ;-) well, i'd have sent a correction, but it was too late to catch it before publishing...I expected the articles to be 2 weeks apart and not just 1. > (4) I'd set a property instead of writing a file in <plistgen>. At least > make that an option. a thought. I'd have followed through with this if I wasn't already re-educated in the fact that javadoc does what plistgen does already, to a certain degree. however, as a scoping thing and a general practice in writing back-ends for scripting languages (of which Ant can be seen as one), I tend to not like the idea that variables spontaniously appear in the middle of execution. e.g., int i; createJinScope(i); int k = j + i; that sort of thing where "j" didn't exist in any way specified by the user, but suddenly there it is because some back end put it into the scope. that bugs me as bad design. Yes, I know I ended up doing exactly that with Jaxb, but in truth I didn't like having to go to that approach. Making it a condition probably would be better, where that would make the property be specified by the user and not internally created by the task. I just didn't think of deriving from Condition, only "using" it. the docs I suppose could be clearer about what objects at the API level are meant to be derived from (whether internally abstract or not), and what's "final". Being open-source, where one can examine the sources more closely as examples rather than relying on examples from the vendor, one could pretty much safely derive from anything. The concern still is that derivations from a more concrete object may become incompatible in future versions. > (5) learn to use setFoo(File) instead of setFoo(String). If you do > so, Ant will automatically convert the attributes value and assume > they are either absolute file names or relative to the project's base > directory. This made your project.resolveFile invocations obsolete as > well. perhaps, but I was also showing what the API was capable of at the project/file level. If i make a new article (by finding some other useful task to write), I'd probably bring that up. > (6) make JaxbCheck implement Condition so it can be reused in a > home-brewed subclass of <condition>. discussed under #4 above. thanks, Joe -- ---------------------------------------------------------------------- Joseph Shelby mailto:[EMAIL PROTECTED] 45533 Stablemates Ct. http://www.io.com/~acroyear Sterling, VA 20164 (703) 404-0314 | 247-7868 Software Engineer, ISX Corporation, Arlington, VA "The people of England will permit anything...except cruelty to horses and a rise in the price of beer." -- Return of the Musketteers (1989) ---------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
