Menu
▾
▴
RE: [Springframework-developer] Tests (groovy!)
|
From: Alef A. <al...@jt...> - 2004-07-23 17:41:12
|
I agree with not having Groovy dependent tests in the distribution = before 1.1 final. However I don't think it's much of a problem to keep = the Groovy tests in the test directory since they can be excluded using = the .groovy file extension, can't they? =20 So keep the groovy-build.xml around for the time being and move it over = to the build.xml file after 1.1? =20 Alef =20 =20 ________________________________ Van: spr...@li... namens = j=FCrgen h=F6ller [werk3AT] Verzonden: vr 23-7-2004 16:01 Aan: spr...@li... Onderwerp: Re: [Springframework-developer] Tests (groovy!) Sounds plausible! Still, for the time being, I'd prefer if our release = distributions don't have to include Groovy: i.e., our framework test = suite does not depend on groovy.jar. If we want to use Groovy for core = frameworks tests, let's do this after Spring 1.1 final (or at least, = after 1.1 RC1). Of course, groovy.jar can reside in our CVS lib directory; we just = wouldn't include in the release zip. However, Groovy-dependent tests = should preferably not reside in the "test" directory for the time being, = but rather in some separate directory that doesn't get included in = release zips. My main concern is to get 1.1 RC1 and 1.1 final out the door as soon as = possible, and to avoid anything that could potentially cause = complications. As we ship our tests, dependencies, and build scripts, = they should be considered in feature freeze mode too. Other opinions on this? Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Darren Davison Sent: Thursday, July 22, 2004 2:34 PM To: spr...@li... Subject: Re: [Springframework-developer] Tests (groovy!) > 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 = added 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 = test 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 = themselves > respectively run the test suite themselves. For 1.1, they should be = able > 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 = since 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 = bits 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, -- Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
