Can't there be tests written for antcall to pick this up? -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers
[EMAIL PROTECTED] wrote on 07/21/2002 02:27:11 AM: > > > For instance, the changes in property inheritance between projects > when you do > > sucessive project calls has broken a HUGE number of my build files. Almost > > universally I have a set of controller build files that in turn call worker > > build files that may in turn call other build files. > > It's very unfortunate those were not discovered _before_ releasing 1.5. > > IMHO this is a bug. > > We should fix it ( i.e. reverse the inheritance rules to 1.4 ) and release > a 1.5.1 that fixes this problem, it is serious enough. > > I tested all my 1.4 build files before 1.5 release, and Gump does a lot > of testing - but it seems this one didn't show up. > > Bugs happen, there is no way to avoid them. > > > To be honest I am getting very sick of updating the same ant filesover and > > over. Each release I have had to go through and make a large number of > > changes to builds to get things going again. I don't consider myself stupid > > or unknowledgable wrt Ant and thus I don't think it is a user error that is > > causing these constant incompatabilities. > > +1 > > Good thing that at least we don't have to rename attributes in the build > files. > > > > What I want to know is how we plan to fix it in the future. With > our current > > "system" I am not sure there is a clean or elegant method via > which we can do > > this. The only thing that I can think of is versioning the names of the > > tasks. > > No, there isn't. Testing is the only way to find bugs and regressions. > Maybe we can improve things - like make gump run closer to what the > project wants ( i.e. without full CLASSPATH, etc ). > > I partially agree with 'versioning', but the main goal should be to > preserve backward compatibility and use versioning only when there's > no way to keep backward compat. > > > > For instance we upgrade <antcall/> in an incompatible way then itstask name > > would become <antcall2/> etc. To avoid the pain of maintaining > separate tasks > > we could do something similar to the following in each task that changed... > > Or we add a an attribute to antcall to triger the different rules - with > default to the old behavior, I don't think we need antcall2 in this case. > > But the real question is if the new behavior is indeed that much better > than the old one. > > Costin > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> >
