Building Groovy projects with Gradle

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Building Groovy projects with Gradle

Peter Niederwieser
Hi,

is it possible to point Gradle to the Groovy installation to use for building (compiling+testing) Groovy projects, e.g. to my own working copy of groovy-core? If yes, will this work even in cases where Gradle itself depends on another version of Groovy?

Thanks,
Peter

PS: I'm reposting because I inadvertently posted to the parent forum before.
Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

hans_d
Administrator
Hi Peter,

nice to see you on the list. I have been impressed by the quality of your postings to the Groovy list :)

On Apr 27, 2008, at 8:47 PM, Peter Niederwieser wrote:

Hi, 

is it possible to point Gradle to the Groovy installation to use for
building (compiling+testing) Groovy projects, e.g. to my own working copy of
groovy-core? If yes, will this work even in cases where Gradle itself
depends on another version of Groovy? 

The Groovy version used by Gradle is separated from the Groovy version you use for the Groovy projects build by Gradle. In fact, you even have to specify a Groovy library for building your Groovy code. The groovyc though comes from the internal Groovy shipped with Gradle. 

There are many ways to specify the source for the libs your projects needs. Conceptually these sources are always repositories. Such a repository can be the remote maven repository, but it can also  be folder on ypur hard disk. For the latter you can say:

dependencies {
   addFlatDirResolver('gradleResolverName', new File('location1'), new File('location2'))
   compile ':groovy-all:1.5.5'
}

The flat dir resolver ignores any group attribute you would need to find libraries in a Maven repository. Therefore you don't need to specify them, you have a leading ':'. This resolver just looks for jars in the specified folder according to the pattern:

groovy-all-1.5.5.jar

- Hans

--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

Peter Niederwieser
hdockter wrote
nice to see you on the list.
The groovyc though comes from the internal Groovy shipped with Gradle.


My project needs a Groovy 1.6 compiler. Does this mean I'm out of luck?

Cheers,
Peter
Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

hans_d
Administrator
Hi Peter,

On Apr 30, 2008, at 2:34 AM, Peter Niederwieser wrote:


hdockter wrote:

nice to see you on the list. 

The groovyc though comes from the internal Groovy shipped with Gradle.


My project needs a Groovy 1.6 compiler. Does this mean I'm out of luck?

Not necessarily. 

There is one build configuration for Gradle at http://teamcity.jetbrains.com/ I have installed yesterday. It uses the groovy-all-1.6-beta1.jar of the latest successful Groovy build (Groovy is also build there).

If this build were successful, you could download the Gradle with Groovy 1.6 distribution from teamcity. Unfortunately this build is failing due to a bug in Groovy 1.6:


I don't know if this is the only problem Gradle has with Groovy 1.6. We won't know until this Groovy bug is fixed.

There might be another possibility for just using the groovyc 1.6 by creating a new taskdef for groovyc with the 1.6 classpath. I don't know if this is possible when Groovy 1.5.5 is also in the Ant classpath.

I'm going to give it a try later.

- Hans


Cheers,
Peter
-- 
Sent from the gradle-user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

Peter Niederwieser
hdockter wrote
If this build were successful, you could download the Gradle with  
Groovy 1.6 distribution from teamcity.
This would be good enough for me as an interim solution.

hdockter wrote
There might be another possibility for just using the groovyc 1.6 by  
creating a new taskdef for groovyc with the 1.6 classpath. I don't  
know if this is possible when Groovy 1.5.5 is also in the Ant classpath.
If Gradle wants to become an attractive and reliable choice for building Groovy projects (and I'm sure it does!), it's really important that it completely separates the Groovy distribution used internally from the Groovy distribution used to build a project. In my opinion there shouldn't even be an option to build using the internal distribution - such a coupling is just too evil.

Cheers,
Peter
Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

hans_d
Administrator

On Apr 30, 2008, at 7:06 PM, Peter Niederwieser wrote:


hdockter wrote:

If this build were successful, you could download the Gradle with  
Groovy 1.6 distribution from teamcity.


This would be good enough for me as an interim solution.


hdockter wrote:

There might be another possibility for just using the groovyc 1.6 by  
creating a new taskdef for groovyc with the 1.6 classpath. I don't  
know if this is possible when Groovy 1.5.5 is also in the Ant classpath.


If Gradle wants to become an attractive and reliable choice for building
Groovy projects (and I'm sure it does!), it's really important that it
completely separates the Groovy distribution used internally from the Groovy
distribution used to build a project. In my opinion there shouldn't even be
an option to build using the internal distribution - such a coupling is just
too evil.

I agree. In fact this is the case right now except for the compiler. I just haven't thought about it properly. As Russel pointed out in the other thread, what I'm interested in is code that gives evidence whether it is compiled with groovy 1.6 or not, because of possible classpath issues.

I want to add a default groovy configuration to the dependencies of a Groovy project.

Users can add to it the groovy jars with all the libraries they need. This configuration is extended by the compile configuration. The groovy configuration will be also used for getting the groovyc. I'm wondering if there should be a convenience behavior, which detects GROOVY_HOME and uses the jars from there if nothing else is specified. 

- Hans


Cheers,
Peter

-- 
Sent from the gradle-user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

hans_d
Administrator
Hi Peter,

On May 1, 2008, at 8:32 AM, Hans Dockter wrote:

On Apr 30, 2008, at 7:06 PM, Peter Niederwieser wrote:


hdockter wrote:

If this build were successful, you could download the Gradle with  
Groovy 1.6 distribution from teamcity.


This would be good enough for me as an interim solution.


hdockter wrote:

There might be another possibility for just using the groovyc 1.6 by  
creating a new taskdef for groovyc with the 1.6 classpath. I don't  
know if this is possible when Groovy 1.5.5 is also in the Ant classpath.


If Gradle wants to become an attractive and reliable choice for building
Groovy projects (and I'm sure it does!), it's really important that it
completely separates the Groovy distribution used internally from the Groovy
distribution used to build a project. In my opinion there shouldn't even be
an option to build using the internal distribution - such a coupling is just
too evil.

I agree. In fact this is the case right now except for the compiler. I just haven't thought about it properly. As Russel pointed out in the other thread, what I'm interested in is code that gives evidence whether it is compiled with groovy 1.6 or not, because of possible classpath issues.

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.

- Hans



I want to add a default groovy configuration to the dependencies of a Groovy project.

Users can add to it the groovy jars with all the libraries they need. This configuration is extended by the compile configuration. The groovy configuration will be also used for getting the groovyc. I'm wondering if there should be a convenience behavior, which detects GROOVY_HOME and uses the jars from there if nothing else is specified. 

- Hans


Cheers,
Peter

-- 
Sent from the gradle-user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:




--
Hans Dockter
Gradle Project lead





--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

Peter Niederwieser
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". :-)
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.

Cheers,
Peter


Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

hans_d
Administrator
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". :-)

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 



-- 
Sent from the gradle-user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

Peter Niederwieser
hdockter wrote
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.
And I'm afraid it won't really solve the problem. As long as an Ant task might see ANY class from Gradle's internal Groovy jar, we're in danger.

hdockter wrote
 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?
I don't know how you integrate with Ant, but isn't it possible to completely seal off Ant tasks by means of a separate classloader?

hdockter wrote
And finally, what about using a different version of groovy for your actual build scripts.
I'd expect build scripts to be compatible with the Groovy version used internally by Gradle. Otherwise things might get too complicated.

Cheers,
Peter
Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

hans_d
Administrator

On May 2, 2008, at 4:28 PM, Peter Niederwieser wrote:


hdockter wrote:

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.


And I'm afraid it won't really solve the problem. As long as an Ant task
might see ANY class from Gradle's internal Groovy jar, we're in danger.

right



hdockter wrote:

 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?


I don't know how you integrate with Ant, but isn't it possible to completely
seal off Ant tasks by means of a separate classloader?

I've worked on this more than a day. One thing is that the custom classloaders you define by yourself are always wrapped in an AntClassloader. And it looks as if the custom classloaders you pass with loaderref to a taskdef are not used in a dynamic way. I succeed in the way that groovyc-1.6 was used for compiling. But then I got classcast exceptions due to incompatible versions of groovy classes. This is no fun.

I'm using a different approach now which works. I have to update the user's guide. This evening to tomorrow there will be a 0.1.4 release containing the new functionality.

I would like to use your detector for an integration test. This integration test would be a multi-project build where detector would be build in one project and the test groovy project would depend on this. Is it possible for you to send the sources of the detector? Would you put them under Apache v2?



hdockter wrote:

And finally, what about using a different version of groovy for your
actual build scripts.


I'd expect build scripts to be compatible with the Groovy version used
internally by Gradle. Otherwise things might get too complicated.

As we think about offering additional languages to Groovy for the build scripts we anyway need a very strong decoupling. Anyway, this is  not on the agenda right now.

- Hans


Cheers,
Peter

-- 
Sent from the gradle-user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

Peter Niederwieser
hdockter wrote
I'm using a different approach now which works. I have to update the  
user's guide. This evening to tomorrow there will be a 0.1.4 release  
containing the new functionality.
Great! Can't wait to switch to Gradle.

hdockter wrote
I would like to use your detector for an integration test. This  
integration test would be a multi-project build where detector would  
be build in one project and the test groovy project would depend on  
this. Is it possible for you to send the sources of the detector?  
Would you put them under Apache v2?
Oh, I didn't include the source code? Sorry for that. Let me improve the transform a bit to better support test automation and post it here in an hour or two. It's only a few lines of code so I'd prefer to donate it as-is instead of putting it under a license, if that's OK for you.

Cheers,
Peter
Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

Peter Niederwieser
OK, here comes an IDEA project with two modules: "VersionDetector" (containing the transform) and "VersionTest" (dependent module containing the test). In your own build, make sure that VersionDetector/src/META-INF is copied to the output directory. Everything else is hopefully self-explaining.

Cheers,
Peter

PS: I'm on a business trip until Thursday and might not get a chance to watch the mailing list until then.

GroovycVersionDetector.tar.gz


Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

hans_d
Administrator
Hi Peter,

On May 4, 2008, at 6:38 PM, Peter Niederwieser wrote:

OK, here comes an IDEA project with two modules: "VersionDetector"
(containing the transform) and "VersionTest" (dependent module containing
the test). In your own build, make sure that VersionDetector/src/META-INF is
copied to the output directory. Everything else is hopefully
self-explaining. 

Cheers,
Peter

PS: I'm on a business trip until Thursday and might not get a chance to
watch the mailing list until then.

GroovycVersionDetector.tar.gz 

Thanks a lot for this. It is already part of the integration test suite of  0.1.4. You can find the detector in the distribution under samples/groovyproject. :)

- Hans




-- 
Sent from the gradle-user mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:




--
Hans Dockter
Gradle Project lead




Reply | Threaded
Open this post in threaded view
|

Re: Building Groovy projects with Gradle

hans_d
Administrator
In reply to this post by Peter Niederwieser
Hi Peter,

On May 4, 2008, at 4:01 PM, Peter Niederwieser wrote:


hdockter wrote:

I'm using a different approach now which works. I have to update the  
user's guide. This evening to tomorrow there will be a 0.1.4 release  
containing the new functionality.


Great! Can't wait to switch to Gradle.

Gradle has found a bug in groovyc beta 1. 


Using certain javac parameters leads to an exception. Therefore Gradle filters those parameters out right now. You can access this filter in your build script and change it if you need those parameters and work with a Groovy where the bug is fixed.

- Hans

--
Hans Dockter
Gradle Project lead