Message-ID: <317986873.707.1425582189756.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_706_1783349036.1425582189755" ------=_Part_706_1783349036.1425582189755 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The third Groovy Developer Conference took place in Paris, in Sun's offi= ces, on the 29th and the 30th of January 2007. = This event was kindly sponsored by the Codehaus Foundation and the room boo= ked by Alexis Moussine-Pouchkine.=20
During this meeting, we followed the agenda outlined there.
The meeting has been productive= and the resulting decisions will be explained in the following sections.= p>=20
First of all, we have decided to keep the current naming / number scheme= of betas and RCs. The number of betas and RCs hasn't been decided yet.= =20
The next major milestone will be 1.1 (and not 2.0 as we might have suppo= sed). We are aiming at releasing this 1.1 before the end of 2007, ideally i= n Q3. The next versions will thus be:=20
We might however provide some 1.x.y releases in case some critical bugs = are found that can't wait for the next major milestones.=20
So far, we haven't felt a strong need to create branches. We will contin= ue to work on SVN trunk to add new features as well as for fixing bugs. Thi= s will not complicate our work for dealing with different branches.=20
For further enhancements / additions / changes proposals, we should form=
alize them in the form of a dedicated document. Discussing such proposals i=
s often tedious on mailing-lists because we often miss the "big pictur=
e" or the tricky details, and the discussion might finish in a dead en=
The proposal should provide some context of why such an enhancemen= t is provided, explain the way it solves a certain problematic, code sample= s, corner cases, ideas for the implementation or even a prototype implement= ation as far as possible.
The details of such a template for proposals should be provided soon.=20
We are going to reorganize the sources and tests to separate:=20
This also means we should separate more cleanly:=20
Core languages classes are everything related to the core concepts of th= e language as well as the GDK. Library classes contain classes related to v= arious APIs like JMX, Swing, and such. While module content usually require= additional dependencies than the ones of the JDK and also usually follow t= heir own release cycle.=20
Separating sources also means creating different artifact deliverables:<= /p>=20
Having a small groovy-core library is particularly interesting for those= wishing to integrate Groovy in their Java applications.=20
Regarding the tests, we should separate the 1.0 tests in a dedicated fol= der, while creating new folders for including "Groovy in Action" = tests, new tests for 1.1 (with tests specific to Java 1.5 features), as wel= l as tests for the TCK of JSR-241.=20
The ASL 2 license has to be applied and enforced everywhere -- instead o= f copying the old BSD license again and again.=20
Despite the great progresses made on improving, adding new content, and = reorganizing the documentation, more care should be provided to the online = documentation in the future. Newcomers should easily find their way through= the website and should be able to get started quickly. Non-documented feat= ures should be identified and reported so that actions can be taken to impr= ove those areas.=20
A particular care should also be provided to improve the JavaDoc of the = core Groovy classes.=20
Our Maven 1 build system is very fragile and is too complicated to make = it evolve properly. Having suffered various pains with it in the past that = we don't want to enumerate here, and as we haven't got enough feedback from= Maven 2 projects for complex builds like Groovy's, we decided to take the = simplest possible path by choosing Ant as our new build system. We will pro= gressively create the most simplistic build that can possibly exist to buil= d the artifacts and pass the test cases, as well as providing reporting cap= abilities (test reports, coverage) for integration in our Continuous Integr= ation process. Users will also be able to very easily build Groovy themselv= es with raw Ant without having to install anything like Maven or other buil= d tool.=20
Other facilities such as creating the distributions can potentially be h= andled differently (Gant or other).=20
The deliverables of JSR-241 consists of:=20
The RI has been released in the form of Groovy 1.0.
The formal gra= mmar of the GLS has been generated out of the Antlr grammar.
The TCK = need to be forked from our test suites, with many additional tests added. The specification in itself will be generated automatically out of the= commented test cases and test suites from the TCK.
The Abstract Syntax Tree will be improved to provide better support for = tools, especially IDEs, and the "groovydoc" documentation tool. A= nd all help possible should be provided to teams working on IDE plugins.=20
"groovydoc" should as a first step be able to generate the Jav= aDoc documentation from the Groovy classes, but should eventually be able t= o generate documentation for both Java and Groovy classes so that inter-lin= ks can be created. More thoughts and discussions might happen to see whethe= r solutions could be found to document classes with dynamic behaviors, like= Builders or MetaClasses.=20
The Groovy console and shell will be revamped to become even more user-f= riendly.=20
The grammar will be cleaned up slightly to remove some artifacts of idea= s brushed during the past JSR meetings but which have never been implemente= d or have been rejected after discussions.=20
Groovy 1.1 will provide annotation support and will integrate seamlessly=
with Java 5's annotations.
Despite Groovy supporting this particular= Java 5 feature, the rest of the project will always stay compatible with b= ytecode for 1.4 JVMs, except for classes annotated which will be compiled a= s bytecode for 1.5 JVMs.
Annotated classes will only be able to be co= mpiled when the compiler is run on a JVM 1.5, while the rest of Groovy clas= ses will always be able to compile and run both on 1.4 and 1.5 and beyond.<= br /> Specific test suites and probably DGM methods requiring a JVM 1.5 wil= l be separated and will not prevent anyone from using Groovy on a JVM 1.4.<= /p>=20
It is important that Groovy stays compatible with 1.4 as much as possibl= e so that Groovy can still be used in corporate environment that have not m= ade the switch yet to more recent versions of their JVMs.=20
Enum will be supported, at least partially.=20
We may reserve ourselves the right to not provide all the extensibility = provided by Java Enums (particularly the capability to define behavior on E= nums).=20
While we usually avoid providing users with too many choices for impleme= nting a given thing, we listened to newcomers wishing to be able to copy an= d paste some Java code containing "old for loops". Groovy 1.1 wil= l add the ability to use classical for loops as provided by Java or C#.= =20
The ExpandoMetaClass pioneered by the Grails project will be introduced = in Groovy itself. By default, those MetaClasses should not be extensible by= default as they can be dangerous in case of concurrent access and shared e= nvironments.=20
Additionally, a new convention will be introduced to define a script cus= tomizing various MetaClasses. For instance, a script in the magic package: = groovy.runtime.metaclass.script can hold a script using ExpandoMetaClasses = to enhance other classes.=20
The experimental date / time / duration support of the GData module will= be back in the core so as to provide a nice syntax for dealing with date a= nd time handling. This will be based on the Java calendar class, as we don'= t want to add an additional dependency of the core on Joda-Time despite its= great merits. But the day JSR-310 finds its way into the JDK, we might cer= tainly upgrade our implementation to using this API, as the underlying impl= ementation should be transparent to the users.=20
While it is possible to call methods without parentheses for top-level s= tatements, it only works for methods with normal arguments, but not with me= thods taking named-arguments (map literal). To provide even more readabilit= y and expressivity, we decided to also allow to omit parentheses in that ca= se, to help with the definition of Domain-Specific Languages.=20
We consider adding the possibility of doing multiple assignments. Method= s returning lists could spread the elements of their list to multiple varia= bles at a time. This mechanism may even be used later in more complex scena= rios like retrieving groups from a regular expression.=20
This section contains some additional information on what has happened a= nd been decided till the meeting.=20
Groovy will sports minimal generics support so that declarations like Li= st<Employee> adds the relevant reflective bytecode information needed= by frameworks like JPA.=20
Make map and closure coercion work also for classes and abstract classes= , and not only for interfaces.=20