ivy jar not on classpath for newly created Grails Apps

I don't really know if this is an actual bug (from Grails own perspective).
Possibly it is not supposed to be needed by a grails app on its classpath (e.g. maybe it is logical for it to only be needed to do dependency resolution).

However, I do know that in Grails 2.0.2 build snapshot this unfortunately causes some of the STS test running infrastructure to break because:

To be able to make the test infrastructure work we need to make sure AST transforms related to @TestFor annotations are executed by Greclipse.
The behavior of the transform is dependent on having a grails.util.BuildSettings instance in BuildSettingsHolder.

Following a hint from Graem, I have a created a rather hacky solution that instantiates this class and initializes it to some degree based on project information from the Eclipse project.
This was just sufficient to make the AST transform run inside Greclipe and the test infrastructure work.

However, it seems that this is now again broken in 2.0.2 build snapshot.

The reason is that instantiating BuildSettings is failing because of a dependency on classes from the ivy jar which is not on the classpath.

java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        ...
	at org.codehaus.jdt.groovy.internal.compiler.ast.Grails20TestSupport.createBuildSettings(Grails20TestSupport.java:158)
	at org.codehaus.jdt.groovy.internal.compiler.ast.Grails20TestSupport.ensureGrailsBuildSettings(Grails20TestSupport.java:132)
	at org.codehaus.jdt.groovy.internal.compiler.ast.Grails20TestSupport.addGrailsTestCompilerCustomizers(Grails20TestSupport.java:100)
Caused by: java.lang.NoClassDefFoundError: org/apache/ivy/core/report/ResolveReport
        ...
	at grails.util.BuildSettings.<init>(BuildSettings.groovy:722)
Caused by: java.lang.ClassNotFoundException: org.apache.ivy.core.report.ResolveReport

Note: I don't think it was on the classpath before 2.0.2, but things worked because of another hack to work around this bug: http://jira.grails.org/browse/GPRELEASE-24

I.e. I had added some code to dig out the ivy jar from the grails install and add it to the classpath for Grails 2.0.0 and 2.0.1 projects.

I could do the same again for 2.0.2 projects as well. But the situation is getting a bit more complex (now Grails 2.0.2 plugin projects will usually get the jar already from
the release plugin's dependencies. Also it is hard to in general test whether the jar is there (STS really doesn't have a good way of predicting what version of the jar Grails would want to be using, nor in what precise location it would be living inside of a Grails distribution. E.g. I've notice that Grails 2.0.2 plugin project may actually end up the ivy jar from 2.0.1 install, presumably because that one was previously cached, and 2.0.1. and 2.0.2 are sharing caches.

So this is a very hacky and brittle solution that I will have to keep adding special cases to on each point release of Grails.

So... I was rather hoping that instead it would be ok to simply make sure that the correct ivy jar is on the classpath of any Grails project.
(In general, also any other jar dependency that's needed to be able to instantiate classes like BuildSettings... but I've already verified that ivy-2.2.0.jar is the only one that's
missing to make Grails test running in STS work again)