Bryan Pendleton <[EMAIL PROTECTED]> writes: >> 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.
If I only needed to do this once, and maybe whenever I touch a shared component, it would be ok. But if I'm forced to go through the this loop just to get updated jar files, then I'm sceptical. > 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 always run all tests against the jars (not just derbyall), and I build the jars so that I can distribute them to other machines and run my tests there. And then it IS a big difference between 2 and 6 minutes. > > 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. That would be the net effect for me. I would like a lean jar build that I can use during development. This target would build only the jars that need to be updated in the fastest possible time, preferably figuring out any dependencies so I wouldn't have to worry about having to run clobber. Before the final derbyall, I don't mind running a heavy target that builds everything... >> 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.). Exactly. A quickbuildjars target would have been awesome... -- dt
