Re: [Springframework-developer] Tests (groovy!)

[<jue...@we...>]

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,
--=20
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