Earlier this week I ran into a situation using one of the NAntContrib tasks that led me to consider modifying the code, but I couldn't because the NAnt-Contrib source isn't in the 0.8.3 bundle -- only the binaries are. I was behind a firewall and couldn't check out the cvs tree. Eventually, I found cvsgrab which works great (accesses the repo via cvsview and allows you to do a cvs co) but I still don' t have the same version as the binaries. I want to offer a suggestion that builds include the NAnt-Contrib source in the NAnt releases, and not just the binaries. The Obsolescing NAnt-Contrib thread sorta hit home for me after this, and I wanted to add a few comments on the topic of the NAnt-Contrib project. For those sick of the topic, please feel free to ignore the rest of this email: Jean Rajotte: >i think we can accomplish your requirements w/o making nant-contrib >obsolete. I agree that the nant-contrib separation has value, and that the requirements mentioned can be met with obsolescing nant-contrib. And I also agree with those who have said nant-contrib has a way to go before its up to speed. But I don't think that nant-contrib as a way-for-developers-to-submit-tasks-outside-the-core-nant-tasks is equivalent to nant-contrib as a separate Sourceforge project. Why not simply create a sub-section of the nant sourceforge project to house the code for the nant-contrib tasks? While separate sf projects gives some of the benefits desired for conceptual separation, there are a number of drawbacks: 1) Marketing: People hear about NAnt, want to use NAnt, and then also have to hear about and have to investigate NAntContrib in order to be able to really use the tool. The set of those who investigate both will always be smaller than those who look into NAnt. This makes NAnt's adoption harder, and therefore less likely. 2) Learning Curve (related to #1): It might not seem like much, but for someone who has never heard of MAKE or Ant, let alone NAnt, have some work to do to grok how NAnt works. Having two projects to get their head around creates the perception of twice the work to do. NAnt's target audience (people in MS shops) are very likely to have to start at the bottom of this learning curve since they are used to using VS to do everything. 2) Support Overhead: Right now there is a lot of buzz on the NAnt project, but none on the NAnt-Contrib project. How many people are working on the NAntContrib sf project and not on NAnt? If the answer is "very few" or "none" then all you have done is double the number of projects that these contributors need to work on. A similar problem exists for users of the projects. 3) Versioning Issues: This has been brought up (and greatly improved) but it is still something that has to be managed -- and is made more complex -- than if the two were a single sf project, with a clearly defined separation. 4) SF Project Overhead: Releasing files, managing permissions, managing web pages, documentation, mailing lists, etc. All of this is work, and while any one of them might not be a big deal, they add up to a significant extra work. Why do it twice? 5) Corporate Adoption Overhead: Many corporate IT shops have to approve software before it can be used in the organization. Getting NAnt approved is tough enough as many shops are still ambivalent about open source. If they take the tack that each project is a separate product (and I have seen some do this) you have just raised the bar to adoption -- possibly beyond what is worth it for that organization. My suggestion is to keep NAnt-Contrib as a separate list of tasks -- even a separate mailing list -- but combine the sf projects, combine the repositories, and combine the builds and releases, managing the separation by standards and convention, not by sf project. OK, I will shut-up for now, but I am firmly in the camp that separate sf projects for NAnt and NAntContrib is bad for NAnt's adoption and use. So, until next time... ;-) Best, Bill William E. Caputo ThoughtWorks, Inc. -------- A Plan is a list of things that don't happen ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users
