>Maybe, but then I'm not sure you realize about the problems of maintaining >these tasks. That's a huge problem and it has been discussed before, as a >user you would like all the tools you are using at time t to be available. >I'm a user as well that what I want. :) >As a committer you receive the aggregation of all the tools users are using
>at moment t. That's a lot and you have to make choice whether or not this is >important or not. These are valid points, however, in this particular instance I am of the opinion that the choice being made is wrong. VSS isn't exactly unusual. The patch to add 'Add' and 'CP' functionality is obviously a common requirement (especially given the numnber of times it has been submitted) - and the patch itself is trivial. To support 'checkin' and not 'add' is bizarre. It should either be added, or the rest of the VSS tasks dropped altogether. >Your example is actually a good one especially since it is a commercial >product. I will have to do the maintenance for all versions forever >because >I must take care of backward compatibility. See JUnit and JavaCC. There >are >probably others and that's what I will have to do as well for JProbe 4.0 >to >be released which has a different layout structure from 2.x/3.x. >Now multiply by the number of products out there that users 'use' and just >imagine the complexity if we had to maintain code for all versions of all products. >A good example would have been for example the VAJ tasks which as noted by >Jon were not compiling for more than 3 months but not a committer did have >the API at hands. What about testing things for example for weblogic 5.x and >6.x, Clearcase, VSS, Starteam, etc... >I'm sorry this is impossible to deal with dependency explosion. >So we have to make choice. Hard for some people, I agree. Ok, but the sad thing is that a huge wealth of volunteered, useful code is being lost. We already have optional components that can't be compiled without external jars. I'm not sure I buy the argument that finding a bug in some code for an external utility is significantly different from reporting a bug in the 'core' product, with the exception that only a limited number of people /may/ be able to fix it. But I do take your point about a dependency explosion. It doesn't matter how external tasks are shared - you are always going to have a problem testing them if you don't have the product. As a user, I'd be perfectly happy to take the health warning rather than not have the leg-up that having the task provides. As a developer, I'm willing to expend the effort to fix tasks for the products I use, and to feed those fixes back to the community. At the moment, I'm getting the feeling that it's a bit of a wasted effort. There must be a way of capturing this useful stuff! The first thing that would be useful is removing the special nature of the optional.jar file compared to 'taskdef'ed tasks. How far has this got? Nigel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
