Yes Ant indeed does ship with cvs tasks, but the reasons for that probable are :
- backward compatibility - lack of third party libraries that include such a task
no - it ships for the same reason they ship the copy task - because lots of people want it and
its totally unreasonable to expect cvs developers to maintain the Ant cvs task. Ant calls the cvs executable rather than
using a library which is the only reason we are having this conversation. If Clayton's tasks did the same would you suggest we ask the developers of cvs to maintain the cvs task ?
I still respectfully disagree. #cvslib is a library that encapsulates cvs functionality just as ziplib is a library that encapsulates zip functionality. If an IDE project wanted to use #cvslib you would expect them them to call the library from their code - not to ask the library writer to create a special layer for them. Should we ask microsoft to maintain the copy task so that when a new version of the framework is released we don't have to re-code - OK thats going a bit far but the principle is the same.I do agree that its very useful to have support for cvs out of the box, but perhaps that could be accomplished by including #cvslib (which itself can then include the cvs nant tasks)
> not saying that what I want
is best, but it certainly doesn't hurt to disucss such things ...
which we are doing. Saying I don't agree is not the same as saying we shouldn't talk about it.
But we certainly can do for the core set of tasks. This is a part of almost every software development effort.I would find it appealing to just being able to plugin a new version of #cvslib and at the same time get the corresponding nant tasks .... we'll never be able to keep up with the functionality third party libraries offer if we include tasks for them ourselves ....
If you use external libraries you have to deal with updating to new versions at some stage. I don't see our case as any different.
Having said that I totally agree that we shouldn't move tasks for *all* scms into our core - the developers who need them will write and maintain them and in some cases those developers will also be the authors of the external systems.
how will we cope with attributes, element, or even enum values that areSeems to me that this is the same issue you run into whenever you use someone elses library. If we need to updrade to a new version we make the required code changes, ship the new version of the library and move on. And since we do ship those libraries we control which version is used. How often do you expect ziplib or #cvslib to change once they are stable ? its not like the cvs api is changing rapidly these days.
supported with one version of the library and not with another ? wouldn't
it be better to just move this stuff to the thid party library itself, where
possible ?
ofcourse not every vendor will be interested in providing NAnt
tasks for its products, but as NAnt gains popularity more vendors will be ... until then, we could provide tasks ourselves ofcourse ...
But I don't think it would hurt to discusss this with the #cvslib, NDoc, NUnit (...) teams ...
yeah - and them impose *our* task writing standards on the authors of those projects ? If we change the way tasks are laid out do we wait for the NUnit developers to write a new version of the task before we can release ? NUnit and NDoc tasks have been included in the core becuase they are deemed highly useful - and we use them in our own build process. If we include them in the core then it is our responsibility to maintain them.
Ian
------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. _______________________________________________ Nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
