Tentative Roadmap

[glaforge]

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

[Andres Almiray]

Looks great, specially the incremental compiler as we would definitely use it at work too.
I wonder where does handling private access fall? as well as possibly allowing < <= => > to be overridden independently of <=>

glaforge wrote:

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

[Alexandru Popescu ☀]

On Dec 17, 2007 1:50 AM, Guillaume Laforge <glaforge@...> wrote:

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

Firstly I would like to thank Mr.G and Jochen for setting up such a
detailed roadmap.

Now, I would like to add my opinion about it (opinion that might not
match exactly the above plan).

I do consider that the Groovy language has become "enough" feature
rich. IMO, the most important aspects for the future of the language
are now more in terms of usability. I don't think I can come out with
a nice proposal as you did, but my suggestion would be that the work
should focus on the following directions:

1/ fixing bugs related to the 1.5 major release. This will probably
result in a couple more minor releases.

2/ focus on the performance. As discussed at GDC this mostly means
rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
would definitely see the whole energy of the Groovy people going this
direction only for the next period.

Probably the only "new" feature that I see as belonging to "usability"
is the multi-assignment, but this is just a nice to have one, so it
shouldn't focus on it right away (or at least I wouldn't consider it
as a strict goal for the next immediate period).

Hope you don't mind expressing my thoughts here,

./alex
--
.w( the_mindstorm )p.

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

    http://xircles.codehaus.org/manage_email

[glaforge]

On Dec 17, 2007 10:25 AM, Alexandru Popescu ☀
<the.mindstorm.mailinglist@...> wrote:
> Firstly I would like to thank Mr.G and Jochen for setting up such a
> detailed roadmap.

You're welcome :-)

> Now, I would like to add my opinion about it (opinion that might not
> match exactly the above plan).

At least, it's not in contradiction with the roadmap!

> I do consider that the Groovy language has become "enough" feature
> rich. IMO, the most important aspects for the future of the language
> are now more in terms of usability. I don't think I can come out with
> a nice proposal as you did, but my suggestion would be that the work
> should focus on the following directions:
>
> 1/ fixing bugs related to the 1.5 major release. This will probably
> result in a couple more minor releases.

Agreed, this is what the 1.5.x releases are for.

> 2/ focus on the performance. As discussed at GDC this mostly means
> rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
> would definitely see the whole energy of the Groovy people going this
> direction only for the next period.

It's going to be a long process I suspect, as various experiments will
have to be done, lots of discussions, a nice general proposal of what
we really want, etc. So it's something that is going to be done in
parallel to the progress we make in 1.x.

> Probably the only "new" feature that I see as belonging to "usability"
> is the multi-assignment, but this is just a nice to have one, so it
> shouldn't focus on it right away (or at least I wouldn't consider it
> as a strict goal for the next immediate period).

I tried to put certain features at certain milestones, but we can
certainly reorder the priorities.
I've put multiple assignments early in the roadmap because we had
promised them in 1.1/1.5, but as they're certainly not critical, we
can postpone them to a latter release, it's not really critical.

In the new features, there are things which should be discussed for
inclusion or not.
For instance, anonymous inner classes, nested classes and co.
Initially, in the early days of Groovy, we didn't want to support them
because we found them ugly, and closures should be used more to fill
in the gap.
So, it's perhaps a debate we should have as to whether the Groovy
users really want them in the language?

Regarding other features, for instance AST Transformations, we can
already do that today, but in a more convoluted way (through the
Groovy classloader), so it's mainly about making this feature easier
to use. And for the concurrency feature, it could even just be an
additional module, instead of bloating Groovy core with yet another
big feature.

> Hope you don't mind expressing my thoughts here,

On the contrary, thanks for sharing your thoughts!

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

[tugwilson]

glaforge wrote:

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

Are any of these milestones going to introduce breaking changes? I'd imagine the new MetaClass work would do so.

John Wilson

[glaforge]

> Are any of these milestones going to introduce breaking changes? I'd imagine
> the new MetaClass work would do so.

Groovy 2.0 will definitely introduce breaking changes for people using
metaclasses, etc.
Groovy 1.x shouldn't introduce breaking changes though, except those
inconcistencies we may find along the way or as bugs are reported and
fixed.

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

[Alex Tkachman]

I 100% agree with you. Performance is weakest point of Groovy runtime.
Even with improvements we did in 1.5. As we said many times we can't
resolve it without full redesign of MOP. So, it should be priority
number one.

On Dec 17, 2007 12:25 PM, Alexandru Popescu ☀
<the.mindstorm.mailinglist@...> wrote:

>
> On Dec 17, 2007 1:50 AM, Guillaume Laforge <glaforge@...> wrote:
> > 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
> >
>
> Firstly I would like to thank Mr.G and Jochen for setting up such a
> detailed roadmap.
>
> Now, I would like to add my opinion about it (opinion that might not
> match exactly the above plan).
>
> I do consider that the Groovy language has become "enough" feature
> rich. IMO, the most important aspects for the future of the language
> are now more in terms of usability. I don't think I can come out with
> a nice proposal as you did, but my suggestion would be that the work
> should focus on the following directions:
>
> 1/ fixing bugs related to the 1.5 major release. This will probably
> result in a couple more minor releases.
>
> 2/ focus on the performance. As discussed at GDC this mostly means
> rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
> would definitely see the whole energy of the Groovy people going this
> direction only for the next period.
>
> Probably the only "new" feature that I see as belonging to "usability"
> is the multi-assignment, but this is just a nice to have one, so it
> shouldn't focus on it right away (or at least I wouldn't consider it
> as a strict goal for the next immediate period).
>
> Hope you don't mind expressing my thoughts here,
>
> ./alex
> --
> .w( the_mindstorm )p.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

[Alex Tkachman]

Regarding putting features like concurrency to in to additional module
I have absolutely vice versa suggestion. I think functionality like
Gant and good concurrency/actors package will not bloat Groovy but
provide best one shop expirience for Groovy users.

So I suggest to include Gant in to main Groovy distro. Of course, if
Russel and other Gant developers like the idea.

On Dec 17, 2007 12:40 PM, Guillaume Laforge <glaforge@...> wrote:

> On Dec 17, 2007 10:25 AM, Alexandru Popescu ☀
> <the.mindstorm.mailinglist@...> wrote:
> > Firstly I would like to thank Mr.G and Jochen for setting up such a
> > detailed roadmap.
>
> You're welcome :-)
>
> > Now, I would like to add my opinion about it (opinion that might not
> > match exactly the above plan).
>
> At least, it's not in contradiction with the roadmap!
>
> > I do consider that the Groovy language has become "enough" feature
> > rich. IMO, the most important aspects for the future of the language
> > are now more in terms of usability. I don't think I can come out with
> > a nice proposal as you did, but my suggestion would be that the work
> > should focus on the following directions:
> >
> > 1/ fixing bugs related to the 1.5 major release. This will probably
> > result in a couple more minor releases.
>
> Agreed, this is what the 1.5.x releases are for.
>
> > 2/ focus on the performance. As discussed at GDC this mostly means
> > rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
> > would definitely see the whole energy of the Groovy people going this
> > direction only for the next period.
>
> It's going to be a long process I suspect, as various experiments will
> have to be done, lots of discussions, a nice general proposal of what
> we really want, etc. So it's something that is going to be done in
> parallel to the progress we make in 1.x.
>
> > Probably the only "new" feature that I see as belonging to "usability"
> > is the multi-assignment, but this is just a nice to have one, so it
> > shouldn't focus on it right away (or at least I wouldn't consider it
> > as a strict goal for the next immediate period).
>
> I tried to put certain features at certain milestones, but we can
> certainly reorder the priorities.
> I've put multiple assignments early in the roadmap because we had
> promised them in 1.1/1.5, but as they're certainly not critical, we
> can postpone them to a latter release, it's not really critical.
>
> In the new features, there are things which should be discussed for
> inclusion or not.
> For instance, anonymous inner classes, nested classes and co.
> Initially, in the early days of Groovy, we didn't want to support them
> because we found them ugly, and closures should be used more to fill
> in the gap.
> So, it's perhaps a debate we should have as to whether the Groovy
> users really want them in the language?
>
> Regarding other features, for instance AST Transformations, we can
> already do that today, but in a more convoluted way (through the
> Groovy classloader), so it's mainly about making this feature easier
> to use. And for the concurrency feature, it could even just be an
> additional module, instead of bloating Groovy core with yet another
> big feature.
>
> > Hope you don't mind expressing my thoughts here,
>
> On the contrary, thanks for sharing your thoughts!
>
> --
>
> Guillaume Laforge
> Groovy Project Manager
> G2One, Inc. Vice-President Technology
> http://www.g2one.com
>

[glaforge]

No, we won't include Gant into Groovy.

On Dec 17, 2007 11:59 AM, Alex Tkachman <alex.tkachman@...> wrote:

> Regarding putting features like concurrency to in to additional module
> I have absolutely vice versa suggestion. I think functionality like
> Gant and good concurrency/actors package will not bloat Groovy but
> provide best one shop expirience for Groovy users.
>
> So I suggest to include Gant in to main Groovy distro. Of course, if
> Russel and other Gant developers like the idea.
>
>
> On Dec 17, 2007 12:40 PM, Guillaume Laforge <glaforge@...> wrote:
> > On Dec 17, 2007 10:25 AM, Alexandru Popescu ☀
> > <the.mindstorm.mailinglist@...> wrote:
> > > Firstly I would like to thank Mr.G and Jochen for setting up such a
> > > detailed roadmap.
> >
> > You're welcome :-)
> >
> > > Now, I would like to add my opinion about it (opinion that might not
> > > match exactly the above plan).
> >
> > At least, it's not in contradiction with the roadmap!
> >
> > > I do consider that the Groovy language has become "enough" feature
> > > rich. IMO, the most important aspects for the future of the language
> > > are now more in terms of usability. I don't think I can come out with
> > > a nice proposal as you did, but my suggestion would be that the work
> > > should focus on the following directions:
> > >
> > > 1/ fixing bugs related to the 1.5 major release. This will probably
> > > result in a couple more minor releases.
> >
> > Agreed, this is what the 1.5.x releases are for.
> >
> > > 2/ focus on the performance. As discussed at GDC this mostly means
> > > rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
> > > would definitely see the whole energy of the Groovy people going this
> > > direction only for the next period.
> >
> > It's going to be a long process I suspect, as various experiments will
> > have to be done, lots of discussions, a nice general proposal of what
> > we really want, etc. So it's something that is going to be done in
> > parallel to the progress we make in 1.x.
> >
> > > Probably the only "new" feature that I see as belonging to "usability"
> > > is the multi-assignment, but this is just a nice to have one, so it
> > > shouldn't focus on it right away (or at least I wouldn't consider it
> > > as a strict goal for the next immediate period).
> >
> > I tried to put certain features at certain milestones, but we can
> > certainly reorder the priorities.
> > I've put multiple assignments early in the roadmap because we had
> > promised them in 1.1/1.5, but as they're certainly not critical, we
> > can postpone them to a latter release, it's not really critical.
> >
> > In the new features, there are things which should be discussed for
> > inclusion or not.
> > For instance, anonymous inner classes, nested classes and co.
> > Initially, in the early days of Groovy, we didn't want to support them
> > because we found them ugly, and closures should be used more to fill
> > in the gap.
> > So, it's perhaps a debate we should have as to whether the Groovy
> > users really want them in the language?
> >
> > Regarding other features, for instance AST Transformations, we can
> > already do that today, but in a more convoluted way (through the
> > Groovy classloader), so it's mainly about making this feature easier
> > to use. And for the concurrency feature, it could even just be an
> > additional module, instead of bloating Groovy core with yet another
> > big feature.
> >
> > > Hope you don't mind expressing my thoughts here,
> >
> > On the contrary, thanks for sharing your thoughts!
> >
> > --
> >
> > Guillaume Laforge
> > Groovy Project Manager
> > G2One, Inc. Vice-President Technology
> > http://www.g2one.com
> >
>

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

[glaforge]

Of course, it's of the highest priority, but as it's going to take
time, and as we want more frequent releases, we can't not release
anything in the mean time.

On Dec 17, 2007 11:51 AM, Alex Tkachman <alex.tkachman@...> wrote:

> I 100% agree with you. Performance is weakest point of Groovy runtime.
> Even with improvements we did in 1.5. As we said many times we can't
> resolve it without full redesign of MOP. So, it should be priority
> number one.
>
> On Dec 17, 2007 12:25 PM, Alexandru Popescu ☀
> <the.mindstorm.mailinglist@...> wrote:
> >
>
> > On Dec 17, 2007 1:50 AM, Guillaume Laforge <glaforge@...> wrote:
> > > 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
> > >
> >
> > Firstly I would like to thank Mr.G and Jochen for setting up such a
> > detailed roadmap.
> >
> > Now, I would like to add my opinion about it (opinion that might not
> > match exactly the above plan).
> >
> > I do consider that the Groovy language has become "enough" feature
> > rich. IMO, the most important aspects for the future of the language
> > are now more in terms of usability. I don't think I can come out with
> > a nice proposal as you did, but my suggestion would be that the work
> > should focus on the following directions:
> >
> > 1/ fixing bugs related to the 1.5 major release. This will probably
> > result in a couple more minor releases.
> >
> > 2/ focus on the performance. As discussed at GDC this mostly means
> > rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
> > would definitely see the whole energy of the Groovy people going this
> > direction only for the next period.
> >
> > Probably the only "new" feature that I see as belonging to "usability"
> > is the multi-assignment, but this is just a nice to have one, so it
> > shouldn't focus on it right away (or at least I wouldn't consider it
> > as a strict goal for the next immediate period).
> >
> > Hope you don't mind expressing my thoughts here,
> >
> > ./alex
> > --
> > .w( the_mindstorm )p.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>

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

[Alex Tkachman]

Well, it was well-argumented. Thank you!

On Dec 17, 2007 2:06 PM, Guillaume Laforge <glaforge@...> wrote:

> No, we won't include Gant into Groovy.
>
>
> On Dec 17, 2007 11:59 AM, Alex Tkachman <alex.tkachman@...> wrote:
> > Regarding putting features like concurrency to in to additional module
> > I have absolutely vice versa suggestion. I think functionality like
> > Gant and good concurrency/actors package will not bloat Groovy but
> > provide best one shop expirience for Groovy users.
> >
> > So I suggest to include Gant in to main Groovy distro. Of course, if
> > Russel and other Gant developers like the idea.
> >
> >
> > On Dec 17, 2007 12:40 PM, Guillaume Laforge <glaforge@...> wrote:
> > > On Dec 17, 2007 10:25 AM, Alexandru Popescu ☀
> > > <the.mindstorm.mailinglist@...> wrote:
> > > > Firstly I would like to thank Mr.G and Jochen for setting up such a
> > > > detailed roadmap.
> > >
> > > You're welcome :-)
> > >
> > > > Now, I would like to add my opinion about it (opinion that might not
> > > > match exactly the above plan).
> > >
> > > At least, it's not in contradiction with the roadmap!
> > >
> > > > I do consider that the Groovy language has become "enough" feature
> > > > rich. IMO, the most important aspects for the future of the language
> > > > are now more in terms of usability. I don't think I can come out with
> > > > a nice proposal as you did, but my suggestion would be that the work
> > > > should focus on the following directions:
> > > >
> > > > 1/ fixing bugs related to the 1.5 major release. This will probably
> > > > result in a couple more minor releases.
> > >
> > > Agreed, this is what the 1.5.x releases are for.
> > >
> > > > 2/ focus on the performance. As discussed at GDC this mostly means
> > > > rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
> > > > would definitely see the whole energy of the Groovy people going this
> > > > direction only for the next period.
> > >
> > > It's going to be a long process I suspect, as various experiments will
> > > have to be done, lots of discussions, a nice general proposal of what
> > > we really want, etc. So it's something that is going to be done in
> > > parallel to the progress we make in 1.x.
> > >
> > > > Probably the only "new" feature that I see as belonging to "usability"
> > > > is the multi-assignment, but this is just a nice to have one, so it
> > > > shouldn't focus on it right away (or at least I wouldn't consider it
> > > > as a strict goal for the next immediate period).
> > >
> > > I tried to put certain features at certain milestones, but we can
> > > certainly reorder the priorities.
> > > I've put multiple assignments early in the roadmap because we had
> > > promised them in 1.1/1.5, but as they're certainly not critical, we
> > > can postpone them to a latter release, it's not really critical.
> > >
> > > In the new features, there are things which should be discussed for
> > > inclusion or not.
> > > For instance, anonymous inner classes, nested classes and co.
> > > Initially, in the early days of Groovy, we didn't want to support them
> > > because we found them ugly, and closures should be used more to fill
> > > in the gap.
> > > So, it's perhaps a debate we should have as to whether the Groovy
> > > users really want them in the language?
> > >
> > > Regarding other features, for instance AST Transformations, we can
> > > already do that today, but in a more convoluted way (through the
> > > Groovy classloader), so it's mainly about making this feature easier
> > > to use. And for the concurrency feature, it could even just be an
> > > additional module, instead of bloating Groovy core with yet another
> > > big feature.
> > >
> > > > Hope you don't mind expressing my thoughts here,
> > >
> > > On the contrary, thanks for sharing your thoughts!
> > >
> > > --
> > >
> > > Guillaume Laforge
> > > Groovy Project Manager
> > > G2One, Inc. Vice-President Technology
> > > http://www.g2one.com
> > >
> >
>
>
>
> --
>
> Guillaume Laforge
> Groovy Project Manager
> G2One, Inc. Vice-President Technology
> http://www.g2one.com
>

[glaforge]

That's the prerogative of the despot of the project.

If we include Gant, we could also integrate Grails directly into
Groovy, as a lot of people are doing Grails web-apps, and for the guys
using Windows, I think we should also make Scriptom part of Groovy by
default.
Also, Groovy users also need to interact with Web Services, so we
should embed Groovy-WS as well, with its hundreds of JARs from CXF,
and XML-RPC, because SOAP is not all.
Etc, etc...

It doesn't make sense to bloat Groovy with things which should have
their own lifecycle and dependencies.
On the contrary, as outlined at GDC#4, the idea would be more to
provide a modular approach by removing or externalizing things. For
instance, not everybody needs the Swing support, the JMX support or
the SQL support.

And also see how stuck Sun is with all their deprecated APIs, it's not
an example I'd wish to follow.


On Dec 17, 2007 12:11 PM, Alex Tkachman <alex.tkachman@...> wrote:

> Well, it was well-argumented. Thank you!
>
>
> On Dec 17, 2007 2:06 PM, Guillaume Laforge <glaforge@...> wrote:
> > No, we won't include Gant into Groovy.
> >
> >
> > On Dec 17, 2007 11:59 AM, Alex Tkachman <alex.tkachman@...> wrote:
> > > Regarding putting features like concurrency to in to additional module
> > > I have absolutely vice versa suggestion. I think functionality like
> > > Gant and good concurrency/actors package will not bloat Groovy but
> > > provide best one shop expirience for Groovy users.
> > >
> > > So I suggest to include Gant in to main Groovy distro. Of course, if
> > > Russel and other Gant developers like the idea.
> > >
> > >
> > > On Dec 17, 2007 12:40 PM, Guillaume Laforge <glaforge@...> wrote:
> > > > On Dec 17, 2007 10:25 AM, Alexandru Popescu ☀
> > > > <the.mindstorm.mailinglist@...> wrote:
> > > > > Firstly I would like to thank Mr.G and Jochen for setting up such a
> > > > > detailed roadmap.
> > > >
> > > > You're welcome :-)
> > > >
> > > > > Now, I would like to add my opinion about it (opinion that might not
> > > > > match exactly the above plan).
> > > >
> > > > At least, it's not in contradiction with the roadmap!
> > > >
> > > > > I do consider that the Groovy language has become "enough" feature
> > > > > rich. IMO, the most important aspects for the future of the language
> > > > > are now more in terms of usability. I don't think I can come out with
> > > > > a nice proposal as you did, but my suggestion would be that the work
> > > > > should focus on the following directions:
> > > > >
> > > > > 1/ fixing bugs related to the 1.5 major release. This will probably
> > > > > result in a couple more minor releases.
> > > >
> > > > Agreed, this is what the 1.5.x releases are for.
> > > >
> > > > > 2/ focus on the performance. As discussed at GDC this mostly means
> > > > > rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
> > > > > would definitely see the whole energy of the Groovy people going this
> > > > > direction only for the next period.
> > > >
> > > > It's going to be a long process I suspect, as various experiments will
> > > > have to be done, lots of discussions, a nice general proposal of what
> > > > we really want, etc. So it's something that is going to be done in
> > > > parallel to the progress we make in 1.x.
> > > >
> > > > > Probably the only "new" feature that I see as belonging to "usability"
> > > > > is the multi-assignment, but this is just a nice to have one, so it
> > > > > shouldn't focus on it right away (or at least I wouldn't consider it
> > > > > as a strict goal for the next immediate period).
> > > >
> > > > I tried to put certain features at certain milestones, but we can
> > > > certainly reorder the priorities.
> > > > I've put multiple assignments early in the roadmap because we had
> > > > promised them in 1.1/1.5, but as they're certainly not critical, we
> > > > can postpone them to a latter release, it's not really critical.
> > > >
> > > > In the new features, there are things which should be discussed for
> > > > inclusion or not.
> > > > For instance, anonymous inner classes, nested classes and co.
> > > > Initially, in the early days of Groovy, we didn't want to support them
> > > > because we found them ugly, and closures should be used more to fill
> > > > in the gap.
> > > > So, it's perhaps a debate we should have as to whether the Groovy
> > > > users really want them in the language?
> > > >
> > > > Regarding other features, for instance AST Transformations, we can
> > > > already do that today, but in a more convoluted way (through the
> > > > Groovy classloader), so it's mainly about making this feature easier
> > > > to use. And for the concurrency feature, it could even just be an
> > > > additional module, instead of bloating Groovy core with yet another
> > > > big feature.
> > > >
> > > > > Hope you don't mind expressing my thoughts here,
> > > >
> > > > On the contrary, thanks for sharing your thoughts!
> > > >
> > > > --
> > > >
> > > > Guillaume Laforge
> > > > Groovy Project Manager
> > > > G2One, Inc. Vice-President Technology
> > > > http://www.g2one.com
> > > >
> > >
> >
> >
> >
> > --
> >
> > Guillaume Laforge
> > Groovy Project Manager
> > G2One, Inc. Vice-President Technology
> > http://www.g2one.com
> >
>

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

[Graeme Rocher-2]

I'm in agreement with the two Alex's, our focus right now has to be

1) Performance
2) Java Integration

Forget the other shit, it quite simply should sit on the back burner
until these two are sorted. These 2 things are quite simply the 2 most
important aspects of Groovy's future.

Performance is the number 1 cause for the failure to adopt Groovy.
Java integration is the number 1 selling point differentiating it from
other languages

We need to continue with the 1.5.x series of bug fixes releases and
start now (and I mean now) on the work on the MOP to gain optimal
performance and be up there with the best performing dynamic languages
on the VM. Otherwise we will start to build a reputation (of bad
performance) that will be hard to shake off later.

In terms of breaking changes those using ExpandoMetaClass should not
suffer any. ie I should be able to upgrade Grails to the new MOP with
minimal fuss

Cheers

On Dec 17, 2007 11:15 AM, Guillaume Laforge <glaforge@...> wrote:

> That's the prerogative of the despot of the project.
>
> If we include Gant, we could also integrate Grails directly into
> Groovy, as a lot of people are doing Grails web-apps, and for the guys
> using Windows, I think we should also make Scriptom part of Groovy by
> default.
> Also, Groovy users also need to interact with Web Services, so we
> should embed Groovy-WS as well, with its hundreds of JARs from CXF,
> and XML-RPC, because SOAP is not all.
> Etc, etc...
>
> It doesn't make sense to bloat Groovy with things which should have
> their own lifecycle and dependencies.
> On the contrary, as outlined at GDC#4, the idea would be more to
> provide a modular approach by removing or externalizing things. For
> instance, not everybody needs the Swing support, the JMX support or
> the SQL support.
>
> And also see how stuck Sun is with all their deprecated APIs, it's not
> an example I'd wish to follow.
>
>
>
> On Dec 17, 2007 12:11 PM, Alex Tkachman <alex.tkachman@...> wrote:
> > Well, it was well-argumented. Thank you!
> >
> >
> > On Dec 17, 2007 2:06 PM, Guillaume Laforge <glaforge@...> wrote:
> > > No, we won't include Gant into Groovy.
> > >
> > >
> > > On Dec 17, 2007 11:59 AM, Alex Tkachman <alex.tkachman@...> wrote:
> > > > Regarding putting features like concurrency to in to additional module
> > > > I have absolutely vice versa suggestion. I think functionality like
> > > > Gant and good concurrency/actors package will not bloat Groovy but
> > > > provide best one shop expirience for Groovy users.
> > > >
> > > > So I suggest to include Gant in to main Groovy distro. Of course, if
> > > > Russel and other Gant developers like the idea.
> > > >
> > > >
> > > > On Dec 17, 2007 12:40 PM, Guillaume Laforge <glaforge@...> wrote:
> > > > > On Dec 17, 2007 10:25 AM, Alexandru Popescu ☀
> > > > > <the.mindstorm.mailinglist@...> wrote:
> > > > > > Firstly I would like to thank Mr.G and Jochen for setting up such a
> > > > > > detailed roadmap.
> > > > >
> > > > > You're welcome :-)
> > > > >
> > > > > > Now, I would like to add my opinion about it (opinion that might not
> > > > > > match exactly the above plan).
> > > > >
> > > > > At least, it's not in contradiction with the roadmap!
> > > > >
> > > > > > I do consider that the Groovy language has become "enough" feature
> > > > > > rich. IMO, the most important aspects for the future of the language
> > > > > > are now more in terms of usability. I don't think I can come out with
> > > > > > a nice proposal as you did, but my suggestion would be that the work
> > > > > > should focus on the following directions:
> > > > > >
> > > > > > 1/ fixing bugs related to the 1.5 major release. This will probably
> > > > > > result in a couple more minor releases.
> > > > >
> > > > > Agreed, this is what the 1.5.x releases are for.
> > > > >
> > > > > > 2/ focus on the performance. As discussed at GDC this mostly means
> > > > > > rethinking the whole MOP, stabilizing and unifying the MOP, etc. I
> > > > > > would definitely see the whole energy of the Groovy people going this
> > > > > > direction only for the next period.
> > > > >
> > > > > It's going to be a long process I suspect, as various experiments will
> > > > > have to be done, lots of discussions, a nice general proposal of what
> > > > > we really want, etc. So it's something that is going to be done in
> > > > > parallel to the progress we make in 1.x.
> > > > >
> > > > > > Probably the only "new" feature that I see as belonging to "usability"
> > > > > > is the multi-assignment, but this is just a nice to have one, so it
> > > > > > shouldn't focus on it right away (or at least I wouldn't consider it
> > > > > > as a strict goal for the next immediate period).
> > > > >
> > > > > I tried to put certain features at certain milestones, but we can
> > > > > certainly reorder the priorities.
> > > > > I've put multiple assignments early in the roadmap because we had
> > > > > promised them in 1.1/1.5, but as they're certainly not critical, we
> > > > > can postpone them to a latter release, it's not really critical.
> > > > >
> > > > > In the new features, there are things which should be discussed for
> > > > > inclusion or not.
> > > > > For instance, anonymous inner classes, nested classes and co.
> > > > > Initially, in the early days of Groovy, we didn't want to support them
> > > > > because we found them ugly, and closures should be used more to fill
> > > > > in the gap.
> > > > > So, it's perhaps a debate we should have as to whether the Groovy
> > > > > users really want them in the language?
> > > > >
> > > > > Regarding other features, for instance AST Transformations, we can
> > > > > already do that today, but in a more convoluted way (through the
> > > > > Groovy classloader), so it's mainly about making this feature easier
> > > > > to use. And for the concurrency feature, it could even just be an
> > > > > additional module, instead of bloating Groovy core with yet another
> > > > > big feature.
> > > > >
> > > > > > Hope you don't mind expressing my thoughts here,
> > > > >
> > > > > On the contrary, thanks for sharing your thoughts!
> > > > >
> > > > > --
> > > > >
> > > > > Guillaume Laforge
> > > > > Groovy Project Manager
> > > > > G2One, Inc. Vice-President Technology
> > > > > http://www.g2one.com
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Guillaume Laforge
> > > Groovy Project Manager
> > > G2One, Inc. Vice-President Technology
> > > http://www.g2one.com
> > >
> >
>
>
>
> --
>
> Guillaume Laforge
> Groovy Project Manager
> G2One, Inc. Vice-President Technology
> http://www.g2one.com
>

--
Graeme Rocher
Grails Project Lead
G2One, Inc. Chief Technology Officer
http://www.g2one.com

[shemnon]

On 12/17/07, Guillaume Laforge <glaforge@...> wrote:

It doesn't make sense to bloat Groovy with things which should have
their own lifecycle and dependencies.
On the contrary, as outlined at GDC#4, the idea would be more to
provide a modular approach by removing or externalizing things. For
instance, not everybody needs the Swing support, the JMX support or
the SQL support.

I didn't see  modularity on the roadmap anywhere.  Innocent omission or will it be tied in tot he next release 'when ready'?

--Danno

[glaforge]

> I didn't see  modularity on the roadmap anywhere.  Innocent omission or will
> it be tied in tot he next release 'when ready'?

It's missing and it deserves a GEP on its own.

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

[Jörg Staudemeyer-2]

Hi Guillaume ...

2007/12/17, Guillaume Laforge <glaforge@...>:

Dear Groovy developers,

why do you address Groovy developers only? Looks a bit as if you make Groovy for yourselves and not for users.

-Jörg 

[Alexandru Popescu ☀]

On Dec 17, 2007 9:30 PM, Jörg Staudemeyer <jstaudemeyer@...> wrote:
> Hi Guillaume ...
>
> 2007/12/17, Guillaume Laforge <glaforge@...>:
> > Dear Groovy developers,
>
> why do you address Groovy developers only? Looks a bit as if you make Groovy
> for yourselves and not for users.
>

Are you nitpicking :-) ? I assume Mr.G send this out the roadmap in
this format as we firstly need to decide which is the road we will go.
By the time we have an agreement and a more stable roadmap, MrG will
probably announce it publicly.

./alex
--
.w( the_mindstorm )p.

>  -Jörg
>

[Chris Dempsey-2]

Would you be stunned of Microsoft decided among its developers what the roadmap for Windows before letting the world know?

On Dec 17, 2007 1:30 PM, Jörg Staudemeyer <jstaudemeyer@...> wrote:

Hi Guillaume ...

2007/12/17, Guillaume Laforge <glaforge@...>:

Dear Groovy developers,

why do you address Groovy developers only? Looks a bit as if you make Groovy for yourselves and not for users.

-Jörg 

--
Chris
grok-programming.com

[Warner Onstine-3]

On Dec 16, 2007 6:25 PM, Andres Almiray <aalmiray@...> wrote:
>
> Looks great, specially the incremental compiler as we would definitely use it
> at work too.
> I wonder where does handling private access fall? as well as possibly
> allowing < <= => > to be overridden independently of <=>

+1 on this. Honestly this one little omission really hamstrings Groovy
in certain respects and I would love to see method
overloading/overriding become complete (I have at least one bug on
this and have voted for another).

Other than that I think the roadmap looks good.

-warner


--
Warner Onstine - Programmer/Author
New book on Tapestry 4!
Tapestry 101 available at
http://sourcebeat.com/books/tapestrylive.html
warner@...
http://warneronstine.com/blog

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

    http://xircles.codehaus.org/manage_email

[glaforge]

On Dec 17, 2007 8:30 PM, Jörg Staudemeyer <jstaudemeyer@...> wrote:
> Hi Guillaume ...
>
> 2007/12/17, Guillaume Laforge <glaforge@...>:
> > Dear Groovy developers,
>
> why do you address Groovy developers only? Looks a bit as if you make Groovy
> for yourselves and not for users.

You're serious? LOL :-)
I guess if I were doing Groovy just for myself or ourselves, I
wouldn't care about the bugs users report, or feature requests users
make. You'd notice a huge difference in the quality of the project and
you would not be using it :-)
You know, what this roadmap is mainly about what users requested over
the course of time.


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