Part of the problem depends on how much time developers are willing to wait for a jar build. The time necessary to clobber, then copy, alter, recompile the new source, and then package a 'production' build - the build that you are supposed to run your tests against - may increase dramatically.
Can we quantify this? In my environment, it takes under 2 minutes for the complete ant clobber/ant all/ant buildjars step. Given that derbyall takes 4 hours, 2 minutes is nothing. Even if it triples, say, to 6 minutes, it would still be nothing. I'm just trying to say that it's hard to see build time as a problem right now, particularly if what we're talking about is "the build time before you run derbyall". If *every* routine development build increased dramatically in time, that would be more frustrating.
another factor is how well these source modifications work with IDEs that don't have knowledge of Ant or the source modifications for a production build.
This seems *much* more important to me. IDE productivity is key.
In the past, I've seen serious problems occur because of a disconnect between development and production builds. So, I think we should consider introducing any differences between the development and production testing environments very carefully.
100% agree, especially given the roller-coaster ride that Andrew and I experienced with the sysinfo changes and how sensitive they were to the various different runtime configurations (classes, jars, different classpath orders, etc.). thanks, bryan
