Simeon Fitch <[EMAIL PROTECTED]> wrote: > Apologies if this is outside the voting rules or not the issue being > resolved here, but some of these I've marked as -1 as I think they > should be "optional" tasks rather than core tasks.
Actually my +1s didn't mean I think that stuff belongs to core either, just that it would be fine with me if anybody implemented it ... >> * Add a JavaApply task that executes a given class with files from >> * a fileset as arguments - similar to <apply>. > > -0 (could apply be appropriatly modified to cover this case). probably - depending on what we come up with later, <apply> might no longer be necessary either. >> * make the default logger's output clear, informative, and terse. >> >> Actually, this is a little bit abstract, but doesn't apply to the >> core either. > > -1 (This is a task implementation guideline, not something that can > be implemented by the logging module; unless this is a veiled > commentatry about the "-emacs" feature. In that case my vote is +0). Yes, I think it was about the -emacs switch - anything else would be a guideline at best. >> * make PATH handling consistent. Every task that has a PATH >> * attribute must also accept references to PATHs. > > -0 (isn't this more of an issue of allowing references in all > attribute values, which I'd +1). we could make it that way - and might even be able to make the core do that for us. >> * URL-spider task that checks links for missing content or server >> * errors > > -0 (how is this different from the "reachable" task above. could > they be combined?) not too different. Apart from the spider part of this, a page would be reachable, even if it returned an internal server error. Stefan
