Message-ID: <1450346860.2285.1369290393406.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2284_243749727.1369290393406" ------=_Part_2284_243749727.1369290393406 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.=C2=A0 = This event was kindly sponsored by the Codehaus Foundation and the room boo= ked by Alexis Moussine-Pouchkine.
During this meeting, we followed the agenda outlined there.
The meeting has been productive and the resulting decisions will be explain= ed in the following sections.
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.
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:
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.
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.
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 enhancement is prov= ided, explain the way it solves a certain problematic, code samples, corner= cases, ideas for the implementation or even a prototype implementation as = far as possible.
The details of such a template for proposals should be provided soon.
We are going to reorganize the sources and tests to separate:
This also means we should separate more cleanly:
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.
Separating sources also means creating different artifact deliverables:<= /p>
Having a small groovy-core library is particularly interesting for those= wishing to integrate Groovy in their Java applications.
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.
The ASL 2 license has to be applied and enforced everywhere -- instead o= f copying the old BSD license again and again.=C2=A0
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.
A particular care should also be provided to improve the JavaDoc of the = core Groovy classes.
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.
Other facilities such as creating the distributions can potentially be h= andled differently (Gant or other).
The deliverables of JSR-241 consists of:
The RI has been released in the form of Groovy 1.0.
The formal grammar of the GLS has been generated out of the Antlr grammar.<= br /> 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 comm= ented 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.
"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.
The Groovy console and shell will be revamped to become even more user-f= riendly.
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.
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 p= roject will always stay compatible with bytecode for 1.4 JVMs, except for c= lasses annotated which will be compiled as bytecode for 1.5 JVMs.
Annotated classes will only be able to be compiled when the compiler is run= on a JVM 1.5, while the rest of Groovy classes will always be able to comp= ile and run both on 1.4 and 1.5 and beyond.
Specific test suites and probably DGM methods requiring a JVM 1.5 will be s= eparated and will not prevent anyone from using Groovy on a JVM 1.4.
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.
Enum will be supported, at least partially.
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).
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#.
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.
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.
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.
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.
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.
This section contains some additional information on what has happened a= nd been decided till the meeting.=C2=A0
Groovy will sports minimal generics support so that declarations like Li= st<Employee> adds the relevant reflective bytecode information needed= by frameworks like JPA.
Make map and closure coercion work also for classes and abstract classes= , and not only for interfaces.