(the mail actually comes from the commons list, but Peter's comment seems the most appropriate one to reply to)
From: Peter Donald [mailto:[EMAIL PROTECTED] > At 03:14 2/5/01 -0700, Scott Sanders wrote: > >I will try and initiate that over on Ant-dev. My intention was to > >finish the functionality to enable the xpath task to make it > into the > >distribution, so an ant-sandox is appropriate. > > But remember that the main reason they are not in the ant project is > because the committers do not want them there and they think > it would be a > nightmare to support and pain for our users (especially in transition > between 1.x and 2.0). So realize that there may be a reason for it not > being done despite everyone thinking it would be a good idea > for ant2 ;) However, it is quite common for the ant commiter to respond to a request with "It is possible to write a task to do that, but it won't be part of ant" An AntOn/AntCallOn/Foreach task is a common example, and there are others. In the past month I think I have written 3 tasks, none of which I expect (or necessarily want) to see form part of the core/optional tasks, but which clearly support a defined use case from an ant user. I think it is quite reasonable to tell users, "We don't like that idea, but could implement a task for it yourself", but when there is no clear place to share those tasks, it's a bit hard. In the last 3 days, I've replied to at least 4 people's requests, saying "I wrote such a task - search through ant-dev". I don't think that's really a good situation. I have tasks that probably shouldn't be part of the support ant environment, but which other people want to use. Should I take these to sourceforge? Is that really the solution that people want? The commiters probably see less need for an "ant-contrib" module, since they can commit any task they think is useful, but it should be clear to all, that there are useful tasks that are not being accepted as part of ant. Even if these tasks don't fit the direct goals of ant, that doesn't mean they should be lost. Other than the adminstration difficulties of managing a new cvs module, what is the complaint against having a set of contrib tasks? It certainly seems better than the alternative.
