ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joshua Davis" <>
Subject RE: Did somebody say Shut up and Write? :)
Date Tue, 19 Dec 2000 14:48:54 GMT
I read the doc, it's a great start.  Here's my "2 cents":

1. I agree with Peter about the 'set' feature:
a) The abstraction of fileset and patternset doesn't seem to  provide any
new functionality or extensibility.  Maybe if sets were even more abstract
and worked like tasks (i.e. plug in your own 'set' class... woo-hoo!)?
Still, although the description is clear in the document, the potential uses
are not.  What is the 'problem' with the existing 'fileset' and 'patternset'
features that  needs to be solved?

b) Java types!?? Yuk, indeed!  It seems fitting that ANT would know more
about Java than other languages, but this might be a bit extreme for those
non-Java folks using ANT (there are some of these, right?).

2. The proposal should contain a statement regarding upward compatibility
with previous versions.

3. Logging is important.  E-mail and newsgroup build notification is
commonplace.  HTML error and status reports would also be very nice,
although the 'front end' Servlet might be the place to do this.

4. Also in agreement with Peter: If the 'property in a task' capability is
removed, it should be replaced by something else.

5. Any 'implicit' behavior should be well documented (justified).  The doc
isn't entirely clear on why searching for modules implicitly is a good idea.

Okay, that was a nickel.

BTW, newbie question... what's CJAN?

Joshua Davis
Software Architect
Metiom, Inc. <>

> -----Original Message-----
> From: Peter Donald []
> Sent: Tuesday, December 19, 2000 8:40 AM
> To:
> Cc:
> Subject: Re: Did somebody say Shut up and Write? :)
> kewl ;)
> A few comments to start but I think I need a bit of time to digest it ;)
> At 04:05  19/12/00 -0800, James Duncan Davidson wrote:
> >What's there:
> >    a stab at actually looking at Workspace/Module rather than Project.
> >    This gets around child/parent Projects and ant-call -- and opens the
> >    door to something better.
> I am not sure I like the handling of differences between workspace/module.
> In many ways I think the difference is rather .. nebulous so not sure what
> to make of it. I am also strongly in favour of no intrinsic behaviour
> (including searching for workspace from module file).

Intrinsic behavior is very... 'make-like'. ;->

> We had a few complaints when we implemented this for ant build files. The
> two prominent ones were security - mistyping ant in wrong directory could
> send you into a long search that could find something in a very far away
> place (way up directory tree) and some installations would not instal ant
> with this feature enabled.
> The other issue was similar - searching could cause "thrashing" if you
> happenend to be on a NFS/samba/other remote drive. Typing ant
> could cause a
> 4-5 sec delay if you did it in wrong place.
> I much prefer explictness if at all possible. If you have a look at the
> antfarm proposal it actually explictly imported other projects in. For
> example for the following statement
> <import name="meep"/>
> it would look for meep.ant along "project path". While this project path
> was a controlled form of inter-project/workspace searching. For instance
> meep could refer to binary drop or source drop - however as long as it
> produced meep.jar in correctplace (as defined by a property in meep
> project) then it would be fine. I could see this as gret for CJAN.
> So I am not sure if seperating module/workspace out is ideal solution. I
> was of the understanding that workspace was more a conceptual idea. A
> "workspace" of foo was essentially the DAG of project files imported
> directly or indirectly from foo. Not sure I guess it needs to be looked at
> a bit more.
> >    a unification of Properties and Sets with a further
> abstraction of the
> >    current FileSet/PatternSet ideas. Any type of object that
> can be created
> >    with a String constructor can be set as a Property or a member of a
> >    Property Set. With a little more definition of builders, this
> >    requirement can go away.
> I think this may be too complex for users - not sure. While it would be
> ideal if we just wanted simple data types and sets of simple data types I
> think this approach would fall down in complex case. For example how would
> you represent
> <property name="foo">
>   <fileset dir="bob">
>    <fileset ref="bar" />
>    <patternset ref="blee" />
>    <patternset>
>       <include name="" />
>    </patternset>
>   </fileset>
> </property>
> (I know it is unrealistic but this is worst case scenario). It would also
> be unable to represent many other complex types (I am thinking temporary
> data-holders between tasks).
> However the worst thing about it is that it uses java types - yuck !!!
> Remember that many of the target audience doesn't know what java is
> (besides being that ugly thing thats is sometimes placed on web-pages). It
> seems unreasonable to expect any knowledge of java - especially if ant was
> to move towards a c/c++ build system.
> Also I don't think I like the restriction that properties could not be
> defined in targets. Currently a lot of my build files use something like
> <target name="debug-mode" if="debug-mode">
>   <property name="output.dir" value="../build/debug"/>
> </target>
> <target name="release-mode" depends="debug-mode" unless="debug-mode" >
>   <property name="output.dir" value="../build/release"/>
> </target>
> and I have recomended a lot of other people use that pattern. (Either that
> or the mutual-exclusion of multiple targets version of above) .
> >    some simple examples showing how Workspace/Module files can work
> >    together
> >
> >    a bad drawing of the Workspace runtime tree
> >
> >    other things captured.
> >
> >So -- comments on Peter's list based on this proposal:
> >
> >    namespaces -- no reason they can't be in buildfiles, but I
> don't think
> >    that we need to explicitly support them. If namespace
> attributes or tags
> >    are in the file, we just ignore them. If we treat them as
> such, we only
> >    depend on SAX1. No biggie, we should just define what we do.
> Right - a while ago I was advocating attributes such as
> ant:classpath="${foo}"
> ant:new-vm="true"
> ant:log-level="DEBUG"
> ant:....
> All these things are independent of the actual task and could be
> implemented as part of any task. This would stop a lot of special
> case code
> - for example a lot of my tasks used to run in default classpath but I
> later needed to specify the classpath. This of course meant a complete and
> utter rewrite of everything which I don't think was desirable -
> and I think
> it must be common situation.
> Considering the  above attributes are concerns of container (project)
> rather than contained component (task) - I think it may be nice/useful to
> think about applying them.
> >    Ant-call isn't discussed here as the Workspace/Module
> thoughts are this
> >    proposals mechanism for dealing with modularity and multi
> build files.
> ant-call was also used for templating. So instead of writing 10 targets
> that do a javac, jar, sign, you can write one target that gets properties
> past in via ant-call. It was primitive but a lot of people use it this way
> (which is surprising because it is slooooooow in current ant.
> >    Jar task info shouldn't be in the Manifest itself. Too much
> data can go
> >    there as is. It should probably be in META-INF/ant.xml or some such.
> agreed.
> >    Installer. I'd like to see more along these lines. In fact,
> given that
> >    Ant is pretty small (the biggest chunk is the durn XML
> parser), there's
> >    no real reason it can't be used as a task engine to be used by an
> >    installer. Probably something where a Module tree would be built
> >    at runtime so that things like install dir can be queried instead of
> >    being something that is driving off an XML file. I'm not
> sure that I'd
> >    write an installer that drove a project/workspace directly. Maybe I'd
> >    write it with Installets or something, but that's a whole different
> >    ball of wax. If this works for that purpose, more power. :)
> Right - I think it would be better to be at a lower level for installer.
> Instead of reusing whole of ant it would just reuse the task execution
> engine and ignore the project/module/workspace classes. Hopefully each
> different concern would be localised to a different directory and such
> reuse would be possible.
> >Observations (and Questions) for Diane:
> >    I'd like to know more about your build-order issues.
> Typically divisions
> >    between sourcepaths and destpaths seem like they could keep things
> >    segregated until you copy the results together into one happy tree.
> >    However, the side-compile issue is the biter. I guess I'd like a bit
> >    more info there.
> Thats what I thought - I think her build situations is really
> painful. Have
> to compile class 1, 2 and 3 with 1.3 JDK, then classes 4,5 6 with 1.2 JDK
> and then ... ouchies ;)
> >    I agree that if/unless checks need to be for true/false/1/0 type of
> >    matches and not existence of property. I would like to know your
> >    feeling about execution order. IOW, in AntEater I checked in a
> >    buildtarget task that did the if/unless checking.. This is a bit
> >    different than doing the if checking in the target def in the fact
> >    that all of those items could be centralized in one target instead
> >    of spread out through the build files. Would this be helpful?
> I am not sure it would be useful. It is similar to the issue of
> CSS styling
> of ant buildfiles but on a more fixed level which sounds painful ;)
> >    Logging -- it would be nice to provide a listener to simply write all
> >    events out to a file -- or mail the events output to somewhere at
> >    a particular email address... Any further comments on this?
> Theres a few issues. Sometimes you need to log to different things
> depending on how build finished and how long it took and what options were
> used to build etc. Similar to what you have ages ago I implemented
> something like
> <project ...>
>   <listener type="org.apache.ant.MailNotification">
>     <param name="blah" value="blee"/>
>   </listener>
> </project>
> However I found it too constraining as it missed to much being
> instantiated
> after the project was already in motion - I am not sure of a more viable
> solution thou ;(
> Cheers,
> Pete
> *-----------------------------------------------------*
> | "Faced with the choice between changing one's mind, |
> | and proving that there is no need to do so - almost |
> | everyone gets busy on the proof."                   |
> |              - John Kenneth Galbraith               |
> *-----------------------------------------------------*
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message