.duncan wrote:
>Properties, and the way the behave really don't sit well with me right now. I took a pass about a week ago at eliminating properties all together. You heard me right - eliminating them. I think that they are way too procedural. You don't have them in HTML (except in scripts). Unfortunately, I gave up. I started by looking into _why_ they were used (as opposed to how). - Some properties were used to modify behavior: build.compiler, debug, optimize, etc. Something akin to a css stylesheet would be more to the point here. At the top, define a style that applies to all javac tasks - direct and to the point, as opposed to a procedural. By allowing an id on any element (something I've already laid the groundwork for), you could also allow individual overrides at the attribute level on any element. Very powerful stuff for projects which invoke other projects. Watching where Craig is going with jakarta-taglibs, he is heading towards building a larger building blocks to be used in the build process. - Paths. More specifically the root or something to prepend. If we modeled paths as containing two or more parts, and allowed some form of XPATH (e.g., directly express that you want to use the output of the previous javac task as the input to the jar process as opposed to coincidentally mentioning the same string in both places). Unfortunately, which the resulting data model is considerably better from a capturing the intent point of view, it quite frankly sucks from a usability point of view. - Availability flags. This is part of the "evil" conditionals described below. - Miscellaneous. Project names, versions, timestamps, and the like. I never got here as I gave up on paths, but my feeling was that if we could come up with something better for the above cases, perhaps we could leave these as properties for now... >Command line defined props *and* system properties should take preference >over any prop defined in the build.xml file. I agree. And properties passed from a parent project should override the properties in a subproject. There are bugs in this area - I can't override dist.dir in jakarta-taglibs for example and have it still take effect in jspspec. >Conditionals in the targets are not clear and clean. bleck. Targets should >just be able to define dependancies with the logic in the tasks (even if the >logic is defined with script instead of a class). Much as I like scripts, I want to resist making them *required* as long as humanly possible. And I view conditional compilation as a necessary core requirement. At the moment, I feel that optional excludes are less evil than optional tasks (contrast ant's build.xml to cocoon's). >So, really I need to shut up and put together that document and then there >will be a exposition of what I think and then people can either use it or >not. :) I'm actually thinking that if each of us puts down some random thoughts (like the ones I just put down above), it might spark an idea that catches on. Then again, probably not. - Sam Ruby
