Russel Winder wrote:
Hans,
There is a very serious issue here, it is the "conflict" between
traditional ways of packaging Java applications (which involves shipping
a full set of jars, at the risk of every application installing the same
jar to the system) and the managed installation (e.g. Debian, Ubuntu,
Fedora, RHEL, CentOS, SuSE, MacPorts) where the package manager
nominates which versions of things are installed and all applications
share the same jars.
For Debian and Ubuntu at least, installed packaged applications are
effectively forced to use the packaged versions of all dependencies. So
on Ubuntu Jaunty Groovy is 1.6.0.
Now on the one hand the Gradle team should not be worrying about this
sort of thing, but should just be putting out standalone distributions.
However, I do think it is a good idea if, in support of packagers, it is
proven that the product (in this case Gradle) does actually work with
the version of Groovy known to be on the system.
I agree. However, given that Gradle integrates so deeply with Groovy, in
practice it's a lot of work to support more than 1 version of Groovy
(for build files that is - Groovy projects are fine). I think there will
come a time when we will have to solve the multiple versions of Groovy
problem, but we should leave it for now. Provided, of course, that we
are pretty quick to move to the latest version of Groovy.
For Debian Unstable and MacPorts this is a fairly quickly moving target
for Ubuntu things are more rigidly timeboxed.
On Wed, 2009-06-03 at 10:15 +0200, Hans Dockter wrote:
On Jun 2, 2009, at 8:00 PM, Rene Groeschke wrote:
Hello folks,
I've just bumped the gradle macport portfile to gradle 0.6.1. This
port depends on the groovy - port 1.6.3, since it is build from the
source. I'm not sure if the port dependency to groovy 1.6.3 is
really nice here. I think most of the gradle users had installed
groovy without macports. Any recommendation to that? see http://trac.macports.org/ticket/19845
for further details.
Gradle ignores any installed Groovy version. It uses the one it comes
shipped with. This is important as Groovy is not necessarily 100
percent backward compatible, even for revision releases. Relying on
the installed Groovy version would seriously affect the Gradle user
experience. I'm not sure about the best way to use Gradle with package
managers in the future. The downside of our current approach is of
course the larger package size.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
