Hi, I think that a nant task should live in nant. It gives the nant developers more choices if an external library decides to stop supporting (or just hasn't developed (-:) features that the nant community needs.
For instance if you do not like the fact that library x removed function y then either go with library z, or build function y into your code. If the external library has this control they are going to do the easiest thing and say that function y is no longer supported and force you to upgrade your existing code. Not to say that this will never happen in nant itself but at least there will be discussions (like this, which is very good!) to decide on the best course to take. I think it is a good rule of thumb to say: if the project wants it, then the project maintains it. In other words internalize as many dependencies as possible to minimize the risk to the project and the customer/ community using that project. Having said all that I did not intend to force the cvs task on anyone. I just thought that it was missing and wanted to add it (I actually wanted to port my ant cvs tasks to nant (-: ... and get draco.net working with my linux cvs repository). If it came down to a vote though, I would vote for adding it. Clayton -----Original Message----- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: June 8, 2003 6:27 AM To: Gert Driesen Cc: Clayton Harbour; [EMAIL PROTECTED] Subject: Re: [nant-dev] Nant cvs task using sharpcvslib > 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 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) 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. > 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. > 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 .... But we certainly can do for the core set of tasks. This is a part of almost every software development effort. 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 are > 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 ? Seems 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. 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
