On 15/12/09 1:53 AM, Russel Winder wrote:
Hans,
On Mon, 2009-12-14 at 11:37 +0100, Hans Dockter wrote:
On Mon, Dec 14, 2009 at 8:19 AM, Russel Winder
<[email protected]> wrote:
On Mon, 2009-12-14 at 07:34 +0530, Roshan Dawrani wrote:
> Is there a gradle version(snapshot?) available that uses
groovy
> 1.6.5(+)? Or will I need to build it locally?
It seems there is an incompatibility between Gradle and all
Groovy
versions post 1.6.4. The sooner this is sorted and Gradle
uses 1.6.7
the better. Actually it would be even better if Gradle worked
with
whichever version of Groovy the user nominated -- I for one
want to use
Groovy 1.8-beta-1-SNAPSHOT.
I don't think this works out. It will be a maintainability nightmare.
See Grails, where a particular versions also uses a particular version
of Groovy, doesn't it?
Yes and no. The problem Gradle has is that the attitude of "we choose
which version of libraries to work with" leads to having decayingly old
versions of dependencies, cf. BND, Groovy -- because there is always
something with higher priority than dealing with the problems of
upgrading. So upgrades don't get done.
At some point soon, we will rework the plug-in stuff to let the build
author have some control over which version of a dependency is used:
http://jira.codehaus.org/browse/GRADLE-723
The core is a different matter. It would be nice to let you choose which
version of Groovy to use for build scripts, but it is just so much work
to support multiple versions of Groovy at the moment. I feel like we
have better things to do with our time at the moment.
There's also the issue of how to deal with a build where some bits need
one version of Groovy and other bits need a different version of Groovy
(eg I'm using 3rd party plugins which need some other version of Groovy
than what my build script needs). Having a fixed version of Groovy for a
given version of Gradle helps solve this problem. Maybe it is actually a
bad idea to offer multiple versions of Groovy for build scripts.
Finally, there's the question of how important this choice really is.
Are people actually running into Groovy bugs in their build scripts,
that are fixed in 1.6.5 and later, and for which there's no possible
work-around? If not, then there's no real reason to upgrade.
In the Python community, where they do not have the luxury of specifying
exact versions of things, people choose a lowest common denominator
language spec for their Python code and libraries and work to that using
CI servers to spot problems. To be honest despite the travails, their
code and algorithms are better Python systems than most Java/Groovy
systems are Java/Groovy systems.
It has been entertaining and enlightening trying to ensure Gant works
with the latest Groovy 1.5.x, 1.6.x and 1.7.x -- as is required for use
with Grails. The problems are the main code but the tests. These are
generally though easily handled.
So in principle there is a maintenance problem, but it is more perceived
than actual.
Oh, there's a very real maintenance problem. Each upgrade to Groovy
usually takes 2 or 3 days of my time to sort out. This usually involves
putting in work-arounds to problems, and these work-arounds are
generally version specific and incompatible with the work-arounds for
other versions of Groovy. To support multiple versions of Groovy at the
moment, we'd have to apply these work-arounds dynamically based on the
chosen version. I'm not even slightly interested in doing this.
I'm sure (well, hoping) that the effort to upgrade will improve over
time, and we will be able to move more quickly with Groovy releases, and
possibly offer the choice of Groovy version for build scripts.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
