|
From: Darren D. <da...@da...> - 2004-07-22 12:34:10
|
> Darren, > > Are you modifying Spring's standard build process here? Will this make > Spring's standard build depend on Groovy? I feel that this is not too > appropriate given that we are about to release 1.1 RC1 within the next > couple of days. No it won't affect the build or make it depend on groovy. What I've done for now is to take a copy of build.xml (called groovy-build.xml) and adde= d the groovyc taskdef and task to the buildtests target in there while experimenting with it. In fact those are the only 2 changes required to the build to enable the whole process - it's pretty seamless. Nor have I modified any of the existing test classes, rather I've duplicated two tes= t classes, so in the tree for those 2 files only, a corresponding *Tests.groovy file exists alongside the *Tests.java file. If you build with build.xml, nothing unusual happens - any .groovy files in the tree are simply ignored by javac and junit. If you specify -buildfile groovy-build.xml then the groovyc task will compile *.groovy files to standard *.class files just as the javac task handles *.java files. The two languages can be mixed and matched seamlessly as the bytecode is standard. Once people have had a look at it, if it's something we want to use as an option then we'd modify the main build.xml as described - but that can be whenever. Of course at that point, any new tests written in groovy *would* have a dependency on groovy.jar but this is no more onerous than depending on any other jar. See below.. > I certainly don't object to doing tests with Groovy, but remember that = we > ship our build file and all libraries that we depend on in the > "-with-dependencies" download, so that people can build Spring themselv= es > respectively run the test suite themselves. For 1.1, they should be abl= e > to do this without Groovy, IMO. that's no problem, they can do that. The only dependencies when running tests written with groovy are: groovy.jar, which will be in /lib/groovy (it also contains the groovyc ant task) and asm.jar which we already depend on anyway. The junit side of things is completely unmodified sinc= e any tests written in groovy extend GroovyTest which in turn extends junit.framework.TestCase somewhere along the line. There's no requirement to install any of the groovy binaries or other bit= s and pieces you can download from them, even when writing and running groovy based unit tests - it's all pure java and all invoked via ant. If you're still not comfortable with it and want to hold off committing for a while, that's no problem at all. The _only_ impact it will have is adding a couple of hundred KB to the size of the release zip in practice, since it will just be "another jar file" and won't be implicated in anything the users want to do with the tests. > Sorry if I misunderstand something here... not at all - just let me know if you'd still prefer me to hold off? Best wishes, --=20 Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm |