installing gradle 0.6.1 using macports

View: New views
6 Messages — Rating Filter:   Alert me  

installing gradle 0.6.1 using macports

by RenŽé Gröschke :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.

to install gradle 0.6.1 via macports use the following command:

 > sudo port install gradle

if you already used macports to install gradle v. 0.6, you can upgrade  
to the newest version via

 > sudo port upgrade gradle


regards,

René

-----------------------------------
René Gröschke
rene@...
http://www.breskeby.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Re: installing gradle 0.6.1 using macports

by hdockter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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



Re: installing gradle 0.6.1 using macports

by RenŽé Gröschke :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Am Mi, 3.06.2009, 10:15, schrieb Hans Dockter:
>

> 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.

I noticed that gradle uses the own shipped groovy version in operational
mode. But in an infirmed moment I wasn't sure that gradlew hasn't external
dependencies when building gradle ;-) . I will remove the groovy dependecy
in the portfile.

regards,
René

-------------------
René Gröschke
rene@...



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

    http://xircles.codehaus.org/manage_email



Re: installing gradle 0.6.1 using macports

by Russel Winder-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.

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
>
>
--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder@...
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder


signature.asc (204 bytes) Download Attachment

Re: installing gradle 0.6.1 using macports

by Adam Murdoch-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



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



Re: installing gradle 0.6.1 using macports

by Russel Winder-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Adam,

On Thu, 2009-06-04 at 07:05 +1000, Adam Murdoch wrote:
[ . . . ]
> 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 Gant I ended up creating builds for Groovy 1.5, 1.6 and 1.7.  It
turns out that there is no need for version specific source except in
the unit tests, but there do need to be version specific compilations.
However the Gant source is way smaller and far simpler than the Gradle
source -- because Gant is basically very simple and doesn't actually
have to do much, whereas Gradle is a serious bit of work.

There is also a standalone distribution of Gant that includes the latest
release Groovy, in this case 1.6.3.

Actually I think supporting the Gant build and then applying this to the
Gradle build itself is a good use case for Gradle.

From what I can tell trying to do the Gant build in Ant would require
lots of macro magic where it is relatively straightforward in Gant using
functions and closures.  I guess I should try creating a GMaven build,
but I gave up on Maven even with all the effort Jason took to try and
sort me out a Maven build.

I haven't actually been able to follow up on all the idea people
presented some weeks ago on how to progress this build need using
Gradle.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:russel.winder@...
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder


signature.asc (204 bytes) Download Attachment