> From: Peter Donald [mailto:[EMAIL PROTECTED] > > Consider this the last ditch effort ;)
OK, here is my last ditch response :-) > > I think it makes more sense for the source file to be designated > with file="" > attribute because that follows convention of rest of ant tasks. Any > objections to that? Well, it is only really true of the <copy> and <move> tasks. There are other tasks where this is not true. It is not true of the recent changes you made to Zip.java and its decendants, nor is it true for a task such as <echo>. So I don't really agree that this is a convention. It will also be very difficult to institute this convention in a backward compatible way since it reverses the meaning of existing attributes. > I would actually like to see this convention moved towards all > tasks in ant2 > .. for tasks like javac that have source files and destination files. So > instead of srcdir/destdir or whatever task-specific conventions > used we would > have dir (for srcdir) and todir (for destdir). I like conventions but I think we need to be careful about over abstraction. I like to think of the java task dealing with source. IOW, I think of compiling the source - not compiling a directory - if you know what I mean. I'm not convinced there is a benefit is making all tasks fit this "interface" > So what do you think ? Have I convinced you or do I have to go revert the > changes ? ;) > Well, you haven't convinced me, but in the end that isn't a huge deal. What I think we should do, before making further changes, is to have a discussion about the conventions we want to put in place and to where they should be applied. We might also consider the correlation between attributes and elements. For example, if you rename the srcdir attribute to "dir", what becomes of the <src> element - the relationship becomes more obscure. Then we should consider the backward compatability implications of this convention. We can't really make the file attribute of <echo> go from meaning destination to source easily. Finally, we should be consistent since the changes you made to Zip.java already violate the convention. Conor
