Can we go to Groovy 2.0?

[Dan Allen]

Can we shoot for Groovy 2.0 in Fedora 18? What about Fedora 17 updates?

Groovy 2.0 is a crucial evolution in this widely used language and, being
all about features first, we want Fedora to be the place to run it.

The 2.0 update is significant because it introduces a static typing mode,
allowing it to cater to both the dynamic language crowd as well as the
traditional Java crowd.

Of course, the big question for Fedora is backwards compatibility. Groovy
2.0 claims to be backwards compatible with 1.8. Hamlet D'Arcy had this to
say on the topic in an abstract for an article on Groovy 2.0 in NFJS, The
Magazine [1]:

"Don’t worry, the major release is backwards compatible with previous
Groovies. The 2.0 increment is earned because of the size and scope of its
biggest features: modularization, invoke dynamic support, and most
importantly an upgrade to the static type system. Groovy 2.0 will contain a
static type checker which validates your code as part of the compiler,
similar to what you’re familiar with from Java. The final class files and
bytecode produced is still the same as before, but with this feature you
have the safety you expect from Java with the conciseness and
expressiveness of Groovy."

Here's a detailed article published on InfoQ about what's new in Groovy
2.0. [2]

-Dan

[1] http://www.nofluffjuststuff.com/home/magazine_subscribe?id=31
[2] http://www.infoq.com/articles/new-groovy-20

[Johannes Lips]

Dan Allen wrote:
> Can we shoot for Groovy 2.0 in Fedora 18? What about Fedora 17 updates?

Hello Allen,

I am currently co-maintaining groovy and I of course saw the new update
as well. Although they claim all the changes are pretty minor and
nothing big, there is one thing preventing me from doing the update
right away. I tried that over the weekend but it was not possible.
The main reason is that they changed the whole build system from ant to
gradlew [1] and I have to find the time to adopt those changes.
Main problem would be to get gradle in fedora first and then it might be
possible to work on an update for groovy.
If there is another, easier way just let me know and I would be glad
implementing this.

Johannes

P.S.: Package review of gradle
https://bugzilla.redhat.com/show_bug.cgi?id=809950
[1] http://www.gradle.org/
> Groovy 2.0 is a crucial evolution in this widely used language and,
> being all about features first, we want Fedora to be the place to run it.
>
> The 2.0 update is significant because it introduces a static typing
> mode, allowing it to cater to both the dynamic language crowd as well as
> the traditional Java crowd.
>
> Of course, the big question for Fedora is backwards compatibility.
> Groovy 2.0 claims to be backwards compatible with 1.8. Hamlet D'Arcy had
> this to say on the topic in an abstract for an article on Groovy 2.0 in
> NFJS, The Magazine [1]:
>
> "Don’t worry, the major release is backwards compatible with previous
> Groovies. The 2.0 increment is earned because of the size and scope of
> its biggest features: modularization, invoke dynamic support, and most
> importantly an upgrade to the static type system. Groovy 2.0 will
> contain a static type checker which validates your code as part of the
> compiler, similar to what you’re familiar with from Java. The final
> class files and bytecode produced is still the same as before, but with
> this feature you have the safety you expect from Java with the
> conciseness and expressiveness of Groovy."
>
> Here's a detailed article published on InfoQ about what's new in Groovy
> 2.0. [2]
>
> -Dan
>
> [1] http://www.nofluffjuststuff.com/home/magazine_subscribe?id=31
> [2] http://www.infoq.com/articles/new-groovy-20
>
> -- 
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://google.com/profiles/dan.j.allen
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
> --
> java-devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/java-devel

[Aleksandar Kurtakov]

One more project lost for us thanks to gradle :(

Alex

----- Original Message -----
> From: "Johannes Lips" 
> To: [e-mail]
> Sent: Thursday, July 5, 2012 9:32:14 AM
> Subject: Re: [fedora-java] Can we go to Groovy 2.0?
>
> Dan Allen wrote:
> > Can we shoot for Groovy 2.0 in Fedora 18? What about Fedora 17
> > updates?
>
> Hello Allen,
>
> I am currently co-maintaining groovy and I of course saw the new
> update
> as well. Although they claim all the changes are pretty minor and
> nothing big, there is one thing preventing me from doing the update
> right away. I tried that over the weekend but it was not possible.
> The main reason is that they changed the whole build system from ant
> to
> gradlew [1] and I have to find the time to adopt those changes.
> Main problem would be to get gradle in fedora first and then it might
> be
> possible to work on an update for groovy.
> If there is another, easier way just let me know and I would be glad
> implementing this.
>
> Johannes
>
> P.S.: Package review of gradle
> https://bugzilla.redhat.com/show_bug.cgi?id=809950
> [1] http://www.gradle.org/
> > Groovy 2.0 is a crucial evolution in this widely used language and,
> > being all about features first, we want Fedora to be the place to
> > run it.
> >
> > The 2.0 update is significant because it introduces a static typing
> > mode, allowing it to cater to both the dynamic language crowd as
> > well as
> > the traditional Java crowd.
> >
> > Of course, the big question for Fedora is backwards compatibility.
> > Groovy 2.0 claims to be backwards compatible with 1.8. Hamlet
> > D'Arcy had
> > this to say on the topic in an abstract for an article on Groovy
> > 2.0 in
> > NFJS, The Magazine [1]:
> >
> > "Don’t worry, the major release is backwards compatible with
> > previous
> > Groovies. The 2.0 increment is earned because of the size and scope
> > of
> > its biggest features: modularization, invoke dynamic support, and
> > most
> > importantly an upgrade to the static type system. Groovy 2.0 will
> > contain a static type checker which validates your code as part of
> > the
> > compiler, similar to what you’re familiar with from Java. The final
> > class files and bytecode produced is still the same as before, but
> > with
> > this feature you have the safety you expect from Java with the
> > conciseness and expressiveness of Groovy."
> >
> > Here's a detailed article published on InfoQ about what's new in
> > Groovy
> > 2.0. [2]
> >
> > -Dan
> >
> > [1] http://www.nofluffjuststuff.com/home/magazine_subscribe?id=31
> > [2] http://www.infoq.com/articles/new-groovy-20
> >
> > --
> > Dan Allen
> > Principal Software Engineer, Red Hat | Author of Seam in Action
> > Registered Linux User #231597
> >
> > http://google.com/profiles/dan.j.allen
> > http://mojavelinux.com
> > http://mojavelinux.com/seaminaction
> >
> > --
> > java-devel mailing list
> > [e-mail]
> > https://admin.fedoraproject.org/mailman/listinfo/java-devel
>
> --
> java-devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/java-devel

[Dan Allen]

On Thu, Jul 5, 2012 at 3:46 AM, Aleksandar Kurtakov wrote:
> One more project lost for us thanks to gradle :(

There's no doubt, the adoption of Gradle has slowed down updates until the
packaging is complete. But, software is going to change, that's just the
nature of it. Nothing has been lost, we just have to rise together to the
new challenge. We could have said the same thing about Maven builds before
you all did the innovative work of integrating that into rpmbuild.

It's becoming very clear to me, though, that we need to get more
information out there (this list is as good as any) on the status of the
Gradle packaging. That will help everyone set schedules and expectations
better. Let's frame it as a challenge, not a problem.

-Dan

[Aleksandar Kurtakov]

----- Original Message -----
> From: "Dan Allen" 
> To: "Aleksandar Kurtakov" 
> Cc: "Johannes Lips" , [e-mail]
> Sent: Thursday, July 5, 2012 10:55:00 AM
> Subject: Re: [fedora-java] Can we go to Groovy 2.0?
>
> On Thu, Jul 5, 2012 at 3:46 AM, Aleksandar Kurtakov <
> [e-mail] > wrote:
>
> One more project lost for us thanks to gradle :(
>
> There's no doubt, the adoption of Gradle has slowed down updates
> until the packaging is complete. But, software is going to change,
> that's just the nature of it. Nothing has been lost, we just have to
> rise together to the new challenge. We could have said the same
> thing about Maven builds before you all did the innovative work of
> integrating that into rpmbuild.

Sadly to support Gradle new blood is needed as the current maintainers are having hard time keeping Maven+friends up to date.

Alex
> It's becoming very clear to me, though, that we need to get more
> information out there (this list is as good as any) on the status of
> the Gradle packaging. That will help everyone set schedules and
> expectations better. Let's frame it as a challenge, not a problem.
>
> -Dan
>
> --
>
> Dan Allen Principal Software Engineer, Red Hat | Author of Seam in
> Action
> Registered Linux User #231597
>
> http://google.com/profiles/dan.j.allen
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction

[David Walluck]

On 07/05/2012 04:26 AM, Aleksandar Kurtakov wrote:
> Sadly to support Gradle new blood is needed as the current
> maintainers are having hard time keeping Maven+friends up to date.

First, gradle requires a bootstrap process with an existing gradle
binary. I believe this is allowed in Fedora.

Second, I had some problems with the bootstrap producing invalid code,
so I came up with a two-stage bootstrap process which semms to work.

If it helps, here is a list of gradle BuildRequires so that you may see
any packages that aren't yet in Fedora. Note that some of these may be
optional if you do not need to package every plugin initially.

ant
antlr
apache-ivy
bnd1
bsh2
checkstyle
codenarc
commons-beanutils
commons-cli
commons-codec
commons-collections
commons-httpclient
commons-lang
docbook-xsl
dom4j
ecj3
gmetrics
groovy17
guava
jakarta-commons-io
jakarta-slide-webdavclient
jansi
jaxen
jboss-servlet-api_3.0_spec
jcommander
jetty6
jmock
jna
jnr-posix
jsch
jsp_2_1_api
jsr-305
junit4
jzlib
logback
maven2
maven-ant-tasks
nekohtml
objectweb-asm
objenesis
plexus-containers-component-annotations
pmaven
slf4j
snakeyaml
sonar
testng
xalan-j2
xhtmlrenderer
xmlunit
xslthl

[Carlo de Wolf]

On 07/05/2012 10:58 AM, David Walluck wrote:
> On 07/05/2012 04:26 AM, Aleksandar Kurtakov wrote:
> > Sadly to support Gradle new blood is needed as the current
> > maintainers are having hard time keeping Maven+friends up to date.
>
> First, gradle requires a bootstrap process with an existing gradle
> binary. I believe this is allowed in Fedora.
>
> Second, I had some problems with the bootstrap producing invalid code,
> so I came up with a two-stage bootstrap process which semms to work.

We should be able to bootstrap Gradle with any other build tool. 
Personally I think Ant is better, because of its simplicity.
It is just a matter of executing the right steps (which different build 
tools do with different efficiency.)

As always the issues that turn up are related to the dependencies. And 
in Gradle's case the dependency chain going from Gradle -> Groovy -> 
ObjectWeb-Asm.

To me the exit criteria of having a working Gradle is seeing Hibernate 4 
build. So if you can fire that up, then we have working bits. :-)

Carlo
> If it helps, here is a list of gradle BuildRequires so that you may see
> any packages that aren't yet in Fedora. Note that some of these may be
> optional if you do not need to package every plugin initially.
>
> ant
> antlr
> apache-ivy
> bnd1
> bsh2
> checkstyle
> codenarc
> commons-beanutils
> commons-cli
> commons-codec
> commons-collections
> commons-httpclient
> commons-lang
> docbook-xsl
> dom4j
> ecj3
> gmetrics
> groovy17
> guava
> jakarta-commons-io
> jakarta-slide-webdavclient
> jansi
> jaxen
> jboss-servlet-api_3.0_spec
> jcommander
> jetty6
> jmock
> jna
> jnr-posix
> jsch
> jsp_2_1_api
> jsr-305
> junit4
> jzlib
> logback
> maven2
> maven-ant-tasks
> nekohtml
> objectweb-asm
> objenesis
> plexus-containers-component-annotations
> pmaven
> slf4j
> snakeyaml
> sonar
> testng
> xalan-j2
> xhtmlrenderer
> xmlunit
> xslthl
> --
> java-devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/java-devel

[David Walluck]

On 07/05/2012 05:45 AM, Carlo de Wolf wrote:
> We should be able to bootstrap Gradle with any other build tool. 
> Personally I think Ant is better, because of its simplicity.
> It is just a matter of executing the right steps (which different build 
> tools do with different efficiency.)

Ideally, I suppose, but someone needs to write it. Worst case, one can
often call 'javac' directly to bootstrap.

But in the case of something like 'gmaven' where groovy is a first-class
citizen, you'd also have to worry about executing groovy scripts to
produce the .java code to compile.
> To me the exit criteria of having a working Gradle is seeing Hibernate 4 
> build. So if you can fire that up, then we have working bits. :-)

I am not sure if it's true in the community, but for the version of
hibernate that I worked with a gradle 'rc' version was required as 1.0
final had some API changes. Again, leave it to Java to make major API
breakages during an 'rc' since those letters apparently mean nothing.

[Aleksandar Kurtakov]

----- Original Message -----
> From: "David Walluck" 
> To: [e-mail]
> Sent: Thursday, July 5, 2012 5:07:50 PM
> Subject: Re: [fedora-java] Can we go to Groovy 2.0?
>
> On 07/05/2012 05:45 AM, Carlo de Wolf wrote:
> > We should be able to bootstrap Gradle with any other build tool.
> > Personally I think Ant is better, because of its simplicity.
> > It is just a matter of executing the right steps (which different
> > build
> > tools do with different efficiency.)
>
> Ideally, I suppose, but someone needs to write it. Worst case, one
> can
> often call 'javac' directly to bootstrap.
>
> But in the case of something like 'gmaven' where groovy is a
> first-class
> citizen, you'd also have to worry about executing groovy scripts to
> produce the .java code to compile.
> > To me the exit criteria of having a working Gradle is seeing
> > Hibernate 4
> > build. So if you can fire that up, then we have working bits. :-)
>
> I am not sure if it's true in the community, but for the version of
> hibernate that I worked with a gradle 'rc' version was required as
> 1.0
> final had some API changes. Again, leave it to Java to make major API
> breakages during an 'rc' since those letters apparently mean nothing.

I really hope that the potential packager will package the latest released version in order to prevent such incompatibility problems soon after the package is introduced.

Alex
> --
> java-devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/java-devel

[David Walluck]

On 07/05/2012 10:23 AM, Aleksandar Kurtakov wrote:
> I really hope that the potential packager will package the latest
> released version in order to prevent such incompatibility problems
> soon after the package is introduced.

IMO, gradle is a really bad idea/design. Instead of being declarative
like ant, it contains actual code to do the build (which seems
completely unnecessary and will tend to make every build different).

The code generally extends the gradle API, so if the gradle API changes,
and it does, all build files must be patched. I can say this was mostly
never a problem for ant, which also tried to retain backwards
compatibility for the most part.

[Aleksandar Kurtakov]

----- Original Message -----
> From: "David Walluck" 
> To: [e-mail]
> Sent: Thursday, July 5, 2012 7:04:35 PM
> Subject: Re: [fedora-java] Can we go to Groovy 2.0?
>
> On 07/05/2012 10:23 AM, Aleksandar Kurtakov wrote:
> > I really hope that the potential packager will package the latest
> > released version in order to prevent such incompatibility problems
> > soon after the package is introduced.
>
> IMO, gradle is a really bad idea/design. Instead of being declarative
> like ant, it contains actual code to do the build (which seems
> completely unnecessary and will tend to make every build different).

I can not agree more. I have never seen worse build system in Java land.

Alex
> The code generally extends the gradle API, so if the gradle API
> changes,
> and it does, all build files must be patched. I can say this was
> mostly
> never a problem for ant, which also tried to retain backwards
> compatibility for the most part.
> --
> java-devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/java-devel

[Andrew Dinn]

On 05/07/12 17:27, Aleksandar Kurtakov wrote:
> I can not agree more. I have never seen worse build system in Java land.

Given how many bad ones there are to choose from that is quite damning.

regards,

Andrew Dinn
-----------

[David Walluck]

On 07/05/2012 12:49 PM, Andrew Dinn wrote:
> On 05/07/12 17:27, Aleksandar Kurtakov wrote:
> > I can not agree more. I have never seen worse build system in Java land.
>
> Given how many bad ones there are to choose from that is quite damning.

Even granting that there are plenty of things to hate about, e.g.,
maven, the point is that there is a common lifecycle there at least.

The same goes for GNU autotools. It's not about how great it is, but
that nearly 100% of the time I feel I know how to build an autotools
project and I know what it will try to do on the system.

Now, we all want to go backwards and start writing our Makefiles by hand
making the same mistakes over and over again.

Wait, that's not good enough, since `make' is too declarative and
doesn't give me enough power.

I am the best programmer in the world, so I am not going to trust some
boilerplate code that somebody else wrote. I am going to need a full
scripting language for my build (or maybe even some compiled code once I
find that that a simple script is not powerful enough either) that calls
my 100 awesome functions that I wrote just to do a ``simple'' file copy.

[Carlo de Wolf]

On 07/05/2012 07:04 PM, David Walluck wrote:
> On 07/05/2012 12:49 PM, Andrew Dinn wrote:
> > On 05/07/12 17:27, Aleksandar Kurtakov wrote:
> > > I can not agree more. I have never seen worse build system in Java land.
> >
> > Given how many bad ones there are to choose from that is quite damning.
>
> Even granting that there are plenty of things to hate about, e.g.,
> maven, the point is that there is a common lifecycle there at least.
>
> The same goes for GNU autotools. It's not about how great it is, but
> that nearly 100% of the time I feel I know how to build an autotools
> project and I know what it will try to do on the system.
>
> Now, we all want to go backwards and start writing our Makefiles by hand
> making the same mistakes over and over again.
>
> Wait, that's not good enough, since `make' is too declarative and
> doesn't give me enough power.
>
> I am the best programmer in the world, so I am not going to trust some
> boilerplate code that somebody else wrote. I am going to need a full
> scripting language for my build (or maybe even some compiled code once I
> find that that a simple script is not powerful enough either) that calls
> my 100 awesome functions that I wrote just to do a ``simple'' file copy.
> --
> java-devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/java-devel

Noxius, the ultimate build tool. 
https://github.com/wolfc/jboss-noxius/blob/master/bootstrap/build.java

Comes with a working bootstrap as well. 
https://github.com/wolfc/jboss-noxius/blob/master/bootstrap.sh

As an extra bonus it can bootstrap a build too. 
https://github.com/wolfc/jboss-noxius/blob/master/bootstrap/bootstrap.java

Need I say more... :-D

Carlo

[Carlo de Wolf]

Sounds like a plan.

Can you pickup the latest from 
https://bugzilla.redhat.com/show_bug.cgi?id=809950#c15, build it on F17 
(or rawhide) and fire off a Hibernate 4 build?

I think we should just stick the issues we find into bz 809950, unless 
they are Hibernate 4 specific.

Carlo

On 07/05/2012 09:55 AM, Dan Allen wrote:
> On Thu, Jul 5, 2012 at 3:46 AM, Aleksandar Kurtakov 
> <[e-mail] > wrote:
> One more project lost for us thanks to gradle :(
>
>
> There's no doubt, the adoption of Gradle has slowed down updates until 
> the packaging is complete. But, software is going to change, that's 
> just the nature of it. Nothing has been lost, we just have to rise 
> together to the new challenge. We could have said the same thing about 
> Maven builds before you all did the innovative work of integrating 
> that into rpmbuild.
>
> It's becoming very clear to me, though, that we need to get more 
> information out there (this list is as good as any) on the status of 
> the Gradle packaging. That will help everyone set schedules and 
> expectations better. Let's frame it as a challenge, not a problem.
>
> -Dan
>
> -- 
> Dan Allen
> Principal Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://google.com/profiles/dan.j.allen
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
>
> --
> java-devel mailing list
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/java-devel

[Andrew Haley]

On 07/05/2012 08:13 AM, Dan Allen wrote:
> The 2.0 update is significant because it introduces a static typing mode,
> allowing it to cater to both the dynamic language crowd as well as the
> traditional Java crowd.

No!  Say it ain't so, Joe.  :-(

Andrew.