Hi Sam, Thanks for the info, especially regarding the workaround. That will hold me over for now. Also, is there an online archive of this mailing list available anywhere?
I'd like to throw my two cents in about the language issue, if I may. I agree that you don't want Ant to become a general purpose programming language or anywhere near as complex and impenetrable as make (see footnote). However, I think it is also important not to be overly dogmatic about keeping all programming functionality out of Ant. If you require people to escape to an external scripting language in order to get any kind of programming functionality at all, then you run into problems of portability (unless you use Java itself) and language-specifice questions of how to access the values you generate in these embedded programmatic sections in order to affect the build process. The question then becomes where do you draw the line? That's always a hairy issue, but in my opinion I think you want to avoid the extremes. Ant already has some conditional 'programmatic' behavior based on the existence of properties, classes, or files. Extending that to include comparisons of property values is a rather small increase in complexity, but it handily addresses a large spectrum of build problems. To be honest, I guess I'm more in favor of putting more functionality into Ant. I like Ant because 1) it's Java, and 2) it's XML. For both of those reasons it is superior to make. I think it would be even better if Ant were able to address non-trivial build requirements. Sure, it may add complexity, but hopefully it could be designed as pay-as-you-go: the functionality is available, but it doesn't get in your way if you don't need it. Think about it - if Ant could succinctly handle complex builds, does that make it difficult to work with? Not necessarily. Does it make it derivative of make? No, because of 1) and 2). Anyway, that's just my opinion. Sorry if I'm reopening a can of worms. :-) Thanks, Edwin Footnote: I realized as I was writing this that it later sounds like I contradict my own statement. I thought I did too, at first, but this is how I reconcile it: Ant is always going to be build-specific, and in that sense will never be truly general-purpose, and the fact that Ant uses XML makes it already far superior syntactically than make. In any event, I still think Ant is cool. On Sun, 12 Mar 2000 [EMAIL PROTECTED] wrote: > > > Edwin Park wrote: > >Can ANT be used to build targets depending on the value of a particular > >property? For instance, I would like to have different build behavior > >depending on the value of the java.specification.version property. > > Be patient with us on this issue. > > I believe that everyone here agrees that that is a valid requirement, but > there is honest disagreement as to how to address it. Nobody wants Ant to > become a general purpose programming language or approach the complexity of > make. At the moment, we are in essense observing a "cease fire" on this > issue - but expect festivities to resume shortly. > > For my part, I would like to be able to see the equivalent of DHTML's: > > <script language="your_favorite_language"> your_code_here </script> > > Furthermore, I'd like to see a few more XML entities and/or attributes so > that the more common requirements could be handled without the need to > resort to this. > > For now, you can get a close approximation to what you desire with the > following: > > <available property="jdk11" classname="java.lang.Void"> > <available property="jdk12" classname="java.lang.ThreadLocal"> > <available property="jdk13" classname="java.lang.StrictMath"> > > Note that the property "jdk12" in this case actually means "jdk12 or > higher". > > - Sam Ruby > >
