ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <>
Subject Did somebody say Shut up and Write? :)
Date Tue, 19 Dec 2000 12:05:01 GMT
Ok. So, I heard ya. And I've started a write up. If this is an attempt to
actually build consensus on Ant2 and earn my stripes, so be it.  In any
case, Jon was correct in his phone call to me that it was time to put up or
shut up.

Sorry, it's in footer mode right now as 1) I write better in
Dreamweaver than hacking XML tags and Dreamweaver is set up for my site and
2) it's too damn late to get this checked in somewhere, so it's parked on my
site which is reflected off of my local web docs drive. Please don't be
offended that it's currently sitting on my site.

The document is written in a bit of a prose style rather than a dry bullet
list style to try and explain the rational behind the set up. Or maybe its
that way because I'm tired. :) In any case....

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.

    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.

    some simple examples showing how Workspace/Module files can work

    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.

    Ant-call isn't discussed here as the Workspace/Module thoughts are this
    proposals mechanism for dealing with modularity and multi build files.

    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.

    Datatypes to be defined anywhere -- They belong with modules for scoping
    reasons. This is one of the things that I've stressed each and every
    time that I have popped up over the last year. Its cleaner to view
    properties as a single data store that is global to the module.

    Unification of datatypes. Well, guess I don't oppose it in general
    terms. I found a way to get there that feels pretty good for me and
    in fact generalizes out Sets from just being collections of Files.
    Conor and I had a discussion offline about Datatypes and I did some
    long hard looking at what was there...

    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. :)

Observations (and Questions) for Diane:

    Sounds like a *really* good Javac fa├žade is needed for your stuff to
    deal with the permutations. That is definitely going to provide a good
    workout for whatever solution comes along.

    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.

    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?

    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?

James Duncan Davidson                              
                                                                  !try; do()

View raw message