ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Shelby <acroy...@io.com>
Subject Re: new Ant article online
Date Wed, 27 Mar 2002 19:28:31 GMT
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:acroyear@io.com
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:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message