Groovy 1.5.6 is out!

Hi all,

G2One and the Groovy development team is pleased to announce the
release of Groovy 1.5.6, a bug fix release for the stable Groovy 1.5.x
branch.

A regression introduced in 1.5.5 was fixed, and 35 bugs have been
resolved (generics, MOP, and joint compiler issues, better line
information for IDE support, etc)

As usual, you can download the latest Groovy dustribution here:
http://groovy.codehaus.org/Download

And read the change log to know all the details there:
http://jira.codehaus.org/browse/GROOVY?report=com.atlassian.jira.plugin.system.project:changelog-panel

Enjoy!

--

-- 
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

    http://xircles.codehaus.org/manage_email

(Continue reading)

headers

Guillaume Laforge | 5 Apr 19:10

Fwd: final Groovy JSR?

Wasn't delivered.

---------- Forwarded message ----------
From: Bill Shannon <bill.shannon@...>
Date: Sat, Apr 5, 2008 at 12:40 AM
Subject: Re: final Groovy JSR?
To: Guillaume Laforge <glaforge@...>
Cc: jsr-241-comments@..., Groovy JSR <jsr@...>

Guillaume Laforge wrote:

>
> >  For example, do you expect people to write libraries using Groovy,
> >  which they would distribute as jar files?
> >
>
> Right.
> This has always been possible (as long as you have the Groovy runtime
> on your classpath).
>

 But what if the library is compiled by Foo's Groovy compiler and my
 program using the library is compiled by Bar's Groovy compiler?

 You have to decide whether this is important and/or likely.  I agree
 you can probably ignore this for the first version.

 Will this get any easier in Java SE 7 with the new dynamic language
 bytecode?

(Continue reading)

headers

Guillaume Laforge | 5 Apr 19:10

Fwd: final Groovy JSR?

Wasn't delivered.

---------- Forwarded message ----------
From: Bill Shannon <bill.shannon@...>
Date: Fri, Apr 4, 2008 at 11:59 PM
Subject: Re: final Groovy JSR?
To: Guillaume Laforge <glaforge@...>
Cc: jsr-241-comments@..., Groovy JSR <jsr@...>

Guillaume Laforge wrote:

> On Sat, Mar 22, 2008 at 8:24 PM, Bill Shannon <bill.shannon@...> wrote:
>
> > [...]
> >  You need a spec that's sufficient for someone else to implement
> >  Groovy support without reference to your code.  I don't know that
> >  much about Groovy, but you might want to split the spec into a
> >  language/compiler portion and a runtime portion (assuming runtime
> >  support beyond what's in Java SE is needed).
> >
>
> What do you mean by language/compiler portion, and runtime portion exactly?
> I just want to be sure I understood correctly.
> For the language part, we need to explain the semantics of the
> language, its grammar, etc.
> For the runtime part, you mean things like the libraries? ie. a
> closure class, a GString class, etc.
> Is that what you meant?
>

(Continue reading)

headers

Guillaume Laforge | 5 Apr 00:33

Re: final Groovy JSR?

On Fri, Apr 4, 2008 at 11:59 PM, Bill Shannon <bill.shannon@...> wrote:
> [...]
> > Back on the level of integration mentioned above, and on this
> > portability / interoperability aspect, Groovy mandates a seamless
> > integration with Java. But does it mean we'd also mandate a perfect
> > interoperability with other Groovy implementations?
> >
>
>  I think it would be better if you did, but it's up to you to decide.

Yes, for sure, conceptually speaking, this would be desired.
For Java, this is simpler as a call to a method is directly encoded in
the bytecode.
No intermediary layer of indirection.
It then just depends on the runtime part (JDK classes, third party
libraries, etc)
But for a dynamic language, in the bytecode you'll find some calls to
utility classes handling the double dispatch.
Some of them are public APIs (which will be part of the JSR), but
others may be present that are specific to each implementation.
So we'll have to think deeper as to what we really want to make portable or not.
Tricky issue 

> [...]
>  You're allowed to make that choice.  It's up to your expert group to
>  decide whether that's a good choice.  Personally, I think this might
>  be acceptable for a first release, but long term it will limit
>  acceptance of Groovy.  But you should work through the scenarios for
>  how you expect people to use Groovy to see if it will be an issue for
>  you.  For example, do you expect people to write libraries using Groovy,

(Continue reading)

headers

Guillaume Laforge | 4 Apr 23:41

Re: final Groovy JSR?

Bonjour Liz,

On Wed, Mar 26, 2008 at 11:37 AM, Liz M Kiener <Liz@...> wrote:
>
>  Bonjour Guillaume -
>
>  It has been a while since you took over this JSR and we corresponded last.
> Your next stage for this JSR is the EDR.  You should have seen email from me
> regarding any planned stages before JavaOne.

Alright, I saw it.
It'll take me some time to get the EDR finished, and it won't be before JavaOne.

> Will you make it to San Francisco for JavaOne?

Yes.

> The PMO will once again host an EG meeting room.

Yup, I saw that, this is handy.

> I am attaching the EDR presentation for you outlining the deliverables for
> submission to the PMO.  You may want to take the opportunity to put an
> update on the Community Update Page of the JSR and send me a schedule update
> for the JSR detail page.
>
>  If you have any questions please contact me.

Merci beaucoup

(Continue reading)

headers

Guillaume Laforge | 4 Apr 23:38

Re: final Groovy JSR?

Hi Bill,

Thanks a lot for your explanations.
I haven't been able to answer earlier, I'm sorry.

Some comments inline.

On Sat, Mar 22, 2008 at 8:24 PM, Bill Shannon <bill.shannon@...> wrote:
> [...]
>  You need a spec that's sufficient for someone else to implement
>  Groovy support without reference to your code.  I don't know that
>  much about Groovy, but you might want to split the spec into a
>  language/compiler portion and a runtime portion (assuming runtime
>  support beyond what's in Java SE is needed).

What do you mean by language/compiler portion, and runtime portion exactly?
I just want to be sure I understood correctly.
For the language part, we need to explain the semantics of the
language, its grammar, etc.
For the runtime part, you mean things like the libraries? ie. a
closure class, a GString class, etc.
Is that what you meant?

> Do you want someone
>  else to be able to implement a Groovy compiler that generates code
>  that works with your runtime?  And vice versa?  And if the Groovy
>  compiler or interpreter needs to be available to applications at
>  runtime, how does that work and what level of mix-and-match do you
>  want to support?

(Continue reading)

headers

Guillaume Laforge | 22 Mar 14:46

Re: final Groovy JSR?

Hello Bill,

On Fri, Mar 21, 2008 at 7:25 PM, Bill Shannon <bill.shannon-xsfywfwIY+M@public.gmane.org> wrote:

I see that the Groovy JSR has been going for about 4 years now,
and the implementation is up to version 1.5.x, but there's still
no Public Draft or Proposed Final Draft of the spec. When do you
expect to complete the JSR?

Very good question. Actually, after a long period of hibernation on the JSR front, we're resuming work on it in the upcoming months.

But we'd be happy to have some guidance to the steps to follow, and details of the key deliverables that are expected to ship with the JSR.

So far, the RI is there, of course, in the shape of Groovy 1.5.4.
The TCK is not split from the Groovy test suites, so we'd need to find an easy way for people to reuse it if they want to develop a compatible Groovy language.
On the spec side, we have the language grammar in an EBNF and diagram form, but what is still missing is the writing of the formal specification document, beyond our online documentation or the books we've written on the topic.

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

headers

Guillaume Laforge | 17 Dec 00:47

Tentative Roadmap

Dear Groovy developers,

Now that we have released 1.5, it is time to think about the future of Groovy, by discussing its roadmap.

After some discussions at GDC#4 ( http://docs.codehaus.org/display/GroovyJSR/GDC4+Discussions), on the lists, and elsewhere, we've listed possible improvements and new features.

Jochen and myself compiled a tentative roadmap this weekend, taking these ideas into account and trying to lay them out across potential release numbers.

This is a tentative roadmap.
Certain features can be discussed, whether we do want them or not.
And there's room for moving features from one to another release.
New ideas missing can also be introduced.
So it's still pretty open at the moment.

Note that the roadmap can change across the course of time according to the progress (or lack thereof) we make on the GEPs (Groovy Extension Proposals).
It is not set in stone today, even after our upcoming discussions. The GEPs will drive us through the releases.
It is very important that we try to clearly define what we want to do in the coming releases, and not just commit blindly any cool hacks :-)
We need to have crystal clear scope and semantics for all major features.

First of all, the basic idea: instead of one huge release a year with several betas and RCs, it'd be great if we could make more frequent releases (with a few betas and RCs) every two or three months or so, but containing a lower number of major features. So ideally, we could release 1.6 / 1.x throughout the year, with a bigger 2.0 at then end of next year with a reworked MOP system.

There are three main kind of releases:
- 1.5.x will provide some patches to the 1.5 final release
- 1.6 / 1.x will introduce a few major features at each release depending on the completeness of the GEPs
- and 2.0 will focus on the reworked MetaClass runtime system and will be worked on in parallel to the other 1.x releases.

Ideally, we should try to release 1.5.1 next week, before Christmas, with the current fixes for the Ant builder, the dead lock in the class loader.
And probably a 1.5.2 when we find the concurrency issue we have on parallel environments.

Without further ado, here's the proposed Roadmap.
The GEPs will be there for defining the exact scope of the major features by giving some finer-grained details of the content of the upcoming releases.
I'll publish this roadmap on the JSR wiki.

Groovy Roadmap

Groovy 1.5.1

Bug fix release
Deadlock in GroovyClassLoader
Problem with Ant tasks

Groovy 1.5.2

Bug fix release
Concurrency issues (unless it's fixed in 1.5.1)

Groovy 1.6

Based on JDK 1.5 with Retro* version available for JDK 1.4

Make sure we can run the unit tests with the retro-weaved jar to ensure compatibility

Annotation definition in Groovy

Currently, annotations can't be defined in Groovy, only used

Multiple assignment

GEP

Define the exact scope of multiple assignment by revisiting the existing GEP page

Groovy 1.7

Upgrade to ASM 3

if necessary or deemed useful (more efficient bytecode?)

Groovy incremental compiler

Especially useful for the Eclipse plugin

AST transformations

GEP

reuse of annotations or not
exact scope of those transformations

pluggable AST transformations for advanced DSL or integration cases

Groovy 1.8

Nested Classes & Anonymous Inner Classes

GEP

The exact semantics with relationship to the MOP should be properly defined through a GEP

Groovy 1.9

Upgrade to Antlr 3

We'll be able to use the tooling support accompanying Antlr 3

Concurrency features

GEP

Define what coverage we'd like to bring

Rollback the iterator features to properly discuss them first

Work on this theme first as a module, and if deemed right, we can bring it back to groovy-core

Groovy 2.0

New MetaClass system

Benchmark test suites to track progress of performance across releases
GEP

defining the scope of changes
describing the new system
proposals of a more homogeneous system

homogenize categories, EMCs, custom metaclasses

homogenize the configuration / declaration / convetions

have per-thread / scoped EMCs (like categories)

per-module/library metaclasses

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

headers

Guillaume Laforge | 9 Dec 16:25

What's new in Groovy 1.5?

Hi all,

After the announcement of the release of Groovy 1.5, as promised in
the release notes, here's a detailed article on what's new in Groovy
1.5.

Read it on InfoQ:
http://www.infoq.com/articles/groovy-1.5-new

--

-- 
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

    http://xircles.codehaus.org/manage_email

headers

Guillaume Laforge | 8 Dec 00:40

Groovy 1.5 is there!

Hi all,

I'm very pleased to announce the release of Groovy 1.5.

You can read the release notes there:
http://docs.codehaus.org/display/GROOVY/2007/12/07/Groovy+1.5+released

An upcoming article on InfoQ will give you a more in-depth overview of
this new version.

Thanks a lot to everybody: developers, contributors, users.
Without you, Groovy wouldn't be the great dynamic language it is today.

--

-- 
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

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

    http://xircles.codehaus.org/manage_email

headers

Guillaume Laforge | 2 Nov 20:09

Release candidate 2 is available!

Dear all,

The Groovy development team and G2One, the Groovy & Grails company, are happy to announce the new milestone of Groovy: the second release candidate is here. Just a few weeks after the first release candidate, this new version focused mainly on bug fixing, ironing out the Swing console with a nice new icon toolbar and the interactive shell, and the XML handling. You can have a closer look at the JIRA issues for more detailed information and you can download Groovy 1.1-rc-2 from the usual place.

Apart from these bugs and little improvements, we kept on increasing the performance of Groovy. As an informal benckmark, we measured the time taken by our test suites to run, and for instance, according to the Grails team, the Grails test suites executed about 40% faster with Groovy 1.1-rc-2 than with Groovy 1.1-rc-1, of course, depending on your project, your mileage may vary.

Please help us making sure Groovy 1.1 is rock-solid by having a run with this new release candidate in your projects, so that we can iron out the latest little problems that may arise. Thanks in advance for your help. Stay tuned for the final Groovy 1.1 release in a couple of weeks!

Download: http://groovy.codehaus.org/Download
JIRA issues fixed: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10242&styleName=Html&version=13792

--
Guillaume Laforge
Groovy Project Manager
G2One, Inc. Vice-President Technology
http://www.g2one.com

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31