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.
http://www.x180.net/Projects/Build/index.html Sorry, it's in x180.net 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 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. 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? .duncan -- James Duncan Davidson [EMAIL PROTECTED] !try; do()
