Hi Peter,
On May 2, 2008, at 1:46 PM, Peter Niederwieser wrote:
hdockter wrote:
What I'm asking here is if you can provide such code ;). Or by what
other means can one recognizes which groovyc is used? I'm want to
release 0.1.4 within the next days and I would like to include this
feature.
Ok, here comes "detector 1.0". :-)
http://www.nabble.com/file/p17016198/detector-1.0.jar detector-1.0.jar
Simply put it on the compile classpath and then compile any groovy
code
(empty file is good enough).
If you get a message "groovyc version 1.6 (or higher) detected!",
you can be
sure that it's groovyc >= 1.6. If you don't get a message, then
either it's
groovyc < 1.6, or something about the global transform mechanism
has changed
(which might or might not happen until 1.6 final).
If you need something more elaborate than this (e.g. a unit test
that only
succeeds when compiled with >= 1.6), just let me know.
Thanks a lot. I will definitely use this for my unit tests.
I have figured out that setting the classpath in the taskdef of
groovyc has a lower precedence than the start classpath of Gradle.
This way I can't implement a user provided groovyc.
I see two other options right now:
One is using an customized internal groovy jar which does not include
groovyc. I don't like this solution too much. The other is using an
embedded script which calls groovyc and which has the user provided
groovy in its classpath. Can you think of another way of implementing
this?
The problem also goes beyond using groovyc. What about executing
parts of the groovy 1.6 stuff just builded? The user has to delegate
this execution to a separate script which is then executed with a
different classpath. This is not really convenient and Gradle should
offer something convenient for this. And finally, what about using a
different version of groovy for your actual build scripts.
The build scripts interact with the API of the gradle core to
configure the build. Right now this API includes the Groovy Closure
type. If we replaced the occurences of the closure type with an
suitable interface the API would be a pure Java API (implemented with
Groovy). But the build scripts right now use the same classpath as
the groovy core. With a suitable classloader setting we could
separate this. Then you could have build scripts with whatever groovy
version the user likes.
- Hans
P.S. I've put your personal email address in CC as Nabble has taken a
whole day to pick up my last postings.
Cheers,
Peter
--
View this message in context: http://www.nabble.com/Building-Groovy-
projects-with-Gradle-tp16926886p17016198.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
