import-bot (20212) [Avatar] Offline
#1
[Originally posted by ddkilzer]

I know, I know, you probably feel like you just got done with the first
edition! smilie Here are a couple ideas that I would have found useful in
the current book (mostly due to lack of experience with the Ant world):

1. A "reverse index" of subelements that may be nested within tasks.
For example, a list of all tasks that take a <classpath> (or other
"path-like") datatype.

I found it frustrating that the index only contained one entry on
"classpath" inside <javac>, when it can also be used in <taskdef>
and <junit>, to name two.

Also, I have yet to understand why the <cvs> task doesn't take a
<path> subelement, but maybe that's just because I'm using WSAD
and its crazy project structure. (Having to update 30+ directories,
each as a separate checkout directory, is just annoying.)

2. Regarding the internal API, explain the difference between:
setProperty(), setNewProperty(), setUserProperty() and
setInheritedProperty(). A statement about when each should be
used when writing tasks (and why) would be very helpful.
(Section 19.2.2 in the Ant book on page 471 covers two of them,
but doesn't give examples for each. Note that I have NOT read
much of this chapter at all, so I could be missing a lot.)

In the spirit of open source, I wrote a <propertycharreplace>
task that was heavily derived from <propertyregex> from
antcontrib-0.4, but I noticed that <propertyregex> does not
appear to respect immutability. I created a bug on SourceForge
for this, but after I did so, I realized that had this task
respected immutabiliy, it would have made my work much harder.

http://sourceforge.net/tracker/index.php?func=detail&aid=790686&group_id=36177&atid=416920


I guess I'm not sure I understand when property immutability
applies and when it doesn't (yet). I just copied what the
<propertyregex> task used rather than experimenting with each
of the four API calls above.

Anyway, thanks for all the hard work writing this book! I started
reading Chapter 1, but ended up diving head-first into the book
while writing custom Ant tasks to automate a build for IBM's WSAD
tool. It's been an invaluable reference, and I'm afraid I would
have worn out Google looking for answers if I didn't have the
book handy!

BTW, the Ant task I wrote for WSAD is called <projectbuildall> and
(re)builds all projects in a workspace, not just one, which
complements the <projectbuild> task Barry Searle talks about
in his article.

http://www7b.software.ibm.com/wsdd/library/techarticles/0203_searle/searle3.html

Finally, I almost went to the NoFluffJustStuff conference
in Chicago in September, but there is a big in-state rivalry
college football game that weekend which I already had plans
for. (Go Iowa State!)

http://www.nofluffjuststuff.com/2003-09-chicago/index.jsp
http://cyclones.ocsn.com/sports/m-footbl/sched/iast-m-footbl-sched.html

Dave
import-bot (20212) [Avatar] Offline
#2
Re: 2 ideas for the next edition
[Originally posted by erikhatcher]

Dave,

Thank you so much for your very detailed feedback. Let me address your items
below...

> 1. A "reverse index" of subelements that may be nested within tasks.
> For example, a list of all tasks that take a <classpath> (or other
> "path-like"smilie datatype.

Good idea, and quite easy to accomplish. I'm not quite sure how useful it'd
be generally speaking
though. I don't think folks create a <path> and wonder where it could be
used. Keep in mind also
that the name "classpath" for a subelement only has meaning for that task, and
could conceivably have
other meanings, and there are other subelement names that take a path and its
used as a classpath
but don't use the name classpath exactly.

> Also, I have yet to understand why the <cvs> task doesn't take a
> <path> subelement, but maybe that's just because I'm using WSAD
> and its crazy project structure. (Having to update 30+ directories,
> each as a separate checkout directory, is just annoying.)

Yikes. I have felt your pain with WSAD. My sympathies.

> 2. Regarding the internal API, explain the difference between:
> setProperty(), setNewProperty(), setUserProperty() and
> setInheritedProperty(). A statement about when each should be
> used when writing tasks (and why) would be very helpful.

setNewProperty is really the main one that custom task writers should use, and
its best to keep it
documented more or less that way to avoid violations of property immutability.

> appear to respect immutability. I created a bug on SourceForge
> for this, but after I did so, I realized that had this task
> respected immutabiliy, it would have made my work much harder.

Property immutability is a good thing, but there are cons to it as you've
pointed out.

> I guess I'm not sure I understand when property immutability
> applies and when it doesn't (yet). I just copied what the
> <propertyregex> task used rather than experimenting with each
> of the four API calls above.

All built-in Ant tasks respect property immutability. Custom tasks may choose
not to, but I'd not use
tasks that broke those rules.

> BTW, the Ant task I wrote for WSAD is called <projectbuildall> and
> (re)builds all projects in a workspace, not just one, which
> complements the <projectbuild> task Barry Searle talks about
> in his article.

Very nice! I hope you get your task added to WSAD distribution or at least
out there for other WSAD
users to take advantage of.

> Finally, I almost went to the NoFluffJustStuff conference
> in Chicago in September, but there is a big in-state rivalry
> college football game that weekend which I already had plans
> for. (Go Iowa State!)
>
> http://www.nofluffjuststuff.com/2003-09-chicago/index.jsp

Unfortunately I will not be at the Chicago symposium. The pre-registration
numbers weren't good
enough to justify bringing me in. Prod the local user groups to get more
folks out to this wonderful
event! Its a real joy to attend - I highly recommend it!

Erik