Hello:
I am writing a <depends> like task that does the same thing but for XML/XSLT
(where we have the same problem, in spades-- see my earlier postings on this).
Since many different "transformational" technologies (yacc/lex, javac, xslt, cc, etc. etc)
will likely have the same issue, can we __please___ rename <depends> to
something that indicates it is the "javac" flavor? Leaving <depends> as-is makes it
seem as if java compilation is hardwired in ant in some way. That is unfortunate, b/c
ant is way more generally useful than that.
The other option (genericizing the task until it can handle all possible flavors above)
seems too heavyweight, although we will probably find commonalities between the
flavors that can be factored out in time.
To be clear: I love the <depends> task, I am merely respectfully requesting that
the name be changed to better represent what it actually does.
--Craeg
Glenn McAllister wrote:
Conor MacNeill wrote:
So, I am +1 on integration, certainly making it optional. If it remains separate, and that seems likely, then perhaps it should be made a core task rather than being optional. It has no non-JDK dependencies.
Conor
I think I'm going to bow to the wisdom of others at this point. My biggest concern with integrating <depends> into <javac> was that it sounded like we were going to do away with depends as a separate task at the same time, and have no choice about running the integrated dependancy checking. I think I may have just misread the intent of the issue.
That being said, I'll change my -1 a +0. I don't think its necessary, but it sure as heck can't hurt if its optional and we don't do away with <depends>.
Glenn
