|
From: Darren D. <da...@da...> - 2004-07-23 15:16:54
|
> 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 su= ite > 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, af= ter > 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 rele= ase > 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, t= hey > should be considered in feature freeze mode too. sounds fine to me. No-one's in any *need* of this after all - it was jus= t a way to make tests potentially easier to write and therefore more likely that people *would* write them. Given immature IDE integration and the additional learning curve, there's not even any guarantee that writing code in Groovy is going to be quicker than writing the equivalent, more verbose Java :) I'm happy to drop it altogether if there's not enough interest - at least we know it's simple to integrate should we choose to look at it again in the future. I still might look at the possibility of using Groovy (or other BSF script) as a bean definition language. This has cropped up on the lists before. Cheers! --=20 Darren Davison Public Key: http://www.davison.uk.net/pages/key.htm |