James Duncan Davidson <[EMAIL PROTECTED]> wrote: > On 12/6/00 12:30 AM, "Stefan Bodewig" <[EMAIL PROTECTED]> wrote: > >> Jon Stevens <[EMAIL PROTECTED]> wrote: >> >>> Why are people submitting every task under the Sun to be included >>> with Ant? >> >> Because they want to use every tool under the sun with Ant and they >> don't have any influence on their tool developers. > > It was never intended that all tasks end up in Ant core.
We agree on that - I'm sure that you know that, just wanted to clarify that once again. My point was that currently you don't have too many choices if you want to distribute a task that is useful for many people. > AntEater allows for taskpaths to be set up to further enable > this... As I said later in my mail, Ant2 will be a totally different issue, be it AntEater or something different - the mechanism of easy tasklibrary deployment is something we have agreed upon long ago, we are just hashing out the details right now. >> Not sure whether POET would care about their developers that want >> to use Ant for example - but if one of them steps up and offers an >> open source solution to his fellow developers I won't be the one to >> reject him. > > It's not core though. It shouldn't be. What is "not core" in Ant 1.2, in Ant 1.3? Everything that's in ...taskdefs/optional, everything that is not in src/main or everything that is not in Ant's repository. If the answer should not be the first one, we'll end up in discussing which of the already present tasks should be core and which should be not. Do we really need this right now, when we know the problem will be solved in Ant2? >> Ant has become that successful that people are going wild and add >> tasks for everything. This is great. > > It is great. However, there are two bad influences at work here -- > 1) Everybody has a neat way to further extend the relatively simple > yet power concept of mapping the XML data files into tasks and How so? Either I haven't seen this or I don't understand it. > 2) people see this simple thing as something that can be further > abstracted out into something more. If we have a clear separation of Ant's core classes and the frontend, it should be quite easy to build several types of "something more" on top of Ant - but I sure wouldn't want to put all these additional things into Ant. Having a clear separation between Ant's business logic and the frontend is another thing we already have agreed upon for Ant2. Stefan
