Tim, From: "Tim Vernum" <[EMAIL PROTECTED]> > > 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.
I voted against this concept, not because I don't believe in a task-contrib area, but more because I think it is best to wait for Ant2 to provide the appropriate mechanisms for this sort of thing. Once something like this gets established, it is hard to take it away and say "Oh, we really should be doing it this way." In Ant2, adding tasks should be as simple as dropping in a .tsk file into the appropriate directory. In Ant 1.x, you have to deal with taskdefs, classpaths, changing defaults.properties, etc. That will add support load, even in an unsupported contrib area. So, as part of the Ant2 discussion, I voted to wait until Ant2 establishes the right infrastructure. However, I can also see your points. So, I change my -1 to a -0. If someone wants to setup and manage an unsupported ant-contrib area for 1.x tasks, go ahead. Conor
