> 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 files over 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 its task 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]>
