----- Original Message ----- From: "Kurt Huwig" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 16, 2001 10:57 PM Subject: Ant2 suggestions
> [...] > So, comparing just the dependencies, make is more powerful than ant, but this > is not all ;-) I've never hacked much makefiles myself as NeXT's ProjectBuilder was better at this than me,but I can't see why make would be more powerful than Ant just because the rules are specified differently. I really like the fact that I tell Ant 'I want this. To get this do foo, bar and baz. To get foo do...' . Can you explain what nifty feature I should be missing in Ant that makes my life misarable? > [..] > make was written for C programs and deals very badly with directories. Most of > the time, each directory needs its own makefile. I must have been abusing make, we had only one makefile per project and we've always used sub-directories quite a lot. > I like to reduce problems to the very necessary, > because I don't want to learn much. Everything should be as intuitively as > possible. Laziness is a virtue when programming. However, what is intuitive differs per person and is largely based on past experiences. The biggest mistake is to use yourself as the center of universe. > 1. filesets > ------------ > Ant deals with file conversion. You have input files and outputfiles and tasks > what to do with them. Right now, both writing build.xml files and tasks > itselves it more complicated than necessary. > Each task can have input-files, output-files. Some of the build-in tasks just > need one of them, like 'mkdir' or 'delete'. Nethertheless, the syntax should > be similar, as it is obvious that 'delete' does not create files. > > A possibility would be> > <mytask in="...." out="..."/> > (this could also be 'from' and 'to') or Arguments names should be descriptive of what they are used for. If two tasks can share the same name, great, but don't enforce names. The names you've suggested seem a bit too general for me. > Right now, the semantics using several filesets is confusing. If you have > (version 1) > > [...] > then both 'a' and 'b' are sorted and given to the task as one fileset, thats > ok. But if you have (version 2) > [...] > then 'a' and 'b' are not sorted and given to the task in two separate calls as > two separate filesets. This is the same as (version 3) > [...] > and should not be like this, as I can write it like this if I want it. My > suggestion is: > > version 1: all files are sorted > version 2: files are sorted within the filesets, but not sorted across them and > given to the task as one large fileset > version 3: several filesets, several calls to the task > Could you explain what trouble it causes? Don't fix what isn't broken. > Additionally an option 'parallel="false"' that switches to 'one file at a time' > mode. Task specific, imho. > [...] > 3. fileset-code for tasks > -------------------------- > When writing a task, accessing the filesets and mapper is rather complicated. > Code like > > fs.getDirectoryScanner( project ) > > where 'project' is inherited from a super class is not very object oriented. What exactly is not 'object oriented' about this construct? The fact that a task inherits its project or that the fileset needs the project to setup the scanner? > Also, the files should be accessible as an 'Iterator' over 'File'. I tend to agree on this one. I think all objects that have a containment relationship with other objects should have an iterator. Unfortunately even Sun doesn't do this. Look for example at the Servlet API and in 1.4 the NetworkInterface class... > As there is only one fileset, the Iterator itself should be sufficient. Don't agree here. Use a collection. Collections can return iterators. Doesn't complicate things and doesn't force you into a specific way. [...] Maurice.
