ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nigel Magnay <>
Subject RE: [Bug 7153] - Need additional Microsoft Visual SourceSafe Ta sks
Date Wed, 20 Mar 2002 10:17:12 GMT

>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
>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
>I must take care of backward compatibility. See JUnit and JavaCC. There
>probably others and that's what I will have to do as well for JProbe 4.0
>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 
>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
>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?


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message