> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: > > >> Peter Vogel <[EMAIL PROTECTED]> wrote: > >> > Except that "parallel" in the sense of execOn simply says that > >> > it's ok to provide the whole fileset to the command at once, > >> > rather than running the command for each file. > > > > I think one of our worst decitions was to use "parallel" for the > > name of that attribute. > > Mea culpa. >
That's alright. I should have screamed at the time. But I kept quiet :-( > >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > >> > >> But you could only achieve the same as execon does if this string > >> representation is a space delimited list of absolute pathnames - > >> not the only reasonable choice for FileSet.toString(). > > > > I think this is the wrong approach because it puts too much > > dependency on surface syntax which can be OS dependant or what have > > you. > > I still think that execon is worth a task of its own, even if there > was a foreach task in core. > Oh, I have no problem with that. What I was trying to say is that if we were to have a general set oriented facility (lets not get hung up on iteration), and we want to be able to say "apply all at once" (aka "parallel") then I would not rely on the way the set is stringified. But one would need to provide a generic way for passing the individual parameters to the task. Like for example the meta-code calling createXXX() when a set of XXX is being passed. Looking at the code of <execon>, it does not rely on files being separated by spaces. What is does is pass each element in the fileset as a separate argument. It is upto the <exec> task to interpret them appropriatelly. The same would have to work on a generalized case. I will send another message with some more concrete ideas. Jose Alberto > Stefan >
