You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@groovy.apache.org by gi...@apache.org on 2026/04/12 08:21:53 UTC
(groovy-dev-site) branch asf-site updated: 2026/04/12 08:21:50: Generated dev website from groovy-website@14be50e
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/groovy-dev-site.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 6b9cfb1 2026/04/12 08:21:50: Generated dev website from groovy-website@14be50e
6b9cfb1 is described below
commit 6b9cfb102f445e253782583607c67489a512d866
Author: jenkins <bu...@apache.org>
AuthorDate: Sun Apr 12 08:21:50 2026 +0000
2026/04/12 08:21:50: Generated dev website from groovy-website@14be50e
---
search/search-index.json | 36 +-
wiki/GEP-1.html | 361 +++++++++----
wiki/GEP-10.html | 560 +++++++++++++-------
wiki/GEP-11.html | 694 ++++++++++++++++--------
wiki/GEP-12.html | 545 ++++++++++++-------
wiki/GEP-13.html | 347 ++++++++----
wiki/GEP-14.html | 394 ++++++++++----
wiki/GEP-15.html | 580 +++++++++++++-------
wiki/GEP-2.html | 571 +++++++++++++-------
wiki/GEP-3.html | 821 ++++++++++++++++++++---------
wiki/GEP-4.html | 330 ++++++++----
wiki/GEP-5.html | 209 ++++++--
wiki/GEP-6.html | 289 +++++++---
wiki/GEP-7.html | 372 +++++++++----
wiki/GEP-8.html | 791 ++++++++++++++++++---------
wiki/GEP-9.html | 622 +++++++++++++++-------
wiki/grails-proposal.html | 650 ++++++++++++++++-------
wiki/groovy-release-discussion.html | 446 +++++++++++-----
wiki/initial-release-process-proposal.html | 526 +++++++++++-------
19 files changed, 6342 insertions(+), 2802 deletions(-)
diff --git a/search/search-index.json b/search/search-index.json
index e07f8e5..855f0e5 100644
--- a/search/search-index.json
+++ b/search/search-index.json
@@ -737,105 +737,105 @@
{
"id": "wiki/groovy-release-discussion.html",
"title": "The Apache Groovy programming language - Developer docs - Adapting the release process for Apache",
- "content": "The Apache Groovy programming language - Developer docs - Adapting the release process for Apache Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute [...]
+ "content": "The Apache Groovy programming language - Developer docs - Adapting the release process for Apache Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute [...]
"url": "wiki/groovy-release-discussion.html",
"site": "dev"
},
{
"id": "wiki/GEP-13.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-13",
- "content": "The Apache Groovy programming language - Developer docs - GEP-13 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-13 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GE [...]
"url": "wiki/GEP-13.html",
"site": "dev"
},
{
"id": "wiki/GEP-1.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-1",
- "content": "The Apache Groovy programming language - Developer docs - GEP-1 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = G [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-1 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GEP [...]
"url": "wiki/GEP-1.html",
"site": "dev"
},
{
"id": "wiki/GEP-10.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-10",
- "content": "The Apache Groovy programming language - Developer docs - GEP-10 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-10 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GE [...]
"url": "wiki/GEP-10.html",
"site": "dev"
},
{
"id": "wiki/initial-release-process-proposal.html",
"title": "The Apache Groovy programming language - Developer docs - Initial release process proposal",
- "content": "The Apache Groovy programming language - Developer docs - Initial release process proposal Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosyst [...]
+ "content": "The Apache Groovy programming language - Developer docs - Initial release process proposal Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosyst [...]
"url": "wiki/initial-release-process-proposal.html",
"site": "dev"
},
{
"id": "wiki/GEP-8.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-8",
- "content": "The Apache Groovy programming language - Developer docs - GEP-8 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = G [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-8 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GEP [...]
"url": "wiki/GEP-8.html",
"site": "dev"
},
{
"id": "wiki/GEP-12.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-12",
- "content": "The Apache Groovy programming language - Developer docs - GEP-12 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-12 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GE [...]
"url": "wiki/GEP-12.html",
"site": "dev"
},
{
"id": "wiki/GEP-5.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-5",
- "content": "The Apache Groovy programming language - Developer docs - GEP-5 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = G [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-5 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GEP [...]
"url": "wiki/GEP-5.html",
"site": "dev"
},
{
"id": "wiki/GEP-14.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-14",
- "content": "The Apache Groovy programming language - Developer docs - GEP-14 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-14 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GE [...]
"url": "wiki/GEP-14.html",
"site": "dev"
},
{
"id": "wiki/GEP-15.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-15",
- "content": "The Apache Groovy programming language - Developer docs - GEP-15 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-15 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GE [...]
"url": "wiki/GEP-15.html",
"site": "dev"
},
{
"id": "wiki/grails-proposal.html",
"title": "The Apache Groovy programming language - Developer docs - Grails Project Proposal",
- "content": "The Apache Groovy programming language - Developer docs - Grails Project Proposal Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog p [...]
+ "content": "The Apache Groovy programming language - Developer docs - Grails Project Proposal Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog p [...]
"url": "wiki/grails-proposal.html",
"site": "dev"
},
{
"id": "wiki/GEP-2.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-2",
- "content": "The Apache Groovy programming language - Developer docs - GEP-2 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = G [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-2 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GEP [...]
"url": "wiki/GEP-2.html",
"site": "dev"
},
{
"id": "wiki/GEP-3.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-3",
- "content": "The Apache Groovy programming language - Developer docs - GEP-3 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = G [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-3 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GEP [...]
"url": "wiki/GEP-3.html",
"site": "dev"
},
{
"id": "wiki/GEP-11.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-11",
- "content": "The Apache Groovy programming language - Developer docs - GEP-11 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-11 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GE [...]
"url": "wiki/GEP-11.html",
"site": "dev"
},
{
"id": "wiki/GEP-4.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-4",
- "content": "The Apache Groovy programming language - Developer docs - GEP-4 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = G [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-4 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GEP [...]
"url": "wiki/GEP-4.html",
"site": "dev"
},
@@ -849,21 +849,21 @@
{
"id": "wiki/GEP-6.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-6",
- "content": "The Apache Groovy programming language - Developer docs - GEP-6 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = G [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-6 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GEP [...]
"url": "wiki/GEP-6.html",
"site": "dev"
},
{
"id": "wiki/GEP-7.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-7",
- "content": "The Apache Groovy programming language - Developer docs - GEP-7 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = G [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-7 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GEP [...]
"url": "wiki/GEP-7.html",
"site": "dev"
},
{
"id": "wiki/GEP-9.html",
"title": "The Apache Groovy programming language - Developer docs - GEP-9",
- "content": "The Apache Groovy programming language - Developer docs - GEP-9 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize = G [...]
+ "content": "The Apache Groovy programming language - Developer docs - GEP-9 Socialize Discuss on the mailing list Groovy on X Groovy on Bluesky Groovy on Mastodon Groovy on LinkedIn Events and conferences Source code on GitHub Report issues in Jira Stack Overflow questions Slack Community You are using an outdated browser. Please upgrade your browser to improve your experience. Apache Groovy™ Learn Documentation Download Support Contribute Ecosystem Blog posts Socialize GEP [...]
"url": "wiki/GEP-9.html",
"site": "dev"
},
diff --git a/wiki/GEP-1.html b/wiki/GEP-1.html
index 641a28c..c28173d 100644
--- a/wiki/GEP-1.html
+++ b/wiki/GEP-1.html
@@ -59,113 +59,282 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-1: Groovy Enhancement Proposal
-
-:category: dev
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-1
-*Title*:: Groovy Enhancement Proposal
-*Version*:: 2.0
-*Type*:: Informational
-*Status*:: Final
-*Leader*:: Apache Project Leader
-*Created*:: 2009-03-26
-*Last modification* :: 2018-10-11
-****
-
-== Abstract: What is a GEP?
-
-GEP stands for Groovy Enhancement Proposal. A GEP is a document providing information to the Groovy development team and
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-1</a></li><li><a href='#_abstract_what_is_a_gep' class='anchor-link'>Abstract: What is a GEP?</a></li><li><a href='#_rationale_why_a_gep' class='anchor-link'>Rationale: Why a GEP?</a></li><li><a href='#_whats_in_a_gep' class='anchor-link'>What’s in a GEP?</a></li><li><a href='#_the_general_workflow [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-1</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>Groovy Enhancement Proposal</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>2.0</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Informational</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Final</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Apache Project Leader</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2009-03-26</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2018-10-11</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract_what_is_a_gep">Abstract: What is a GEP?</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>GEP stands for Groovy Enhancement Proposal. A GEP is a document providing information to the Groovy development team and
user community describing a new feature, an enhancement, or a change to Groovy, the language, its APIs, its integration,
or its infrastructure. Whenever such an addition or change is significant and deserves a detailed discussion on its
-rationale, its design, or its impact on the project, the writing of a GEP should be considered.
-
-The concept of the GEP was freely inspired from Python's http://www.python.org/dev/peps/pep-0001/[PEP] (Python Enhancement Proposal).
-
-== Rationale: Why a GEP?
-
-For non-trivial, complex or strategic features, discussions on mailing lists are difficult to lead and follow, and often
-don't help reach a consensus. Writing a proper document explaining the design and implications of said feature allows both
+rationale, its design, or its impact on the project, the writing of a GEP should be considered.</p>
+</div>
+<div class="paragraph">
+<p>The concept of the GEP was freely inspired from Python’s <a href="http://www.python.org/dev/peps/pep-0001/">PEP</a> (Python Enhancement Proposal).</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_rationale_why_a_gep">Rationale: Why a GEP?</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>For non-trivial, complex or strategic features, discussions on mailing lists are difficult to lead and follow, and often
+don’t help reach a consensus. Writing a proper document explaining the design and implications of said feature allows both
the originator of the idea and the community at large to have a chance to provide interesting and useful feedback and
-helps better understanding the rationale, the design decisions, the impact of the proposal.
-
-== What's in a GEP?
-
-A GEP:
-
-* is led by a "Leader" who is responsible for the writing and progress of the proposal
-* is assigned a unique "Number"
-* has a "Title" describing succinctly its intent
-* has a "Type"
-* has a "Status" giving information on its progress
-* has a "Version" number indicating its current revision
-* gives a "Last modification" date
-* gives a "Creation" date
-* features an "Abstract" explaining the intent of the GEP
-* gives a "Rationale" for this enhancement
-
-The type of a GEP can be of the following:
-
-Informational:: if the GEP provides some information or guidance on a topic related to Groovy (this GEP is of such type, as well as the list of all existing GEPs)
-Feature:: if the GEP is about the implementation of a new feature, enhancement or a change in Groovy
-Process:: if the GEP describes a process related to the Groovy project (examples: the Groovy release process, how to enroll new committers, etc.)
-
-If the GEP is a Feature GEP, it should also:
-
-* define a "Target" Groovy version for its integration
-* provide a "Reference implementation" properly covered by unit tests and commented (Groovydoc/JavaDoc/asciidoc as appropriate) so that the Groovy community can play with the enhancement and provide useful feedback
-* detail the "Impact" on Groovy, especially in terms of backward-compatibility or impact on other projects
-
-The "Status" of a GEP can be:
-
-Draft:: when a GEP is currently in the writing and is in discussion but hasn't yet reached a state ready for inclusion in Groovy
-Accepted:: when the draft GEP, as is, is in a state which doesn't mandate any additional modification, is ready to be
-integrated into Groovy and has been accepted by the development team, following the usual Apache principles
-Rejected:: when consensus emerges or a development team decision has been made that deems the proposal should not be integrated into Groovy
-Final:: when the GEP has been integrated into a released version of Groovy and has been properly documented in the Groovy wiki
-
-Beyond all these metadata, as appropriate, a GEP should also:
-
-* give pointers to existing mailing-list discussions (through Nabble, Markmail or Ponymail)
-* list existing papers or documentations related to this feature that provides additional material for understanding the concepts or implementation difficulties
-* provide samples showing how the feature should be used and how idiomatic Groovy the solution is
-
-== The general workflow
-
-The general workflow of a Groovy Enhancement Proposal is as follows:
-
-The inception of a GEP generally stems from a discussion on the Groovy mailing lists about a new feature or change
+helps better understanding the rationale, the design decisions, the impact of the proposal.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_whats_in_a_gep">What’s in a GEP?</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>A GEP:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>is led by a "Leader" who is responsible for the writing and progress of the proposal</p>
+</li>
+<li>
+<p>is assigned a unique "Number"</p>
+</li>
+<li>
+<p>has a "Title" describing succinctly its intent</p>
+</li>
+<li>
+<p>has a "Type"</p>
+</li>
+<li>
+<p>has a "Status" giving information on its progress</p>
+</li>
+<li>
+<p>has a "Version" number indicating its current revision</p>
+</li>
+<li>
+<p>gives a "Last modification" date</p>
+</li>
+<li>
+<p>gives a "Creation" date</p>
+</li>
+<li>
+<p>features an "Abstract" explaining the intent of the GEP</p>
+</li>
+<li>
+<p>gives a "Rationale" for this enhancement</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>The type of a GEP can be of the following:</p>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1">Informational</dt>
+<dd>
+<p>if the GEP provides some information or guidance on a topic related to Groovy (this GEP is of such type, as well as the list of all existing GEPs)</p>
+</dd>
+<dt class="hdlist1">Feature</dt>
+<dd>
+<p>if the GEP is about the implementation of a new feature, enhancement or a change in Groovy</p>
+</dd>
+<dt class="hdlist1">Process</dt>
+<dd>
+<p>if the GEP describes a process related to the Groovy project (examples: the Groovy release process, how to enroll new committers, etc.)</p>
+</dd>
+</dl>
+</div>
+<div class="paragraph">
+<p>If the GEP is a Feature GEP, it should also:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>define a "Target" Groovy version for its integration</p>
+</li>
+<li>
+<p>provide a "Reference implementation" properly covered by unit tests and commented (Groovydoc/JavaDoc/asciidoc as appropriate) so that the Groovy community can play with the enhancement and provide useful feedback</p>
+</li>
+<li>
+<p>detail the "Impact" on Groovy, especially in terms of backward-compatibility or impact on other projects</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>The "Status" of a GEP can be:</p>
+</div>
+<div class="dlist">
+<dl>
+<dt class="hdlist1">Draft</dt>
+<dd>
+<p>when a GEP is currently in the writing and is in discussion but hasn’t yet reached a state ready for inclusion in Groovy</p>
+</dd>
+<dt class="hdlist1">Accepted</dt>
+<dd>
+<p>when the draft GEP, as is, is in a state which doesn’t mandate any additional modification, is ready to be
+integrated into Groovy and has been accepted by the development team, following the usual Apache principles</p>
+</dd>
+<dt class="hdlist1">Rejected</dt>
+<dd>
+<p>when consensus emerges or a development team decision has been made that deems the proposal should not be integrated into Groovy</p>
+</dd>
+<dt class="hdlist1">Final</dt>
+<dd>
+<p>when the GEP has been integrated into a released version of Groovy and has been properly documented in the Groovy wiki</p>
+</dd>
+</dl>
+</div>
+<div class="paragraph">
+<p>Beyond all these metadata, as appropriate, a GEP should also:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>give pointers to existing mailing-list discussions (through Nabble, Markmail or Ponymail)</p>
+</li>
+<li>
+<p>list existing papers or documentations related to this feature that provides additional material for understanding the concepts or implementation difficulties</p>
+</li>
+<li>
+<p>provide samples showing how the feature should be used and how idiomatic Groovy the solution is</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_the_general_workflow">The general workflow</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The general workflow of a Groovy Enhancement Proposal is as follows:</p>
+</div>
+<div class="paragraph">
+<p>The inception of a GEP generally stems from a discussion on the Groovy mailing lists about a new feature or change
when the Groovy Despot and the development team deem necessary to properly document and articulate this new idea,
-for further discussion and analysis. Generally, simple bug fixes and minor enhancements don't require a full-blown GEP.
-A GEP is started solely with the agreement of the Groovy PMC.
-
-A unique Number is assigned by the Groovy PMC and a meaningful "Title" is created for this GEP.
+for further discussion and analysis. Generally, simple bug fixes and minor enhancements don’t require a full-blown GEP.
+A GEP is started solely with the agreement of the Groovy PMC.</p>
+</div>
+<div class="paragraph">
+<p>A unique Number is assigned by the Groovy PMC and a meaningful "Title" is created for this GEP.
A proposed Target Groovy version is proposed for the inclusion of this GEP if appropriate.
A Leader for this effort (usually the instigator of the GEP or the lead developer of it) takes care of the
creation of the GEP, of writing a detailed document proposing this enhancement, and eventually of providing
a reference implementation as a branch (or PR or patch) for the targeted Groovy version.
Once the development team and the "Leader" are happy with the status of the GEP, a decision should be made to act the
integration of this GEP into Groovy and a JIRA issue for this task should be created. As per Apache guidelines,
-the Groovy PMC has the last say on the acceptation of the GEP as a Final status GEP.
-
-The integration of the GEP in Groovy is Final once proper documentation is added to the appropriate Groovy repo and
+the Groovy PMC has the last say on the acceptation of the GEP as a Final status GEP.</p>
+</div>
+<div class="paragraph">
+<p>The integration of the GEP in Groovy is Final once proper documentation is added to the appropriate Groovy repo and
that the reference implementation has reached maturity and provides a good test suite covering the feature.
-If the GEP doesn't fulfill all the requirements of the GEP process, the GEP can be rejected or deferred.
-
-== References
-
-=== JIRA issues:
-
-https://issues.apache.org/jira/browse/GROOVY-1709[GROOVY-1709]: GEP: Groovy Enhancement Proposal
-
-== Update history
-
-1.0 (2009-03-26):: Version as extracted from Codehaus wiki
-2.0 (2018-10-11):: Update to reflect changes since joining Apache
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-1</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-1</h1><hr/></div></div></div></div><footer id='footer'>
+If the GEP doesn’t fulfill all the requirements of the GEP process, the GEP can be rejected or deferred.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references">References</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_jira_issues">JIRA issues:</h3>
+<div class="paragraph">
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-1709">GROOVY-1709</a>: GEP: Groovy Enhancement Proposal</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">1.0 (2009-03-26)</dt>
+<dd>
+<p>Version as extracted from Codehaus wiki</p>
+</dd>
+<dt class="hdlist1">2.0 (2018-10-11)</dt>
+<dd>
+<p>Update to reflect changes since joining Apache</p>
+</dd>
+</dl>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-10.html b/wiki/GEP-10.html
index 011654d..60984a2 100644
--- a/wiki/GEP-10.html
+++ b/wiki/GEP-10.html
@@ -59,141 +59,248 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-10: Static compilation
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-10
-*Title*:: Static compilation
-*Version*:: 4
-*Type*:: Feature
-*Status*:: Final
-*Comment*:: Delivered in Groovy 2.0 and enhanced in later versions
-*Leader*:: Cédric Champeau
-*Created*:: 2011-11-23
-*Last modification* :: 2018-10-26
-****
-
-== Abstract: Static compilation
-
-This GEP introduces an experimental new feature in the language known as static compilation.
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-10</a></li><li><a href='#_abstract_static_compilation' class='anchor-link'>Abstract: Static compilation</a></li><li><a href='#_references_and_useful_links' class='anchor-link'>References and useful links</a></li><li><a href='#_update_history' class='anchor-link'>Update history</a></li></ul></div><div cla [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-10</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>Static compilation</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>4</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Final</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Comment</strong>
+</td>
+<td class="hdlist2">
+<p>Delivered in Groovy 2.0 and enhanced in later versions</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Cédric Champeau</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2011-11-23</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2018-10-26</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract_static_compilation">Abstract: Static compilation</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>This GEP introduces an experimental new feature in the language known as static compilation.
Static compilation can be used when the dynamic features of Groovy are not necessary and that the
-performance of the dynamic runtime is too low. The reader must understand that :
-
-* we do not plan to change the semantics of regular Groovy
-* we want static compilation to be triggered explicitly
-* we want the semantics of static groovy to be as close as possible as the semantics of dynamic Groovy
-
-=== Rationale: Static Type Checking vs Static compilation
-
-Static compilation heavily relies on another feature called Static type checking but it is important to understand
+performance of the dynamic runtime is too low. The reader must understand that :</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>we do not plan to change the semantics of regular Groovy</p>
+</li>
+<li>
+<p>we want static compilation to be triggered explicitly</p>
+</li>
+<li>
+<p>we want the semantics of static groovy to be as close as possible as the semantics of dynamic Groovy</p>
+</li>
+</ul>
+</div>
+<div class="sect2">
+<h3 id="_rationale_static_type_checking_vs_static_compilation">Rationale: Static Type Checking vs Static compilation</h3>
+<div class="paragraph">
+<p>Static compilation heavily relies on another feature called Static type checking but it is important to understand
that they are separate steps. You can statically type check your code, and still have the dynamic runtime at work.
Static type checking adds type inference to the compilation process. This means that, for example, type arguments
of method calls are inferred, as well as return types of closures or methods. Those inferred types are used by the
checker to verify the type flow of your program. When it does so, once must be aware that the static checker cannot
-behave like dynamic Groovy. This means that even if a program passes static type checking, it may behave differently at runtime.
-
-=== Method selection
-
-==== Method selection in dynamic Groovy
-
-Groovy supports multimethods. Especially, in dynamic Groovy, target methods are chosen at runtime,
-in opposite to Java which chooses target method at compile time. Let's illustrate the difference with an example :
-
-```
-public void foo(String arg) { System.out.println("String"); }
+behave like dynamic Groovy. This means that even if a program passes static type checking, it may behave differently at runtime.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_method_selection">Method selection</h3>
+<div class="sect3">
+<h4 id="_method_selection_in_dynamic_groovy">Method selection in dynamic Groovy</h4>
+<div class="paragraph">
+<p>Groovy supports multimethods. Especially, in dynamic Groovy, target methods are chosen at runtime,
+in opposite to Java which chooses target method at compile time. Let’s illustrate the difference with an example :</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>public void foo(String arg) { System.out.println("String"); }
public void foo(Object o) { System.out.println("Object"); }
Object o = "The type of o at runtime is String";
-foo(o);
-```
-
-In Java, this code will output "Object", because the target method is chosen according to the type of the arguments at compile time.
+foo(o);</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>In Java, this code will output "Object", because the target method is chosen according to the type of the arguments at compile time.
The declared type of "o" is Object, so the Object version of the method is chosen. If you want to call the String version,
-you have to define "o" as a "String", or cast o to string in the method call arguments. Now the same example in dynamic Groovy :
-
-```
-void foo(String arg) { println 'String' }
+you have to define "o" as a "String", or cast o to string in the method call arguments. Now the same example in dynamic Groovy :</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>void foo(String arg) { println 'String' }
void foo(Object o) { println 'Object' }
def o = 'The type of o at runtime is String'
-foo(o)
-```
-
-If you run this snippet, you will see that Groovy prints "String". The reason is that Groovy resolves type arguments at
+foo(o)</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>If you run this snippet, you will see that Groovy prints "String". The reason is that Groovy resolves type arguments at
runtime and chooses the most specialized version of a method signature when multiple versions are possible.
To deal with multiple arguments, Groovy computes a distance between the actual type arguments and the declared
-argument types of a method. The method with the best score is chosen.
-
-The method selection process is complex, and makes Groovy quite powerful. It is also possible, for example,
+argument types of a method. The method with the best score is chosen.</p>
+</div>
+<div class="paragraph">
+<p>The method selection process is complex, and makes Groovy quite powerful. It is also possible, for example,
to define metaclasses which will choose different methods, or change the return type of a method dynamically.
This behaviour is responsible for a large part of the poor performance of Groovy invocation times as compared to Java.
However, performance has greatly improved with the introduction of call site caching in Groovy.
-Even with those optimizations, Groovy is far for the performance of a pure static language.
-
-==== InvokeDynamic
-
-InvokeDynamic support is under development and should be introduced in the upcoming Groovy 2.0.
+Even with those optimizations, Groovy is far for the performance of a pure static language.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_invokedynamic">InvokeDynamic</h4>
+<div class="paragraph">
+<p>InvokeDynamic support is under development and should be introduced in the upcoming Groovy 2.0.
What InvokeDynamic allows us to do is to, basically, replace call site caching with a native "dynamic method dispatch"
system directly implemented by the JVM. It is still uncertain what performance improvement we will reach.
At best, we could be close to the performance of a statically typed language.
However, as some features are still difficult to implement with InvokeDynamic,
-most likely the performance gain will not be so high. It is important to talk about it though, because :
-
-* invokedynamic allows JIT optimizations
-* replaces the current dynamic method dispatch without changing the semantics of the language
-* if performance is good, could make static compilation unnecessary
-
-However, InvokeDynamic has a major drawback : it will only be available for people using a Java 7+ JVM.
+most likely the performance gain will not be so high. It is important to talk about it though, because :</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>invokedynamic allows JIT optimizations</p>
+</li>
+<li>
+<p>replaces the current dynamic method dispatch without changing the semantics of the language</p>
+</li>
+<li>
+<p>if performance is good, could make static compilation unnecessary</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>However, InvokeDynamic has a major drawback : it will only be available for people using a Java 7+ JVM.
If we want to deliver Java-like performance for Groovy programs to our users, can we afford leaving
-most of them without such? Most probably, Java 7 won't be mainstream before two or three years.
-
-Rémi Forax, however, created a backport of invokedynamic for older versions of the JVM.
+most of them without such? Most probably, Java 7 won’t be mainstream before two or three years.</p>
+</div>
+<div class="paragraph">
+<p>Rémi Forax, however, created a backport of invokedynamic for older versions of the JVM.
Such a backport relies on bytecode transformation to replace invokedynamic instructions with "emulated instructions".
This "emulated" mode is great for us Groovy developers, because it would allow us to write code once and run it on
any JVM, but for users, the performance would most probably be bad. To be sure of that, an experiment with backported
InDy will be made once invokedynamic support is implemented in Groovy core. The most probable situation,
-though, is that performance of such code will remain far from what a static language could provide.
-
-=== Static Groovy
-
-==== Type inference based dispatch
-
-This GEP is there to experiment a static compilation mode in Groovy. With what we have explained before,
+though, is that performance of such code will remain far from what a static language could provide.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_static_groovy">Static Groovy</h3>
+<div class="sect3">
+<h4 id="_type_inference_based_dispatch">Type inference based dispatch</h4>
+<div class="paragraph">
+<p>This GEP is there to experiment a static compilation mode in Groovy. With what we have explained before,
you should already understand that statically typed code implies a different behaviour from dynamic code.
If you expect the statically checked and statically compiled code to behave exactly like dynamic Groovy,
you should already stop there, or wait for invoke dynamic support to expect improved performance.
If you perfectly understand that statically compiled code means different semantics,
then you can continue reading this GEP, and help us choose the best implementation path.
-In fact, there are several options that we will explain here.
-
-The current implementation relies on the static type checker, which performs type inference.
-This means that with the previous example :
-
-```
-void foo(String arg) { println 'String' }
+In fact, there are several options that we will explain here.</p>
+</div>
+<div class="paragraph">
+<p>The current implementation relies on the static type checker, which performs type inference.
+This means that with the previous example :</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>void foo(String arg) { println 'String' }
void foo(Object o) { println 'Object' }
def o = 'The type of o at runtime is String'
-foo(o)
-```
-
-The compiler is able to infer that when the foo method is called, the actual type argument will be a string.
+foo(o)</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The compiler is able to infer that when the foo method is called, the actual type argument will be a string.
If we compile it statically, the behaviour of this statically compiled program at runtime will be the same as dynamic Groovy.
With such an implementation, we expect most programs to behave statically like they would in dynamic Groovy.
-However, this will never be always true. This is why we say this behaviour is "as close as possible" as the one of dynamic Groovy.
-
-The drawback of this implementation is that the developer cannot easily know what method the compiler chooses.
-For example, let's take this example, extracted from a discussion on the mailing list:
-
-```
-void foo(String msg) { println msg }
+However, this will never be always true. This is why we say this behaviour is "as close as possible" as the one of dynamic Groovy.</p>
+</div>
+<div class="paragraph">
+<p>The drawback of this implementation is that the developer cannot easily know what method the compiler chooses.
+For example, let’s take this example, extracted from a discussion on the mailing list:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>void foo(String msg) { println msg }
void foo(Object msg) { println 'Object' }
-def doIt = {x ->
+def doIt = {x ->
Object o = x
foo(o)
}
@@ -201,125 +308,192 @@ def doIt = {x ->
def getXXX() { "return String" }
def o2=getXXX()
-doIt o2 // "String method" or "Object method"????
-```
-
-The static type checker infers the type of o2 from the return type of getXXX, so knows that doIt is called with a String,
+doIt o2 // "String method" or "Object method"????</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The static type checker infers the type of o2 from the return type of getXXX, so knows that doIt is called with a String,
so you could suspect the program to choose the foo(String) method. However, doIt is a closure, which can therefore
be reused in many places, and the type of its "x" argument is unknown. The type checker will not generate distinct
closure classes for the different call sites where it is used. This means that when you are in the closure,
the type of 'x' is the one declared in the closure arguments. This means that without type information on 'x',
-x is supposed an Object, and the foo method which will be statically chosen will be the one with the Object argument.
-
-While this can be surprising, this is not really difficult to understand. To behave correctly,
+x is supposed an Object, and the foo method which will be statically chosen will be the one with the Object argument.</p>
+</div>
+<div class="paragraph">
+<p>While this can be surprising, this is not really difficult to understand. To behave correctly,
you must either add explicit type arguments to the closure, which is always preferred.
In a word, in a statically checked world, it is preferred to limit the places where types will be inferred so
-that code is understood properly. Even if you don't do it, fixing code is easy, so we think this is not a major issue.
-
-==== Java-like method dispatch
-
-The alternative implementation is not to rely on inferred types, but rather behave exactly like Java does.
-The main advantage of this is that the user doesn't have 3 distinct method dispatch modes to understand,
+that code is understood properly. Even if you don’t do it, fixing code is easy, so we think this is not a major issue.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_java_like_method_dispatch">Java-like method dispatch</h4>
+<div class="paragraph">
+<p>The alternative implementation is not to rely on inferred types, but rather behave exactly like Java does.
+The main advantage of this is that the user doesn’t have 3 distinct method dispatch modes to understand,
like in the previous solution (Java, dynamic Groovy, inferred static Groovy).
The major drawback is that the semantics of static Groovy are not close to the ones of dynamic Groovy.
For this reason, this is not the preferred experimental implementation. If you think this version should be preferred,
do not hesitate to send an email to the mailing list so that we can discuss.
-You can even fork the current implementation to provide your own.
-
-=== Testing
-
-Static compilation is now part of the Groovy 2.0.0 release. You can download the latest Groovy 2 releases and test it.
-
-==== @CompileStatic
-
-You can try the following snippet :
-
-```
-@groovy.transform.CompileStatic
+You can even fork the current implementation to provide your own.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_testing">Testing</h3>
+<div class="paragraph">
+<p>Static compilation is now part of the Groovy 2.0.0 release. You can download the latest Groovy 2 releases and test it.</p>
+</div>
+<div class="sect3">
+<h4 id="_compilestatic">@CompileStatic</h4>
+<div class="paragraph">
+<p>You can try the following snippet :</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>@groovy.transform.CompileStatic
int fib(int i) {
- i < 2 ? 1 : fib(i - 2) + fib(i - 1)
-}
-```
-
-This code should already run as fast as Java.
-
-==== The "arrow" operator for direct method calls
-
-Some users have suggested another idea, related to static compilation, which is the "arrow operator".
-Basically, the idea is to introduce another way of calling methods in Groovy :
-
-```
-obj.method() // dynamic dispatch
-obj->method() // static dispatch
-```
-
-While this idea sounds interesting, especially when you want to mix dynamic and static code in a single method,
+ i < 2 ? 1 : fib(i - 2) + fib(i - 1)
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This code should already run as fast as Java.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_the_arrow_operator_for_direct_method_calls">The "arrow" operator for direct method calls</h4>
+<div class="paragraph">
+<p>Some users have suggested another idea, related to static compilation, which is the "arrow operator".
+Basically, the idea is to introduce another way of calling methods in Groovy :</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>obj.method() // dynamic dispatch
+obj->method() // static dispatch</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>While this idea sounds interesting, especially when you want to mix dynamic and static code in a single method,
we think it has many drawbacks. First, it introduces a grammar change, something we would like to avoid as much as possible.
-Second, the idea behind this operator is to perform direct method calls when you *know* the type of an object.
-But, without type inference, you have two problems :
-
-* even if the type of 'obj' is specified, you cannot be sure that at runtime, the type will be the same
-* you still have to infer the argument types too, which leaves us with the same problem as before: relying on type inference,
+Second, the idea behind this operator is to perform direct method calls when you <strong>know</strong> the type of an object.
+But, without type inference, you have two problems :</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>even if the type of 'obj' is specified, you cannot be sure that at runtime, the type will be the same</p>
+</li>
+<li>
+<p>you still have to infer the argument types too, which leaves us with the same problem as before: relying on type inference,
or relying on Java-like behaviour where the method is chosen based on the declared types.
-If we do so, then we would introduce possible incompatibility with the static mode...
-So we would have to choose between this mode and the full static compilation mode.
-
-Imagine the following code :
-
-```
-void write(PrintWriter out) {
- out->write('Hello')
- out->write(template())
+If we do so, then we would introduce possible incompatibility with the static mode…​
+So we would have to choose between this mode and the full static compilation mode.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Imagine the following code :</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>void write(PrintWriter out) {
+ out->write('Hello')
+ out->write(template())
}
-def template() { new MarkupBuilder().html { p('Hello') } }
-```
-
-While the first call can be resolved easily, this is not the same with the second one.
-You would have to rewrite your code probably this way to have this work :
-
-```
-void write(PrintWriter out) {
- out->println('Hello')
+def template() { new MarkupBuilder().html { p('Hello') } }</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>While the first call can be resolved easily, this is not the same with the second one.
+You would have to rewrite your code probably this way to have this work :</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>void write(PrintWriter out) {
+ out->println('Hello')
String content = template() // dynamic call, implicit coercion to string
- out->println(content) // static method dispatch based on declared types only
+ out->println(content) // static method dispatch based on declared types only
}
-def template() { new MarkupBuilder().html { p('Hello') } }
-```
-
-Which is not necessary if you use the @CompileStatic annotation :
-
-```
-@CompileStatic
+def template() { new MarkupBuilder().html { p('Hello') } }</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Which is not necessary if you use the @CompileStatic annotation :</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>@CompileStatic
void write(PrintWriter out) {
out.println('Hello')
out.println(template())
}
-def template() { new MarkupBuilder().html { p('Hello') } }
-```
-
-== References and useful links
-
-* https://web.archive.org/web/20150508040816/http://docs.codehaus.org/display/GroovyJSR/GEP+10+-+Static+compilation[GEP-10: Static compilation] (web archive link)
-* http://blackdragsview.blogspot.com/2011/10/flow-sensitive-typing.html[Flow Sensitive Typing?]
-* https://web.archive.org/web/20150508040745/http://www.jroller.com/melix/entry/groovy_static_type_checker_status[Groovy static type checker: status update] (web archive)
-
-=== Mailing-list discussions
-
-* https://marc.info/?l=groovy-dev&m=132095119732500&w=2[groovy-dev: Static compilation for Groovy]: +
-An interesting discussion where dynamic lovers explain why they do not want static compilation
-
-=== JIRA issues
-
-* https://issues.apache.org/jira/browse/GROOVY-5138[GROOVY-5138: GEP-10 - Static compilation]
-
-== Update history
-
-3 (2012-06-21):: Version as extracted from Codehaus wiki
-4 (2018-10-26):: Numerous minor tweaks
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-10</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-10</h1><hr/></div></div></div></div><footer id='footer'>
+def template() { new MarkupBuilder().html { p('Hello') } }</code></pre>
+</div>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://web.archive.org/web/20150508040816/http://docs.codehaus.org/display/GroovyJSR/GEP+10+-+Static+compilation">GEP-10: Static compilation</a> (web archive link)</p>
+</li>
+<li>
+<p><a href="http://blackdragsview.blogspot.com/2011/10/flow-sensitive-typing.html">Flow Sensitive Typing?</a></p>
+</li>
+<li>
+<p><a href="https://web.archive.org/web/20150508040745/http://www.jroller.com/melix/entry/groovy_static_type_checker_status">Groovy static type checker: status update</a> (web archive)</p>
+</li>
+</ul>
+</div>
+<div class="sect2">
+<h3 id="_mailing_list_discussions">Mailing-list discussions</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://marc.info/?l=groovy-dev&m=132095119732500&w=2">groovy-dev: Static compilation for Groovy</a>:<br>
+An interesting discussion where dynamic lovers explain why they do not want static compilation</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_jira_issues">JIRA issues</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-5138">GROOVY-5138: GEP-10 - Static compilation</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">3 (2012-06-21)</dt>
+<dd>
+<p>Version as extracted from Codehaus wiki</p>
+</dd>
+<dt class="hdlist1">4 (2018-10-26)</dt>
+<dd>
+<p>Numerous minor tweaks</p>
+</dd>
+</dl>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-11.html b/wiki/GEP-11.html
index b2d7e41..fb2c21c 100644
--- a/wiki/GEP-11.html
+++ b/wiki/GEP-11.html
@@ -59,191 +59,332 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-11: Groovy 3 semantics and new MOP
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-11
-*Title*:: Groovy 3 semantics and new MOP
-*Version*:: 4
-*Type*:: Feature
-*Status*:: Draft
-*Leader*:: Jochen "blackdrag" Theodorou
-*Created*:: 2012-06-26
-*Last modification* :: 2018-10-28
-****
-
-== Abstract: Groovy 3 semantics and new MOP
-
-For some time we have been thinking about a new MOP for Groovy but haven't been able to decide on a final
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-11</a></li><li><a href='#_abstract_groovy_3_semantics_and_new_mop' class='anchor-link'>Abstract: Groovy 3 semantics and new MOP</a></li><li><a href='#_rationale' class='anchor-link'>Rationale</a></li><li><a href='#_references_and_useful_links' class='anchor-link'>References and useful links</a></li><li>< [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-11</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>Groovy 3 semantics and new MOP</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>4</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Draft</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Jochen "blackdrag" Theodorou</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2012-06-26</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2018-10-28</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract_groovy_3_semantics_and_new_mop">Abstract: Groovy 3 semantics and new MOP</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>For some time we have been thinking about a new MOP for Groovy but haven’t been able to decide on a final
design which mostly keeps backwards compatibility but also improves various cases that we want to improve.
It is difficult to find the right path between being user-friendly and efficient.
Thus the new MOP will contain some features the old did not, but will also remove some old features for
-the sake of a more straight and more easy to understand MOP.
-
-== Rationale
-
-=== Removing default null argument
-
-The default null argument is used for method calls that have one parameter,
+the sake of a more straight and more easy to understand MOP.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_rationale">Rationale</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_removing_default_null_argument">Removing default null argument</h3>
+<div class="paragraph">
+<p>The default null argument is used for method calls that have one parameter,
but the call is done without an argument for the parameter.
Groovy will here use null, as long as the type of the parameter is not a primitive.
In case of a primitive the call fails. This feature was mainly added in the early Groovy pre 1.0 years
before Groovy supported default values for parameters. Another limitation of this logic is that it works
only with single parameter methods. There have been multiple cases of confused users by this logic.
-Performance wise this logic doesn't cost much, and certainly not more than a call with a real argument.
-But since this is a confusing feature of limited use, it should be removed.
-
-=== Removing automatic list expansion
-
-A method call done with a list that finds no matching method for that list (a method with one parameter of type List,
+Performance wise this logic doesn’t cost much, and certainly not more than a call with a real argument.
+But since this is a confusing feature of limited use, it should be removed.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_removing_automatic_list_expansion">Removing automatic list expansion</h3>
+<div class="paragraph">
+<p>A method call done with a list that finds no matching method for that list (a method with one parameter of type List,
Collection, Object, etc.), will cause a second method selection iteration. This time the list is "unpacked" and all
elements of the list are taken as if the method call had been done with the elements rather than the list.
Groovy also supports spreading of lists by a syntax element, making this automatic feature not needed.
In fact this can be quite surprising for users and is a problem for performance.
A spread version might be still not good in performance, but at least the user will have
to use an extra symbol and thus have the visual indicator. As of why this feature was originally added is unclear.
-Looking at user code you will find barely intended usages of this. Thus it should be removed.
-
-=== Changing Safe Navigation to stop evaluation
-
-Currently an expression like a?.b.c will fail if a is null. It will not evaluate b, but it will try to evaluate c on null.
+Looking at user code you will find barely intended usages of this. Thus it should be removed.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_changing_safe_navigation_to_stop_evaluation">Changing Safe Navigation to stop evaluation</h3>
+<div class="paragraph">
+<p>Currently an expression like a?.b.c will fail if a is null. It will not evaluate b, but it will try to evaluate c on null.
This defies the intent of safe navigation to avoid a NullPointerException. Thus this should be changed to stop the
-evaluation of the path expression.
-
-=== User Wish List
-
-* Instance based Categories by Wujek Srujek +
+evaluation of the path expression.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_user_wish_list">User Wish List</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>Instance based Categories by Wujek Srujek<br>
Instead of having to provide a class with static methods it would be good to be able to feed an instance to the
-use-construct and that then we will use this instance along with its instance methods. This allows instance state to be used.
-* Replacing Introspector by blackdrag +
-Not only because of bugs like GROOVY-5019 there should be a replacement of the Introspector
-
-=== Some leading design ideas of this MOP
-
-The plan is to orientate us a lot on the open call site caching the JVM provides with invokedynamic.
+use-construct and that then we will use this instance along with its instance methods. This allows instance state to be used.</p>
+</li>
+<li>
+<p>Replacing Introspector by blackdrag<br>
+Not only because of bugs like GROOVY-5019 there should be a replacement of the Introspector</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_some_leading_design_ideas_of_this_mop">Some leading design ideas of this MOP</h3>
+<div class="paragraph">
+<p>The plan is to orientate us a lot on the open call site caching the JVM provides with invokedynamic.
For this to work all parts of the MOP should no longer be seen as places that do invoke something,
but as places that return something, that then will be invoked. An invokeMethod then will for example
return instead an object that acts as a kind of handler, which can be invoked.
Groovy will then store it and avoid the reselection unless you invalidate it.
In the old MOP such caching often did not happen once you interact using meta programming.
The tasks to be solved in this are to provide an "extension point" for intercepting methods and to react to
-missing methods, as well as being able to invalidate a cached version and/or to make an uncached version possible.
-
-=== MOP2 outline
-
-image:img/mop_2.jpg[image]
-
-in metaclass of x in pseudocode:
-
-```
-cachable = getMethodInterceptor(...)
+missing methods, as well as being able to invalidate a cached version and/or to make an uncached version possible.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_mop2_outline">MOP2 outline</h3>
+<div class="paragraph">
+<p><span class="image"><img src="img/mop_2.jpg" alt="image"></span></p>
+</div>
+<div class="paragraph">
+<p>in metaclass of x in pseudocode:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>cachable = getMethodInterceptor(...)
if (cachable==null) cachable = getFittingMethod(...)
if (cachable==null) getMethodMissingHandler(...)
if (cachable==null) throw new MethodMissingException(...)
storeInCallSite(cachable)
-invoke(cachable)
-```
-
-as an explanation to the methods:
-
-* getMethodInterceptor +
+invoke(cachable)</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>as an explanation to the methods:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>getMethodInterceptor<br>
Extension point for the user to register an interceptor, that will be used for all method calls.
This is equal to what GroovyInterceptable does using invokeMethod, only that in MOP1 the method is directly called.
In MOP2 we will instead return a handler that then will do whatever is needed. This can for example be a method
-handle to a invokeMethod method if wanted. TODO: define guards
-* getFittingMethod +
+handle to a invokeMethod method if wanted. TODO: define guards</p>
+</li>
+<li>
+<p>getFittingMethod<br>
Predefined way to select a method through metaclass. This method will return an
-object which then can be used to invoke the selected method.
-* getMethodMissingHandler +
+object which then can be used to invoke the selected method.</p>
+</li>
+<li>
+<p>getMethodMissingHandler<br>
Extension point for the user to register a handler for missing methods.
-The then invoked method is comparable to what methodMissing in MOP1 would be doing.
-* MethodMissingException +
-thrown if none of the above methods is bearing a non-null result
-* storeInCallSite +
+The then invoked method is comparable to what methodMissing in MOP1 would be doing.</p>
+</li>
+<li>
+<p>MethodMissingException<br>
+thrown if none of the above methods is bearing a non-null result</p>
+</li>
+<li>
+<p>storeInCallSite<br>
Predefined method to store the cachable result of the above process in the call site.
-As long as the cached object is valid the above methods will not be called again for this call site.
-* invoke +
-Predefined method to do the Initial invocation of the cachable. Subsequent invocation may be done directly by invokedynamic.
-
-=== Context Meta Class
-
-For the MOP2 Groovy will use a system of metaclasses with a context element and an always existing default.
+As long as the cached object is valid the above methods will not be called again for this call site.</p>
+</li>
+<li>
+<p>invoke<br>
+Predefined method to do the Initial invocation of the cachable. Subsequent invocation may be done directly by invokedynamic.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_context_meta_class">Context Meta Class</h3>
+<div class="paragraph">
+<p>For the MOP2 Groovy will use a system of metaclasses with a context element and an always existing default.
At each call site only one such view will be valid and it will be constant.
-Those views can be used to defined "sealed" metaclass, which won't get influenced by outside
+Those views can be used to defined "sealed" metaclass, which won’t get influenced by outside
metaclasses or to allow for example calling private methods and not allowing them in other cases.
-This makes 3 possible metaclass variations currently:
-
-* Default metaclass +
+This makes 3 possible metaclass variations currently:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Default metaclass<br>
Behaves pretty much like what Java allows in regard to method calls (same class private methods are available)
-and all meta programming changes are visible
-* Sealed metaclass +
+and all meta programming changes are visible</p>
+</li>
+<li>
+<p>Sealed metaclass<br>
Like the default metaclass, but meta programming changes from outside the class are not visible.
-This can be especially useful to library writers.
-* Test metaclass (un)sealed +
-Like the two before but with the addition that private members will always be available.
-
-=== Getting a Meta Class
-
-Because of the concept of context a class does not have one direct metaclass that can be generated without its context.
+This can be especially useful to library writers.</p>
+</li>
+<li>
+<p>Test metaclass (un)sealed<br>
+Like the two before but with the addition that private members will always be available.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_getting_a_meta_class">Getting a Meta Class</h3>
+<div class="paragraph">
+<p>Because of the concept of context a class does not have one direct metaclass that can be generated without its context.
The call site defines the place of the context. How the context itself is defined is a TODO.
As an implementation strategy it is possible to for example use ClassValue to store a table with the context being a key.
The key would probably have to be available as static information, or as easily computable information.
Since the resulting metaclass could be stored later in the call site object context changes are to be avoided,
-since it implies the invalidation of the call sites using that context.
-
-=== General dispatch rule for methods (and properties)
-
-To define the dispatch rules correctly we need to define some terms first: +
-_Static Sender Class (SSC)_: This is the static information about the class a call is made from.
+since it implies the invalidation of the call sites using that context.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_general_dispatch_rule_for_methods_and_properties">General dispatch rule for methods (and properties)</h3>
+<div class="paragraph">
+<p>To define the dispatch rules correctly we need to define some terms first:<br>
+<em>Static Sender Class (SSC)</em>: This is the static information about the class a call is made from.
If there is for example a class A and a class B extends A, and a call in a method in A,
-then even if your instance is actually a B the SSC will still be A. +
-_Inheritance based Multimethods_ (short multimethods from now on): Given a class A and a class B extends A,
+then even if your instance is actually a B the SSC will still be A.<br>
+<em>Inheritance based Multimethods</em> (short multimethods from now on): Given a class A and a class B extends A,
a call made from within A may see a method defined on B as long as the method is visible (not private).
Groovy defines a special exception to this though. If the method call from within A is calling a method of the name m,
-then a m from B can only be visible if there is no private m defined in A.
-
-Given those two definitions a method call in A will select the set of method to decide from based on this:
-A call m() with the SSC A and done on an instance of B (extends A) will be using the methods defined in A, if A has a private m, otherwise the call is done using B.
-
-Calls to Super: +
-A call to super in B extends A will have the SSC B, but for the method selection process the super class of SSC (super(SSC)) will be used. In super calls multimethods are not visible. Thus we can directly use the metaclass super(SSC), but we will dispatch only on the public methods of that metaclass.
-
-=== Module Extension Methods Shadowing Rules
-
-Module Extensions Methods are in the old and new MOP defined by the DefaultGroovyMethods related classes and module extension, like groovy-swing. In the definition here we will use the terms of from "inside" and from "outside" to define a callsite, that lies in the same class as the target method (inside) or not (outside). The general rules are:
-
-* public methods are shadowed
-* private methods are shadowed for outside callsites, but not for inside callsites
-
-Subclasses of the class the module extension method has been applied to have these extended rules:
-
-* if the subclass defines a private method of the same signature as the module extension method, then outside callsites will still see the extension method, inside callsites the private method
-* A call to "super" or "this" will call the module extension method. As such the subclass is seen as outside callsite.
-
-Open Blocks are not seen as separate classes.
-
-=== Property Discovery
-
-Currently MetaClass discovers properties based on the Java Beans conventions.
+then a m from B can only be visible if there is no private m defined in A.</p>
+</div>
+<div class="paragraph">
+<p>Given those two definitions a method call in A will select the set of method to decide from based on this:
+A call m() with the SSC A and done on an instance of B (extends A) will be using the methods defined in A, if A has a private m, otherwise the call is done using B.</p>
+</div>
+<div class="paragraph">
+<p>Calls to Super:<br>
+A call to super in B extends A will have the SSC B, but for the method selection process the super class of SSC (super(SSC)) will be used. In super calls multimethods are not visible. Thus we can directly use the metaclass super(SSC), but we will dispatch only on the public methods of that metaclass.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_module_extension_methods_shadowing_rules">Module Extension Methods Shadowing Rules</h3>
+<div class="paragraph">
+<p>Module Extensions Methods are in the old and new MOP defined by the DefaultGroovyMethods related classes and module extension, like groovy-swing. In the definition here we will use the terms of from "inside" and from "outside" to define a callsite, that lies in the same class as the target method (inside) or not (outside). The general rules are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>public methods are shadowed</p>
+</li>
+<li>
+<p>private methods are shadowed for outside callsites, but not for inside callsites</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Subclasses of the class the module extension method has been applied to have these extended rules:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>if the subclass defines a private method of the same signature as the module extension method, then outside callsites will still see the extension method, inside callsites the private method</p>
+</li>
+<li>
+<p>A call to "super" or "this" will call the module extension method. As such the subclass is seen as outside callsite.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Open Blocks are not seen as separate classes.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_property_discovery">Property Discovery</h3>
+<div class="paragraph">
+<p>Currently MetaClass discovers properties based on the Java Beans conventions.
It also allows pseudo properties matching a convention on java.beans.EventSetDescriptor.
-This allows the following trick in SwingBuilder for example:
-
-```
-button(actionPerformed: { println it })
-```
-
-The pseudo property actionPerformed is inferred from the single method exposed by ActionListener,
+This allows the following trick in SwingBuilder for example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>button(actionPerformed: { println it })</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The pseudo property actionPerformed is inferred from the single method exposed by ActionListener,
a type of listener that can be registered on a JButton. The code responsible for discovering these
properties is buried in MetaClassImpl and is not accessible to the outside.
-It would be great if this mechanism be made pluggable.
-
-=== The Realm concept
-
-In MOP2 a Realm is a tree like structure containing the metaclasses.
+It would be great if this mechanism be made pluggable.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_the_realm_concept">The Realm concept</h3>
+<div class="paragraph">
+<p>In MOP2 a Realm is a tree like structure containing the metaclasses.
There is a root realm, used as default, but there can be any number of lower realms.
A metaclass change is visible in a realm, if the change is done to the metaclass in
the same realm or to a metaclass in a higher realm.
@@ -255,81 +396,206 @@ changes more public visible, if the realm allows that. Realms can have a setting
code executed from there to make changes to higher realms. Calling a method is always done using
the metaclasses from the current realm, even if the called class then calls other classes using
its own realm. A realm is thus not thread local structure, it is more of a lexical scope.
-A realm can also use a different metaclass flavor, to for example allow access to private methods and fields.
-
-=== Work Items
-
-This part is to guide the implementors with the course of action and planning of the subtasks.
-
-* make indy the only compilation target in the build
-* move all non-indy bytecode interfacing code to a module, which may be removed later. This includes ScriptBytecodeAdapter as well as all the custom call site caching classes
-* make a new module for MOP2
-* turn metaclass into an immutable
-* implement metaclass views
-
-=== Breaking changes trace
-
-`groovy.lang.MetaObjectProtocol` (currently in `groovy.mop.MetaObjectProtocol`):
-
-* `getProperties()` renamed to `getMetaProperties()`
-* `getMethods()` renamed to `getMetaMethods()`
-* `respondsTo(Object, String, Object[])` changed to `respondsTo(String, Object...)`
-* `respondsTo(Object, String)` replaced by `getMetaMethods(String, Class...)` with the class argument being null
-* hasProperty(Object,String) replaced by getMetaProperty(String) being null or not
-* getStaticMetaMethod(String, Object[]) replaced by respondsTo(String, Object...) and inspecting the list for static methods
-* getMetaMethod(name, Object[]) replaced by respondsTo(String, Object...) in case the arguments are no classes and getMetaMethods(String,Class...) in case of the arguments being classes
-* invokeConstructor(Object[])NO REPLACEMENT
-* invokeMethod(Object, String, Object[]) NO REPLACEMENT
-* invokeMethod(Object, String, Object) NO REPLACEMENT
-* invokeStaticMethod(Object, String, Object[]) NO REPLACEMENT
-* getProperty(Object, String) replaced by MetaProperty#invoke
-* setProperty(Object, String, Object) replaced by MetaProperty#invoke
-* getAttribute(Object, String) replaced by MetaProperty#getField#invoke
-* setAttribute(Object, String, Object) replaced by MetaProperty#getField#invoke
-* `getMetaProperty(String)`, `getTheClass()` UNCHANGED
-
-`groovy.lang.MetaMethod` is split into a public interface `groovy.mop.MetaMethod` and an internal default implementation `groovy.mop.internal.DefaultMetaMethod`.
-
-Differences to groovy.mop.internal.DefaultMetaMethod:
-
-* does no longer extend ParameterTypes and does no longer implement Clonable
-* no protected fields nativeParamTypes, parameterTypes and isVargsMethod
-* the constructor MetaMethod() and MetaMethod(Class[]) are removed and partially replaced by DefaultMetaMethod(Class, String, int, MethodHandle) and DefaultMetaMethod(Class, String, MethodType), which uses the MethodType or the MethodHandle to define the parameter classes
-* coerceArgumentsToClasses(Object[]), correctArguments(Object[]), isValidExactMethod(Class[]), isValidExactMethod(Object[]), isValidMethod(Class[]), isValidMethod(Object[]), isVargsMethod(), isVargsMethod(Object[]) NO REPLACEMENT
-* getNativeParameterTypes()replaced by getParameterClasses()
-* equal(CachedClass[], CachedClass[]), equal(CachedClass[], Class[]), checkParameters(Class[]), clone(), doMethodInvoke(Object, Object[]), getDescriptor() NO REPLACEMENT
-* getDeclaringClass(), getModifiers(), getName(), getReturnType(), isAbstract(), isPrivate(), isProtected(), isPublic(), isStatic(), toString() UNCHANGED
-* getMopName(), getSignature(), invoke(Object, Object[]), isCacheable(), isMethod(MetaMethod), isSame(MetaMethod), processDoMethodInvokeException(Exception, Object, Object[]) NO REPLACEMENT
-
-`groovy.lang.MetaProperty` is split into a public interface `groovy.mop.MetaProperty` and an internal default implementation `groovy.mop.internal.DefaultMetaProperty`.
-
-Differences to groovy.mop.internal.DefaultMetaProperty:
-
-* the public static field PROPERTY_SET_PREFIX is removed NO REPLACEMENT
-* the protected fields name and type are now private and have to be requested through getName and getType
-* getModifiers(), getName(), getType(), DefaultMetaProperty(String, Class) UNCHANGED
-* getGetterName(String, Class), getSetterName(String)NO REPLACEMENT
-* getProperty(Object) replaced by getter(boolean)
-* setProperty(Object, Object) replaced by setter(boolean)
-
-== References and useful links
-
-* https://web.archive.org/web/20150508123746/http://docs.codehaus.org/display/GroovyJSR/GEP+11+-+Groovy+3+semantics+and+new+MOP[GEP-11: Groovy 3 semantics and new MOP] (web archive link)
-
-=== Mailing-list discussions
-
-* https://marc.info/?l=groovy-user&m=134070969008201&w=2[groovy-user: Groovy 3]
-
-=== Reference implementation
-
-* https://github.com/groovy/groovy-core/tree/GROOVY_3_FEATURE[GROOVY_3_FEATURE] +
-feature branch on GitHub
-
-== Update history
-
-3 (2013-10-11):: Version as extracted from Codehaus wiki
-4 (2018-10-28):: Numerous minor tweaks
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-11</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-11</h1><hr/></div></div></div></div><footer id='footer'>
+A realm can also use a different metaclass flavor, to for example allow access to private methods and fields.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_work_items">Work Items</h3>
+<div class="paragraph">
+<p>This part is to guide the implementors with the course of action and planning of the subtasks.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>make indy the only compilation target in the build</p>
+</li>
+<li>
+<p>move all non-indy bytecode interfacing code to a module, which may be removed later. This includes ScriptBytecodeAdapter as well as all the custom call site caching classes</p>
+</li>
+<li>
+<p>make a new module for MOP2</p>
+</li>
+<li>
+<p>turn metaclass into an immutable</p>
+</li>
+<li>
+<p>implement metaclass views</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_breaking_changes_trace">Breaking changes trace</h3>
+<div class="paragraph">
+<p><code>groovy.lang.MetaObjectProtocol</code> (currently in <code>groovy.mop.MetaObjectProtocol</code>):</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><code>getProperties()</code> renamed to <code>getMetaProperties()</code></p>
+</li>
+<li>
+<p><code>getMethods()</code> renamed to <code>getMetaMethods()</code></p>
+</li>
+<li>
+<p><code>respondsTo(Object, String, Object[])</code> changed to <code>respondsTo(String, Object…​)</code></p>
+</li>
+<li>
+<p><code>respondsTo(Object, String)</code> replaced by <code>getMetaMethods(String, Class…​)</code> with the class argument being null</p>
+</li>
+<li>
+<p>hasProperty(Object,String) replaced by getMetaProperty(String) being null or not</p>
+</li>
+<li>
+<p>getStaticMetaMethod(String, Object[]) replaced by respondsTo(String, Object…​) and inspecting the list for static methods</p>
+</li>
+<li>
+<p>getMetaMethod(name, Object[]) replaced by respondsTo(String, Object…​) in case the arguments are no classes and getMetaMethods(String,Class…​) in case of the arguments being classes</p>
+</li>
+<li>
+<p>invokeConstructor(Object[])NO REPLACEMENT</p>
+</li>
+<li>
+<p>invokeMethod(Object, String, Object[]) NO REPLACEMENT</p>
+</li>
+<li>
+<p>invokeMethod(Object, String, Object) NO REPLACEMENT</p>
+</li>
+<li>
+<p>invokeStaticMethod(Object, String, Object[]) NO REPLACEMENT</p>
+</li>
+<li>
+<p>getProperty(Object, String) replaced by MetaProperty#invoke</p>
+</li>
+<li>
+<p>setProperty(Object, String, Object) replaced by MetaProperty#invoke</p>
+</li>
+<li>
+<p>getAttribute(Object, String) replaced by MetaProperty#getField#invoke</p>
+</li>
+<li>
+<p>setAttribute(Object, String, Object) replaced by MetaProperty#getField#invoke</p>
+</li>
+<li>
+<p><code>getMetaProperty(String)</code>, <code>getTheClass()</code> UNCHANGED</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p><code>groovy.lang.MetaMethod</code> is split into a public interface <code>groovy.mop.MetaMethod</code> and an internal default implementation <code>groovy.mop.internal.DefaultMetaMethod</code>.</p>
+</div>
+<div class="paragraph">
+<p>Differences to groovy.mop.internal.DefaultMetaMethod:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>does no longer extend ParameterTypes and does no longer implement Clonable</p>
+</li>
+<li>
+<p>no protected fields nativeParamTypes, parameterTypes and isVargsMethod</p>
+</li>
+<li>
+<p>the constructor MetaMethod() and MetaMethod(Class[]) are removed and partially replaced by DefaultMetaMethod(Class, String, int, MethodHandle) and DefaultMetaMethod(Class, String, MethodType), which uses the MethodType or the MethodHandle to define the parameter classes</p>
+</li>
+<li>
+<p>coerceArgumentsToClasses(Object[]), correctArguments(Object[]), isValidExactMethod(Class[]), isValidExactMethod(Object[]), isValidMethod(Class[]), isValidMethod(Object[]), isVargsMethod(), isVargsMethod(Object[]) NO REPLACEMENT</p>
+</li>
+<li>
+<p>getNativeParameterTypes()replaced by getParameterClasses()</p>
+</li>
+<li>
+<p>equal(CachedClass[], CachedClass[]), equal(CachedClass[], Class[]), checkParameters(Class[]), clone(), doMethodInvoke(Object, Object[]), getDescriptor() NO REPLACEMENT</p>
+</li>
+<li>
+<p>getDeclaringClass(), getModifiers(), getName(), getReturnType(), isAbstract(), isPrivate(), isProtected(), isPublic(), isStatic(), toString() UNCHANGED</p>
+</li>
+<li>
+<p>getMopName(), getSignature(), invoke(Object, Object[]), isCacheable(), isMethod(MetaMethod), isSame(MetaMethod), processDoMethodInvokeException(Exception, Object, Object[]) NO REPLACEMENT</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p><code>groovy.lang.MetaProperty</code> is split into a public interface <code>groovy.mop.MetaProperty</code> and an internal default implementation <code>groovy.mop.internal.DefaultMetaProperty</code>.</p>
+</div>
+<div class="paragraph">
+<p>Differences to groovy.mop.internal.DefaultMetaProperty:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>the public static field PROPERTY_SET_PREFIX is removed NO REPLACEMENT</p>
+</li>
+<li>
+<p>the protected fields name and type are now private and have to be requested through getName and getType</p>
+</li>
+<li>
+<p>getModifiers(), getName(), getType(), DefaultMetaProperty(String, Class) UNCHANGED</p>
+</li>
+<li>
+<p>getGetterName(String, Class), getSetterName(String)NO REPLACEMENT</p>
+</li>
+<li>
+<p>getProperty(Object) replaced by getter(boolean)</p>
+</li>
+<li>
+<p>setProperty(Object, Object) replaced by setter(boolean)</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://web.archive.org/web/20150508123746/http://docs.codehaus.org/display/GroovyJSR/GEP+11+-+Groovy+3+semantics+and+new+MOP">GEP-11: Groovy 3 semantics and new MOP</a> (web archive link)</p>
+</li>
+</ul>
+</div>
+<div class="sect2">
+<h3 id="_mailing_list_discussions">Mailing-list discussions</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://marc.info/?l=groovy-user&m=134070969008201&w=2">groovy-user: Groovy 3</a></p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_reference_implementation">Reference implementation</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://github.com/groovy/groovy-core/tree/GROOVY_3_FEATURE">GROOVY_3_FEATURE</a><br>
+feature branch on GitHub</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">3 (2013-10-11)</dt>
+<dd>
+<p>Version as extracted from Codehaus wiki</p>
+</dd>
+<dt class="hdlist1">4 (2018-10-28)</dt>
+<dd>
+<p>Numerous minor tweaks</p>
+</dd>
+</dl>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-12.html b/wiki/GEP-12.html
index 936939c..cb13118 100644
--- a/wiki/GEP-12.html
+++ b/wiki/GEP-12.html
@@ -59,127 +59,247 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-12: SAM coercion
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-12
-*Title*:: SAM coercion
-*Version*:: 4
-*Type*:: Feature
-*Status*:: Final
-*Leader*:: Jochen "blackdrag" Theodorou
-*Created*:: 2013-05-30
-*Last modification* :: 2018-10-29
-****
-
-== Abstract: SAM coercion
-
-SAM stands for Single Abstract Method.
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-12</a></li><li><a href='#_abstract_sam_coercion' class='anchor-link'>Abstract: SAM coercion</a></li><li><a href='#_references_and_useful_links' class='anchor-link'>References and useful links</a></li><li><a href='#_update_history' class='anchor-link'>Update history</a></li></ul></div><div class='col-lg-8 [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-12</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>SAM coercion</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>4</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Final</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Jochen "blackdrag" Theodorou</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2013-05-30</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2018-10-29</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract_sam_coercion">Abstract: SAM coercion</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>SAM stands for Single Abstract Method.
A SAM type is an abstract class or interface with a single abstract method.
SAM coercion involves transforming a
-`groovy.lang.Closure` instance into an object suitable for our SAM type.
+<code>groovy.lang.Closure</code> instance into an object suitable for our SAM type.
The coercion can happen as part of an assignment or as the result of a method call.
Since this transformation might be outside the types provided by Closure itself,
it can be more than a simple Java style cast.
Closure becomes a kind of subtype to all SAM types.
Groovy has other such transformations without explicit cast or asType usage,
-which are number object transformations as well as the conversion of GString to String.
-
-=== Motivation
-Even before Java8 we had discussions about supporting different interfaces with Closure like Runnable and Callable.
+which are number object transformations as well as the conversion of GString to String.</p>
+</div>
+<div class="sect2">
+<h3 id="_motivation">Motivation</h3>
+<div class="paragraph">
+<p>Even before Java8 we had discussions about supporting different interfaces with Closure like Runnable and Callable.
These two being easy cases, any framework can define a myriad of interfaces and abstract classes.
This then requires to "groovify" the library by writing a helper layer capable of transforming Closure
objects into something the library then understand. While it is unlikely of this approach to make Groovy
-Builder surplus, it can still help with a more simple integration.
-
-==== Meaning of "Single Abstract Method"
-
-For a SAM type to be a SAM type according to this GEP an abstract class or interface with a single
+Builder surplus, it can still help with a more simple integration.</p>
+</div>
+<div class="sect3">
+<h4 id="_meaning_of_single_abstract_method">Meaning of "Single Abstract Method"</h4>
+<div class="paragraph">
+<p>For a SAM type to be a SAM type according to this GEP an abstract class or interface with a single
abstract method is required. Any static methods, as well as non-abstract methods are not counted.
The abstract method may be defined in the SAM class itself, but it can also be a parent.
-The required visibility modifier for the method is public though.
-
-SAM examples:
-
-* Simple Interface:
-
-```
-interface SAM {
+The required visibility modifier for the method is public though.</p>
+</div>
+<div class="paragraph">
+<p>SAM examples:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Simple Interface:</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>interface SAM {
def foo()
-}
-```
-
-* Interface with defender method (aka virtual extension method):
-
-```
-interface SAM {
+}</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Interface with defender method (aka virtual extension method):</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>interface SAM {
def foo()
def bar() default { 1 }
-}
-```
-
-* Interface inheriting from another interface:
-
-```
-interface ParentOfSAM {}
+}</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Interface inheriting from another interface:</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>interface ParentOfSAM {}
interface SAM extends ParentOfSAM {
def foo()
-}
-```
-
-* Interface inheriting from another interface, but not defining a method on its own:
-
-```
-interface ParentOfSAM {
+}</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Interface inheriting from another interface, but not defining a method on its own:</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>interface ParentOfSAM {
def foo()
}
-interface SAM extends ParentOfSAM {}
-```
-
-* simple abstract class
-
-```
-abstract class SAM {
+interface SAM extends ParentOfSAM {}</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>simple abstract class</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>abstract class SAM {
abstract foo()
-}
-```
-
-* abstract class with an abstract and a non-abstract method:
-
-```
-abstract class SAM {
+}</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>abstract class with an abstract and a non-abstract method:</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>abstract class SAM {
abstract foo()
def bar() { 1 }
-}
-```
-
-* abstract class extending other class:
-
-```
-abstract class ParentOfSAM1 {
+}</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>abstract class extending other class:</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>abstract class ParentOfSAM1 {
abstract foo()
-}
-```
-
-* abstract class SAM1 extends ParentOfSAM1 {}
-
-```
-class ParentOfSAM {
+}</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>abstract class SAM1 extends ParentOfSAM1 {}</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>class ParentOfSAM {
def bar() { 1 }
}
abstract class SAM2 extends {
abstract foo()
-}
-```
-
-* abstract class implementing interface:
-
-```
-interface SomeInterface{
+}</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>abstract class implementing interface:</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>interface SomeInterface{
def foo()
}
abstract class SAM1 implements SomeInterface {}
@@ -187,44 +307,71 @@ abstract class SAM2 implements Runnable{}
interface AnotherInterface {}
abstract class SAM3 implements AnotherInterface {
abstract foo()
-}
-```
-
-Non-SAM examples:
-
-* empty interface:
-
-```
-interface SomeMarker {}
-```
-
-* interface with two methods:
-
-```
-interface TwoMethods {
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Non-SAM examples:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>empty interface:</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>interface SomeMarker {}</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>interface with two methods:</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>interface TwoMethods {
def foo()
def bar()
-}
-```
-
-* abstract class with two abstract methods:
-
-```
-abstract class TwoMethods {
+}</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>abstract class with two abstract methods:</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>abstract class TwoMethods {
abstract foo()
abstract bar()
-}
-```
-
-* empty abstract class:
-
-```
-abstract class Empty {}
-```
-
-==== Influence on method selection
-
-The normal method selection algorithm tries to find the most specific method to the given argument
+}</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>empty abstract class:</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>abstract class Empty {}</code></pre>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_influence_on_method_selection">Influence on method selection</h4>
+<div class="paragraph">
+<p>The normal method selection algorithm tries to find the most specific method to the given argument
runtime types and the most general for null. Since a SAM type and a target method parameter type
are not in an inheritance relation "most specific" needs a redefinition in parts.
It will be assumed the SAM type is like a direct child of the given target type,
@@ -233,63 +380,109 @@ then no SAM coercion will be needed. This case is preferred in method selection.
In case of an overloaded method, where each can be used as target for the SAM coercion,
method selection will thus fail, regardless their internal relation.
In Groovy the actual method signature of the SAM type and the coercion target are not important.
-Also it is not important if the target type is an abstract class or an interface.
-
-Example of two SAM targets with failing runtime method selection:
-
-```
-interface SAM1 { def foo(String s)}
+Also it is not important if the target type is an abstract class or an interface.</p>
+</div>
+<div class="paragraph">
+<p>Example of two SAM targets with failing runtime method selection:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>interface SAM1 { def foo(String s)}
interface SAM2 { def bar(Integer i)}
def method(x, SAM1 s1){s1.foo(x)}
def method(x, SAM2 s2){s2.bar(x)}
method (1) {it} // fails because SAM1 and SAM2 are seen as equal
-method ("1") {it} // fails because SAM1 and SAM2 are seen as equal
-```
-
-Example of SAM type being ignore as a non-coercion case is available:
-
-```
-interface SAM {def foo(String s)}
+method ("1") {it} // fails because SAM1 and SAM2 are seen as equal</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Example of SAM type being ignore as a non-coercion case is available:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>interface SAM {def foo(String s)}
def method(SAM s) {1}
def method(Runnable r) {2}
-assert method {it} == 2
-```
-
-==== Influence on static typing system
-
-The Scope for the static type system is split into a basic part for Groovy 2.2 and an extended one
-for a later version (2.3 or 3.0)
-
-==== Groovy 2.2 static checks
-
-The type checking in Groovy 2.2 will be limited to mimic the behavior of normal Groovy.
+assert method {it} == 2</code></pre>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_influence_on_static_typing_system">Influence on static typing system</h4>
+<div class="paragraph">
+<p>The Scope for the static type system is split into a basic part for Groovy 2.2 and an extended one
+for a later version (2.3 or 3.0)</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_groovy_2_2_static_checks">Groovy 2.2 static checks</h4>
+<div class="paragraph">
+<p>The type checking in Groovy 2.2 will be limited to mimic the behavior of normal Groovy.
No method signature checks are performed, as well as there will be no additional test or method
-selection based on the type provided by the open block.
-
-==== Groovy 2.2+ static checks
-
-In later versions of Groovy the static type checker has to be improved to refine method selection by the given type
+selection based on the type provided by the open block.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_groovy_2_2_static_checks_2">Groovy 2.2+ static checks</h4>
+<div class="paragraph">
+<p>In later versions of Groovy the static type checker has to be improved to refine method selection by the given type
signature through the open block or lambda. A SAM type is then a fitting type for the coercion only if the provided
types and the target types in the SAM are matching by number and type itself. A more detailed description can be
-found here: https://cr.openjdk.org/~dlsmith/jsr335/jsr335-0.6.2/F.html
-
-== References and useful links
-
-* https://web.archive.org/web/20150508054422/http://docs.codehaus.org/display/GroovyJSR/GEP+12+-+SAM+coercion[GEP-12: SAM coercion] (web archive link)
-
-=== Reference implementation
-
-* https://github.com/groovy/groovy-core/commits/SAM (feature branch on GitHub)
-
-=== JIRA issues
-
-* https://issues.apache.org/jira/browse/GROOVY-6188[GROOVY-6188: Java8 lambda style coercion for Closure]
-
-== Update history
-
-3 (2013-07-01):: Version as extracted from Codehaus wiki
-4 (2018-10-29):: Numerous minor tweaks
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-12</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-12</h1><hr/></div></div></div></div><footer id='footer'>
+found here: <a href="https://cr.openjdk.org/~dlsmith/jsr335/jsr335-0.6.2/F.html" class="bare">https://cr.openjdk.org/~dlsmith/jsr335/jsr335-0.6.2/F.html</a></p>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://web.archive.org/web/20150508054422/http://docs.codehaus.org/display/GroovyJSR/GEP+12+-+SAM+coercion">GEP-12: SAM coercion</a> (web archive link)</p>
+</li>
+</ul>
+</div>
+<div class="sect2">
+<h3 id="_reference_implementation">Reference implementation</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://github.com/groovy/groovy-core/commits/SAM" class="bare">https://github.com/groovy/groovy-core/commits/SAM</a> (feature branch on GitHub)</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_jira_issues">JIRA issues</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-6188">GROOVY-6188: Java8 lambda style coercion for Closure</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">3 (2013-07-01)</dt>
+<dd>
+<p>Version as extracted from Codehaus wiki</p>
+</dd>
+<dt class="hdlist1">4 (2018-10-29)</dt>
+<dd>
+<p>Numerous minor tweaks</p>
+</dd>
+</dl>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-13.html b/wiki/GEP-13.html
index 0f6c606..0f537b8 100644
--- a/wiki/GEP-13.html
+++ b/wiki/GEP-13.html
@@ -59,127 +59,254 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-13: Sealed classes
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-13
-*Title*:: Sealed classes
-*Version*:: 1
-*Type*:: Feature
-*Status*:: Draft
-*Leader*:: Paul King
-*Created*:: 2021-07-22
-*Last modification* :: 2021-07-22
-****
-
-== Abstract: Sealed classes
-
-Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them.
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-13</a></li><li><a href='#_abstract_sealed_classes' class='anchor-link'>Abstract: Sealed classes</a></li><li><a href='#_references_and_useful_links' class='anchor-link'>References and useful links</a></li><li><a href='#_update_history' class='anchor-link'>Update history</a></li></ul></div><div class='col- [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-13</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>Sealed classes</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>1</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Draft</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Paul King</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2021-07-22</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2021-07-22</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract_sealed_classes">Abstract: Sealed classes</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them.
By supporting sealed classes and interfaces, the Groovy programming language
-can offer an additional mechanism for controlling class hierarchy construction.
-
-=== Motivation
-
-Inheritance is a powerful mechanism for creating hierarchies of related class and interfaces.
+can offer an additional mechanism for controlling class hierarchy construction.</p>
+</div>
+<div class="sect2">
+<h3 id="_motivation">Motivation</h3>
+<div class="paragraph">
+<p>Inheritance is a powerful mechanism for creating hierarchies of related class and interfaces.
Sometimes, it is desirable to restrict the definition of children in such hierarchies.
-Modifiers already provide some mechanisms:
-
-* If all of our classes and interfaces are public, this indicates that we want
-maximum reuse.
-
-* The `final` modifier offers one mechanism for restricting further inheritance at the method or class level.
-It effectively limits all further extension and indicates no further code reuse is desired.
-
-* By making a base class package-private we can limit extension to only classes within
-the same package. If an abstract `Shape` class is package-private, we could have
-public classes `Square` and `Circle` in the same package. This indicates that we want
+Modifiers already provide some mechanisms:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>If all of our classes and interfaces are public, this indicates that we want
+maximum reuse.</p>
+</li>
+<li>
+<p>The <code>final</code> modifier offers one mechanism for restricting further inheritance at the method or class level.
+It effectively limits all further extension and indicates no further code reuse is desired.</p>
+</li>
+<li>
+<p>By making a base class package-private we can limit extension to only classes within
+the same package. If an abstract <code>Shape</code> class is package-private, we could have
+public classes <code>Square</code> and <code>Circle</code> in the same package. This indicates that we want
code reuse to occur only within the package. While it does limit creation of
new shapes outside the original package, it offers no abstraction for a shape which
-could be either a square or circle since `Shape` is not public.
-
-* We can use `protected` visibility to limit access of members strictly to children
-but that doesn't help us solve the aforementioned problems like lack of a visible
-abstraction for `Shape` in the discussed example.
-
-Sealed classes or interfaces can be public but have an associated list of allowed children.
+could be either a square or circle since <code>Shape</code> is not public.</p>
+</li>
+<li>
+<p>We can use <code>protected</code> visibility to limit access of members strictly to children
+but that doesn’t help us solve the aforementioned problems like lack of a visible
+abstraction for <code>Shape</code> in the discussed example.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Sealed classes or interfaces can be public but have an associated list of allowed children.
Classes or interfaces which are not in that list cannot inherit from those sealed types.
This indicates that we want code reuse within the hierarchy but not beyond.
-Parent classes in the hierarchy can be made _accessible_, without also making them _extensible_.
+Parent classes in the hierarchy can be made <em>accessible</em>, without also making them <em>extensible</em>.
This allows hierarchies to be created with maximum reuse within but without having
-to defensively code for arbitrary extensions added at a later time.
-
-Such classes are useful in defining Algebraic Data Types (ADTs) and in scenarios where
+to defensively code for arbitrary extensions added at a later time.</p>
+</div>
+<div class="paragraph">
+<p>Such classes are useful in defining Algebraic Data Types (ADTs) and in scenarios where
we might want to reason about whether we have accounted for all possible types, e.g. the
-static compiler may wish to give a warning if a switch block doesn't exhaustively
-cover all possible types by respective case branches.
-
-==== Initial implementation
-
-* Provide a `@Sealed` marker annotation or AST transform which allows a list of
+static compiler may wish to give a warning if a switch block doesn’t exhaustively
+cover all possible types by respective case branches.</p>
+</div>
+<div class="sect3">
+<h4 id="_initial_implementation">Initial implementation</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Provide a <code>@Sealed</code> marker annotation or AST transform which allows a list of
permitted children to be defined. Use of this annotation will be an incubating
feature subject to change. Explicit use may eventually be discouraged and instead
-a keyword, e.g. `sealed` would be encouraged instead. However, the annotation
+a keyword, e.g. <code>sealed</code> would be encouraged instead. However, the annotation
could be retained to offer support for this feature on earlier JVMs or versions
-of Groovy prior to any grammar changes.
-
-* Prohibit extension of JDK17+ sealed classes or annotated `@Sealed` classes.
-This also applies for interfaces, anonymous inner classes and traits.
-
-* Provide checks in other places where such extension might occur implicitly, e.g.: with `@Delegate`,
-when using type coercion, etc.
-
-* Support `non-sealed` or `unsealed` sub-hierarchies. (See JEP-409)
-
-* Allow the permitted subclasses to be inferred automatically just for the case
-where the base and all permitted subclasses are in the same file. (See JEP-409)
-
-* Introduce the `sealed` modifier and `permits` clause in the grammar.
-
-* By default, when running on JDK17+, sealed class information is added into the bytecode.
-We refer to such classes as _native_ sealed classes.
-
-* By default, when running on earlier JDKs, an annotation is added to a class to indicate that
-a class is sealed. Such classes will be recognized by Groovy 4+ compilers but not by Java.
-
-* The `@SealedOptions` annotation has a `mode` annotation attribute which can override the default behavior.
-
-==== Potential extensions
-
-The following potential extensions are possibly all desirable but
-are non-goals for the first implementation:
-
-* Require that all classes within a sealed hierarchy be compiled at the same time.
-
-* Require that all classes within a sealed hierarchy belong to the same JPMS module.
-
-* Add warnings to the static compiler if a switch is used for a sealed hierarchy
-and not all types are exhaustively covered.
-
-== References and useful links
-
-* https://openjdk.org/jeps/360[JEP 360: Sealed Classes (Preview)]
-* https://openjdk.org/jeps/397[JEP 397: Sealed Classes (Second Preview)]
-* https://openjdk.org/jeps/409[JEP 409: Sealed Classes]
-* https://kotlinlang.org/docs/sealed-classes.html[Sealed Classes] in Kotlin
-* https://github.com/scala/improvement-proposals/pull/43[Sealed Types] in Scala (withdrawn)
-
-=== Reference implementation
-
-https://github.com/apache/groovy/pull/1606
-
-=== JIRA issues
-
-* https://issues.apache.org/jira/browse/GROOVY-10148[GROOVY-10148: Groovy should not allow classes to extend sealed Java classes]
-
-== Update history
-
-1 (2021-07-22) Initial draft +
-2 (2021-11-06) Update to align with 4.0.0-beta-2
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-13</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-13</h1><hr/></div></div></div></div><footer id='footer'>
+of Groovy prior to any grammar changes.</p>
+</li>
+<li>
+<p>Prohibit extension of JDK17+ sealed classes or annotated <code>@Sealed</code> classes.
+This also applies for interfaces, anonymous inner classes and traits.</p>
+</li>
+<li>
+<p>Provide checks in other places where such extension might occur implicitly, e.g.: with <code>@Delegate</code>,
+when using type coercion, etc.</p>
+</li>
+<li>
+<p>Support <code>non-sealed</code> or <code>unsealed</code> sub-hierarchies. (See JEP-409)</p>
+</li>
+<li>
+<p>Allow the permitted subclasses to be inferred automatically just for the case
+where the base and all permitted subclasses are in the same file. (See JEP-409)</p>
+</li>
+<li>
+<p>Introduce the <code>sealed</code> modifier and <code>permits</code> clause in the grammar.</p>
+</li>
+<li>
+<p>By default, when running on JDK17+, sealed class information is added into the bytecode.
+We refer to such classes as <em>native</em> sealed classes.</p>
+</li>
+<li>
+<p>By default, when running on earlier JDKs, an annotation is added to a class to indicate that
+a class is sealed. Such classes will be recognized by Groovy 4+ compilers but not by Java.</p>
+</li>
+<li>
+<p>The <code>@SealedOptions</code> annotation has a <code>mode</code> annotation attribute which can override the default behavior.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_potential_extensions">Potential extensions</h4>
+<div class="paragraph">
+<p>The following potential extensions are possibly all desirable but
+are non-goals for the first implementation:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Require that all classes within a sealed hierarchy be compiled at the same time.</p>
+</li>
+<li>
+<p>Require that all classes within a sealed hierarchy belong to the same JPMS module.</p>
+</li>
+<li>
+<p>Add warnings to the static compiler if a switch is used for a sealed hierarchy
+and not all types are exhaustively covered.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://openjdk.org/jeps/360">JEP 360: Sealed Classes (Preview)</a></p>
+</li>
+<li>
+<p><a href="https://openjdk.org/jeps/397">JEP 397: Sealed Classes (Second Preview)</a></p>
+</li>
+<li>
+<p><a href="https://openjdk.org/jeps/409">JEP 409: Sealed Classes</a></p>
+</li>
+<li>
+<p><a href="https://kotlinlang.org/docs/sealed-classes.html">Sealed Classes</a> in Kotlin</p>
+</li>
+<li>
+<p><a href="https://github.com/scala/improvement-proposals/pull/43">Sealed Types</a> in Scala (withdrawn)</p>
+</li>
+</ul>
+</div>
+<div class="sect2">
+<h3 id="_reference_implementation">Reference implementation</h3>
+<div class="paragraph">
+<p><a href="https://github.com/apache/groovy/pull/1606" class="bare">https://github.com/apache/groovy/pull/1606</a></p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_jira_issues">JIRA issues</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-10148">GROOVY-10148: Groovy should not allow classes to extend sealed Java classes</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>1 (2021-07-22) Initial draft<br>
+2 (2021-11-06) Update to align with 4.0.0-beta-2</p>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-14.html b/wiki/GEP-14.html
index f103ec8..d3f1257 100644
--- a/wiki/GEP-14.html
+++ b/wiki/GEP-14.html
@@ -59,131 +59,293 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-14: Record classes
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-14
-*Title*:: Record classes
-*Version*:: 1
-*Type*:: Feature
-*Status*:: Draft
-*Leader*:: Paul King
-*Created*:: 2021-10-26
-*Last modification* :: 2021-10-26
-****
-
-== Abstract
-
-Record classes, or _records_ for short, are a special kind of class
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-14</a></li><li><a href='#_abstract' class='anchor-link'>Abstract</a></li><li><a href='#_references_and_useful_links' class='anchor-link'>References and useful links</a></li><li><a href='#_update_history' class='anchor-link'>Update history</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='do [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-14</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>Record classes</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>1</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Draft</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Paul King</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2021-10-26</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2021-10-26</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract">Abstract</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Record classes, or <em>records</em> for short, are a special kind of class
useful for modelling plain data aggregates.
They provide a compact syntax with less ceremony than normal classes.
-Groovy already has AST transforms such as `@Immutable` and `@Canonical`
+Groovy already has AST transforms such as <code>@Immutable</code> and <code>@Canonical</code>
which already dramatically reduce ceremony but records have been
introduced in Java and record classes in Groovy are designed to align
-with Java record classes.
-
-=== Motivation
-
-For motivation of the general concept for records,
+with Java record classes.</p>
+</div>
+<div class="sect2">
+<h3 id="_motivation">Motivation</h3>
+<div class="paragraph">
+<p>For motivation of the general concept for records,
see the References and useful links section below.
The overall summary is that very succinct classes can be written
-for the special case of plain data aggregates, e.g.:
-
-[source,groovy]
-----
-record Point3D(int x, int y, int z) { }
-----
-or:
-
-[source,groovy]
-----
-record Person(String firstName, String lastName) { }
-----
-
-Such classes have automatic `toString`, `hashCode` and `equals` methods
+for the special case of plain data aggregates, e.g.:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code data-lang="groovy">record Point3D(int x, int y, int z) { }</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>or:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code data-lang="groovy">record Person(String firstName, String lastName) { }</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Such classes have automatic <code>toString</code>, <code>hashCode</code> and <code>equals</code> methods
and an automatic tuple constructor. All of these factor into account the
-properties (known as record components) of the class.
-
-=== Requirements
-
-The main requirement is to provide equivalent functionality to Java record classes when compiling on suitable JDK versions (16+).
-By _equivalent functionality_, the following aspects are relevant:
-
-* Support reduced ceremony when writing records.
-* Store appropriate information at the bytecode level so that Groovy records are recognised by Java.
-We refer to classes with such bytecode information as _native_ records.
-* Maintain Java syntax compatibility where possible including the compact constructor syntax.
-
-==== Non-goals
-
-* Provide native record support on versions of the JDK which supported records in preview mode
-
-=== Design considerations
-
-* Numerous Groovy AST transforms already provide functionality that overlaps with some features of Java records, e.g. `@ToString`
-helps reduce ceremony by offering a declarative mechanism to achieve an _automatic_ `toString` method.
-Where it makes sense, Groovy's record implementation should leverage such existing functionality.
-* Even though existing Groovy AST transforms can be pieced together to achieve mimic record functionality,
+properties (known as record components) of the class.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_requirements">Requirements</h3>
+<div class="paragraph">
+<p>The main requirement is to provide equivalent functionality to Java record classes when compiling on suitable JDK versions (16+).
+By <em>equivalent functionality</em>, the following aspects are relevant:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Support reduced ceremony when writing records.</p>
+</li>
+<li>
+<p>Store appropriate information at the bytecode level so that Groovy records are recognised by Java.
+We refer to classes with such bytecode information as <em>native</em> records.</p>
+</li>
+<li>
+<p>Maintain Java syntax compatibility where possible including the compact constructor syntax.</p>
+</li>
+</ul>
+</div>
+<div class="sect3">
+<h4 id="_non_goals">Non-goals</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Provide native record support on versions of the JDK which supported records in preview mode</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_design_considerations">Design considerations</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>Numerous Groovy AST transforms already provide functionality that overlaps with some features of Java records, e.g. <code>@ToString</code>
+helps reduce ceremony by offering a declarative mechanism to achieve an <em>automatic</em> <code>toString</code> method.
+Where it makes sense, Groovy’s record implementation should leverage such existing functionality.</p>
+</li>
+<li>
+<p>Even though existing Groovy AST transforms can be pieced together to achieve mimic record functionality,
it sees worth providing a pre-canned packaging of those pieces to mirror record functionality in a concise way.
-Records should not introduce any additional impedance for Java developers learning or using Groovy.
-* Groovy's existing AST transforms offer additional customization options and additional boilerplate reduction options.
-These should be available with Groovy records (when it makes sense).
-* Given that Groovy's existing AST transforms work for JDK versions prior to JDK16, Groovy's record functionality can
-allow the creation of _record-like_ classes. Unlike _native_ records, these won't have record information at the
+Records should not introduce any additional impedance for Java developers learning or using Groovy.</p>
+</li>
+<li>
+<p>Groovy’s existing AST transforms offer additional customization options and additional boilerplate reduction options.
+These should be available with Groovy records (when it makes sense).</p>
+</li>
+<li>
+<p>Given that Groovy’s existing AST transforms work for JDK versions prior to JDK16, Groovy’s record functionality can
+allow the creation of <em>record-like</em> classes. Unlike <em>native</em> records, these won’t have record information at the
bytecode level but will otherwise follow the same conventions as native records. Such classes will store record
-information using annotations. They will be recognised by the Groovy compiler but not a Java compiler.
-* Given that records are primarily designed to be data aggregates, Groovy records are `@CompileStatic` by default.
-
-=== Groovy special features
-
-* Support Groovy's named-parameter syntax
-* Support Groovy's `getAt` method for positional access of components
-* Support Groovy's default parameter concept
-* Support additional helper methods found in other languages, e.g. Kotlin data classes and Scala case classes. Candidates include `copyWith`, `size`, `toMap`, `toList`.
-* Support destructuring of records
-
-==== Initial implementation
-
-* Provide a `@RecordType` annotation collector which collects
-existing AST transforms suitable for providing the desired functionality.
-* Provide a `@RecordBase` AST transform which encapsulates any special
-treatment not found in existing transforms.
-* Provide a `@RecordOptions` annotation which allows the constructed
-record implementation to be customised.
-* Provide support for the `record` keyword in the grammar which can be used
-instead of the `@RecordType` annotation.
-
-== References and useful links
-
-* https://openjdk.org/jeps/395[JEP 395: Records]
-* https://openjdk.org/jeps/384[JEP 384: Records (Second Preview)]
-* https://openjdk.org/jeps/359[JEP 359: Records (Preview)]
-* https://docs.oracle.com/en/java/javase/16/language/records.html[Record Classes] Java documentation
-* https://kotlinlang.org/docs/data-classes.html[Kotlin data classes]
-* https://docs.scala-lang.org/tour/case-classes.html[Scala case classes]
-
-=== Reference implementation
-
-https://github.com/apache/groovy/pull/1375
-https://github.com/apache/groovy/pull/1633
-https://github.com/apache/groovy/pull/1645
-
-=== JIRA issues
-
-* https://issues.apache.org/jira/browse/GROOVY-9754[GROOVY-9754: Provide a record-like equivalent]
-* https://issues.apache.org/jira/browse/GROOVY-10240[GROOVY-10240: Support record grammar]
-* https://issues.apache.org/jira/browse/GROOVY-10298[GROOVY-10298: Refine records to not use system properties]
-* https://issues.apache.org/jira/browse/GROOVY-10338[GROOVY-10338: Enhance records with additional helper methods]
-
-== Update history
-
-1 (2021-10-26) Initial draft
-2 (2021-11-06) Update to align with 4.0.0-beta-2
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-14</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-14</h1><hr/></div></div></div></div><footer id='footer'>
+information using annotations. They will be recognised by the Groovy compiler but not a Java compiler.</p>
+</li>
+<li>
+<p>Given that records are primarily designed to be data aggregates, Groovy records are <code>@CompileStatic</code> by default.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_groovy_special_features">Groovy special features</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>Support Groovy’s named-parameter syntax</p>
+</li>
+<li>
+<p>Support Groovy’s <code>getAt</code> method for positional access of components</p>
+</li>
+<li>
+<p>Support Groovy’s default parameter concept</p>
+</li>
+<li>
+<p>Support additional helper methods found in other languages, e.g. Kotlin data classes and Scala case classes. Candidates include <code>copyWith</code>, <code>size</code>, <code>toMap</code>, <code>toList</code>.</p>
+</li>
+<li>
+<p>Support destructuring of records</p>
+</li>
+</ul>
+</div>
+<div class="sect3">
+<h4 id="_initial_implementation">Initial implementation</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Provide a <code>@RecordType</code> annotation collector which collects
+existing AST transforms suitable for providing the desired functionality.</p>
+</li>
+<li>
+<p>Provide a <code>@RecordBase</code> AST transform which encapsulates any special
+treatment not found in existing transforms.</p>
+</li>
+<li>
+<p>Provide a <code>@RecordOptions</code> annotation which allows the constructed
+record implementation to be customised.</p>
+</li>
+<li>
+<p>Provide support for the <code>record</code> keyword in the grammar which can be used
+instead of the <code>@RecordType</code> annotation.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://openjdk.org/jeps/395">JEP 395: Records</a></p>
+</li>
+<li>
+<p><a href="https://openjdk.org/jeps/384">JEP 384: Records (Second Preview)</a></p>
+</li>
+<li>
+<p><a href="https://openjdk.org/jeps/359">JEP 359: Records (Preview)</a></p>
+</li>
+<li>
+<p><a href="https://docs.oracle.com/en/java/javase/16/language/records.html">Record Classes</a> Java documentation</p>
+</li>
+<li>
+<p><a href="https://kotlinlang.org/docs/data-classes.html">Kotlin data classes</a></p>
+</li>
+<li>
+<p><a href="https://docs.scala-lang.org/tour/case-classes.html">Scala case classes</a></p>
+</li>
+</ul>
+</div>
+<div class="sect2">
+<h3 id="_reference_implementation">Reference implementation</h3>
+<div class="paragraph">
+<p><a href="https://github.com/apache/groovy/pull/1375" class="bare">https://github.com/apache/groovy/pull/1375</a>
+<a href="https://github.com/apache/groovy/pull/1633" class="bare">https://github.com/apache/groovy/pull/1633</a>
+<a href="https://github.com/apache/groovy/pull/1645" class="bare">https://github.com/apache/groovy/pull/1645</a></p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_jira_issues">JIRA issues</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-9754">GROOVY-9754: Provide a record-like equivalent</a></p>
+</li>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-10240">GROOVY-10240: Support record grammar</a></p>
+</li>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-10298">GROOVY-10298: Refine records to not use system properties</a></p>
+</li>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-10338">GROOVY-10338: Enhance records with additional helper methods</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>1 (2021-10-26) Initial draft
+2 (2021-11-06) Update to align with 4.0.0-beta-2</p>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-15.html b/wiki/GEP-15.html
index dfac643..2c9fc70 100644
--- a/wiki/GEP-15.html
+++ b/wiki/GEP-15.html
@@ -59,130 +59,310 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-15: Compound assignment operator overloading
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-15
-*Title*:: Compound assignment operator overloading
-*Version*:: 1
-*Type*:: Feature
-*Status*:: Draft
-*Leader*:: Paul King
-*Created*:: 2026-04-12
-*Last modification* :: 2026-04-12
-****
-
-== Abstract
-
-Groovy supports operator overloading: `\+` maps to `plus()`, `-` maps to `minus()`,
-`<<` maps to `leftShift()`, and so on. However, compound assignment operators
-(`pass:[+=]`, `-=`, `pass:[<<=]`, etc.) are always desugared to `x = x.op(y)` -- there is
-no way to override `+=` independently of `pass:[+]`. This GEP proposes adding
-support for dedicated compound assignment methods such as `plusAssign`,
-`minusAssign`, `leftShiftAssign`, etc.
-
-=== Motivation
-
-The current desugaring of `x += y` to `x = x.plus(y)` creates a new object
-and reassigns the variable. This has several drawbacks:
-
-* **Mutable data structures** are forced into a create-and-reassign pattern
- when in-place mutation is the intended semantics. For example, a mutable
- list's `+=` creates a new list rather than appending in place.
-* **Final fields and variables** cannot use compound assignment at all,
- even when the underlying object is mutable and supports in-place mutation.
-* **Intent** is unclear: the class author cannot distinguish between
- `x + y` (produce a new value) and `x += y` (mutate in place).
-
-Languages like Kotlin and Scala already support this distinction.
-Kotlin maps `\+=` to `plusAssign()` when available, falling back to
-`plus()` with reassignment. Scala allows mutable collections to define
-`+=` directly.
-
-=== Requirements
-
-* Support dedicated compound assignment methods (`plusAssign`, `minusAssign`, etc.)
- that are called in preference to the current `plus` + reassign pattern.
-* Maintain full backward compatibility: existing code that uses `+=` with
- `plus()` must continue to work identically when no `plusAssign` method exists.
-* Support `+=` on `final` fields/variables when `plusAssign` is available.
-* Work correctly in both `@CompileStatic` and dynamic Groovy.
-
-==== Non-goals
-
-* Changing the behavior of `++` and `--` operators (these use `next()`/`previous()`
- and are conceptually different).
-* Changing subscript compound assignment (`a[i] += b`), which uses the existing
- `getAt`/`putAt` pattern. A future GEP might explore a two-argument
- `plusAssign(key, value)` convention where `a[key] += b` maps to
- `a.plusAssign(key, b)`, allowing containers to handle compound updates
- atomically. Multi-dimensional cases like `a[i][j] += b` would resolve
- naturally by peeling subscripts from the left: evaluate `a.getAt(i)` to
- get the inner container, then apply the single-dimension rule to that result.
-
-=== Operator method name mapping
-
-[cols="1,2,2",options="header"]
-|===
-| Operator | Assign method | Fallback method
-
-| `+=` | `plusAssign` | `plus`
-| `-=` | `minusAssign` | `minus`
-| `*=` | `multiplyAssign` | `multiply`
-| `/=` | `divAssign` | `div`
-| `%=` | `remainderAssign` | `remainder`
-| `**=` | `powerAssign` | `power`
-| `<\<=` | `leftShiftAssign` | `leftShift`
-| `>>=` | `rightShiftAssign` | `rightShift`
-| `>>>=` | `rightShiftUnsignedAssign` | `rightShiftUnsigned`
-| `&=` | `andAssign` | `and`
-| `\|=` | `orAssign` | `or`
-| `^=` | `xorAssign` | `xor`
-|===
-
-=== Resolution algorithm
-
-When the compiler encounters `x += y`:
-
-1. Look for a method `plusAssign(y)` on the type of `x`.
-2. If found, call `x.plusAssign(y)` directly. No reassignment occurs.
- This works even when `x` is `final`.
-3. If not found, fall back to the current behavior: `x = x.plus(y)`.
- This requires `x` to be reassignable.
-4. If `x` is `final` and no `plusAssign` exists, report a compile error
- (in `@CompileStatic` mode).
-
-When both `plusAssign` and `plus` exist on the same type, `plusAssign`
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-15</a></li><li><a href='#_abstract' class='anchor-link'>Abstract</a></li><li><a href='#_references_and_useful_links' class='anchor-link'>References and useful links</a></li><li><a href='#_update_history' class='anchor-link'>Update history</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='do [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-15</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>Compound assignment operator overloading</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>1</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Draft</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Paul King</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2026-04-12</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2026-04-12</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract">Abstract</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Groovy supports operator overloading: <code>+</code> maps to <code>plus()</code>, <code>-</code> maps to <code>minus()</code>,
+<code><<</code> maps to <code>leftShift()</code>, and so on. However, compound assignment operators
+(<code>+=</code>, <code>-=</code>, <code><<=</code>, etc.) are always desugared to <code>x = x.op(y)</code> — there is
+no way to override <code>+=</code> independently of <code>+</code>. This GEP proposes adding
+support for dedicated compound assignment methods such as <code>plusAssign</code>,
+<code>minusAssign</code>, <code>leftShiftAssign</code>, etc.</p>
+</div>
+<div class="sect2">
+<h3 id="_motivation">Motivation</h3>
+<div class="paragraph">
+<p>The current desugaring of <code>x += y</code> to <code>x = x.plus(y)</code> creates a new object
+and reassigns the variable. This has several drawbacks:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><strong>Mutable data structures</strong> are forced into a create-and-reassign pattern
+when in-place mutation is the intended semantics. For example, a mutable
+list’s <code>+=</code> creates a new list rather than appending in place.</p>
+</li>
+<li>
+<p><strong>Final fields and variables</strong> cannot use compound assignment at all,
+even when the underlying object is mutable and supports in-place mutation.</p>
+</li>
+<li>
+<p><strong>Intent</strong> is unclear: the class author cannot distinguish between
+<code>x + y</code> (produce a new value) and <code>x += y</code> (mutate in place).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Languages like Kotlin and Scala already support this distinction.
+Kotlin maps <code>+=</code> to <code>plusAssign()</code> when available, falling back to
+<code>plus()</code> with reassignment. Scala allows mutable collections to define
+<code>+=</code> directly.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_requirements">Requirements</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>Support dedicated compound assignment methods (<code>plusAssign</code>, <code>minusAssign</code>, etc.)
+that are called in preference to the current <code>plus</code> + reassign pattern.</p>
+</li>
+<li>
+<p>Maintain full backward compatibility: existing code that uses <code>+=</code> with
+<code>plus()</code> must continue to work identically when no <code>plusAssign</code> method exists.</p>
+</li>
+<li>
+<p>Support <code>+=</code> on <code>final</code> fields/variables when <code>plusAssign</code> is available.</p>
+</li>
+<li>
+<p>Work correctly in both <code>@CompileStatic</code> and dynamic Groovy.</p>
+</li>
+</ul>
+</div>
+<div class="sect3">
+<h4 id="_non_goals">Non-goals</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Changing the behavior of <code>++</code> and <code>--</code> operators (these use <code>next()</code>/<code>previous()</code>
+and are conceptually different).</p>
+</li>
+<li>
+<p>Changing subscript compound assignment (<code>a[i] += b</code>), which uses the existing
+<code>getAt</code>/<code>putAt</code> pattern. A future GEP might explore a two-argument
+<code>plusAssign(key, value)</code> convention where <code>a[key] += b</code> maps to
+<code>a.plusAssign(key, b)</code>, allowing containers to handle compound updates
+atomically. Multi-dimensional cases like <code>a[i][j] += b</code> would resolve
+naturally by peeling subscripts from the left: evaluate <code>a.getAt(i)</code> to
+get the inner container, then apply the single-dimension rule to that result.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_operator_method_name_mapping">Operator method name mapping</h3>
+<table class="tableblock frame-all grid-all stretch">
+<colgroup>
+<col style="width: 20%;">
+<col style="width: 40%;">
+<col style="width: 40%;">
+</colgroup>
+<thead>
+<tr>
+<th class="tableblock halign-left valign-top">Operator</th>
+<th class="tableblock halign-left valign-top">Assign method</th>
+<th class="tableblock halign-left valign-top">Fallback method</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>+=</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>plusAssign</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>plus</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>-=</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>minusAssign</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>minus</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>*=</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>multiplyAssign</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>multiply</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>/=</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>divAssign</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>div</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>%=</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>remainderAssign</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>remainder</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>**=</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>powerAssign</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>power</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code><<=</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>leftShiftAssign</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>leftShift</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>>>=</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>rightShiftAssign</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>rightShift</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>>>>=</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>rightShiftUnsignedAssign</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>rightShiftUnsigned</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>&=</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>andAssign</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>and</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>|=</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>orAssign</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>or</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>^=</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>xorAssign</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>xor</code></p></td>
+</tr>
+</tbody>
+</table>
+</div>
+<div class="sect2">
+<h3 id="_resolution_algorithm">Resolution algorithm</h3>
+<div class="paragraph">
+<p>When the compiler encounters <code>x += y</code>:</p>
+</div>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p>Look for a method <code>plusAssign(y)</code> on the type of <code>x</code>.</p>
+</li>
+<li>
+<p>If found, call <code>x.plusAssign(y)</code> directly. No reassignment occurs.
+This works even when <code>x</code> is <code>final</code>.</p>
+</li>
+<li>
+<p>If not found, fall back to the current behavior: <code>x = x.plus(y)</code>.
+This requires <code>x</code> to be reassignable.</p>
+</li>
+<li>
+<p>If <code>x</code> is <code>final</code> and no <code>plusAssign</code> exists, report a compile error
+(in <code>@CompileStatic</code> mode).</p>
+</li>
+</ol>
+</div>
+<div class="paragraph">
+<p>When both <code>plusAssign</code> and <code>plus</code> exist on the same type, <code>plusAssign</code>
takes precedence. This is the pragmatic choice for Groovy since it lacks
-Kotlin's `val`/`var` distinction. If a class author defined `plusAssign`,
-they intended it to be used for `+=`.
-
-=== Design considerations
-
-* **Primitives are unaffected.** `int x = 0; x += 1` continues to use
- the existing fast-path for primitive arithmetic. The `plusAssign` lookup
- only applies when the base operator would resolve to a method call.
-* **Expression value.** When `plusAssign` is called, the expression value
- of `x += y` is `x` (the mutated object), not the return value of
- `plusAssign`. This differs from the current behavior where the expression
- value is the result of `x.plus(y)`.
-* **Extension methods.** `plusAssign` is discoverable as an extension method
- (DGM or category), not just as an instance method.
-* **`@OperatorRename` support.** The existing `@OperatorRename` annotation
- will be extended to support renaming the assign variants, e.g.
- `@OperatorRename(plusAssign="addInPlace")`.
-
-=== Examples
-
-A mutable accumulator:
-
-[source,groovy]
-----
-class Accumulator {
+Kotlin’s <code>val</code>/<code>var</code> distinction. If a class author defined <code>plusAssign</code>,
+they intended it to be used for <code>+=</code>.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_design_considerations">Design considerations</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><strong>Primitives are unaffected.</strong> <code>int x = 0; x += 1</code> continues to use
+the existing fast-path for primitive arithmetic. The <code>plusAssign</code> lookup
+only applies when the base operator would resolve to a method call.</p>
+</li>
+<li>
+<p><strong>Expression value.</strong> When <code>plusAssign</code> is called, the expression value
+of <code>x += y</code> is <code>x</code> (the mutated object), not the return value of
+<code>plusAssign</code>. This differs from the current behavior where the expression
+value is the result of <code>x.plus(y)</code>.</p>
+</li>
+<li>
+<p><strong>Extension methods.</strong> <code>plusAssign</code> is discoverable as an extension method
+(DGM or category), not just as an instance method.</p>
+</li>
+<li>
+<p><strong><code>@OperatorRename</code> support.</strong> The existing <code>@OperatorRename</code> annotation
+will be extended to support renaming the assign variants, e.g.
+<code>@OperatorRename(plusAssign="addInPlace")</code>.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_examples">Examples</h3>
+<div class="paragraph">
+<p>A mutable accumulator:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code data-lang="groovy">class Accumulator {
int total = 0
void plusAssign(int n) { total += n }
Accumulator plus(int n) { new Accumulator(total: total + n) }
@@ -194,70 +374,108 @@ assert acc.total == 5
def acc2 = acc + 3 // calls acc.plus(3), returns new Accumulator
assert acc2.total == 8
-assert acc.total == 5
-----
-
-A final field with in-place mutation:
-
-[source,groovy]
-----
-@CompileStatic
+assert acc.total == 5</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>A final field with in-place mutation:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code data-lang="groovy">@CompileStatic
class EventBus {
- final List<String> listeners = []
+ final List<String> listeners = []
// List has leftShiftAssign via extension method or subclass
}
def bus = new EventBus()
-bus.listeners <<= "listener1" // calls listeners.leftShiftAssign("listener1")
-----
-
-=== Static compilation (`@CompileStatic`)
-
-In `@CompileStatic` mode, the type checker resolves `plusAssign` at
-compile time using `findMethod()`. If found, it records the target method
+bus.listeners <<= "listener1" // calls listeners.leftShiftAssign("listener1")</code></pre>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_static_compilation_compilestatic">Static compilation (<code>@CompileStatic</code>)</h3>
+<div class="paragraph">
+<p>In <code>@CompileStatic</code> mode, the type checker resolves <code>plusAssign</code> at
+compile time using <code>findMethod()</code>. If found, it records the target method
on the expression via node metadata and the bytecode generator emits a
-direct method call -- no dup, no store-back.
-
-If not found, the existing desugaring to `x = x.plus(y)` applies.
-
-=== Dynamic Groovy
-
-In dynamic Groovy, the runtime checks for `plusAssign` via the Meta-Object
-Protocol (MOP). If `respondsTo(target, "plusAssign", arg)` succeeds, it is
-called. Otherwise, the fallback to `plus` + reassignment applies.
-
-This requires a new runtime helper method (e.g., in `ScriptBytecodeAdapter`)
-that encapsulates the try-assign-then-fallback logic.
-
-=== Breaking behavior
-
-1. **Existing `plusAssign` methods.** If a class already defines a method
- literally named `plusAssign`, `+=` will now call it instead of desugaring
- to `plus` + reassign. This is unlikely in practice but must be documented
- in release notes.
-2. **Expression value change.** `val = (x += y)` -- with `plusAssign`, the
- captured value is `x` (the mutated object), not the result of `plus`.
- This only affects code that uses compound assignment as an expression.
-3. **Final fields.** In `@CompileStatic`, `final` fields with a type that
- has `plusAssign` can now use `+=`. Previously this was always an error.
-
-== References and useful links
-
-* https://kotlinlang.org/docs/operator-overloading.html#augmented-assignments[Kotlin augmented assignments]
-* https://docs.scala-lang.org/overviews/collections-2.13/overview.html[Scala mutable collection operators]
-
-=== Reference implementation
-
-_TBD_
-
-=== JIRA issues
-
-_TBD_
-
-== Update history
-
-1 (2026-04-12) Initial draft
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-15</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-15</h1><hr/></div></div></div></div><footer id='footer'>
+direct method call — no dup, no store-back.</p>
+</div>
+<div class="paragraph">
+<p>If not found, the existing desugaring to <code>x = x.plus(y)</code> applies.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_dynamic_groovy">Dynamic Groovy</h3>
+<div class="paragraph">
+<p>In dynamic Groovy, the runtime checks for <code>plusAssign</code> via the Meta-Object
+Protocol (MOP). If <code>respondsTo(target, "plusAssign", arg)</code> succeeds, it is
+called. Otherwise, the fallback to <code>plus</code> + reassignment applies.</p>
+</div>
+<div class="paragraph">
+<p>This requires a new runtime helper method (e.g., in <code>ScriptBytecodeAdapter</code>)
+that encapsulates the try-assign-then-fallback logic.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_breaking_behavior">Breaking behavior</h3>
+<div class="olist arabic">
+<ol class="arabic">
+<li>
+<p><strong>Existing <code>plusAssign</code> methods.</strong> If a class already defines a method
+literally named <code>plusAssign</code>, <code>+=</code> will now call it instead of desugaring
+to <code>plus</code> + reassign. This is unlikely in practice but must be documented
+in release notes.</p>
+</li>
+<li>
+<p><strong>Expression value change.</strong> <code>val = (x += y)</code> — with <code>plusAssign</code>, the
+captured value is <code>x</code> (the mutated object), not the result of <code>plus</code>.
+This only affects code that uses compound assignment as an expression.</p>
+</li>
+<li>
+<p><strong>Final fields.</strong> In <code>@CompileStatic</code>, <code>final</code> fields with a type that
+has <code>plusAssign</code> can now use <code>+=</code>. Previously this was always an error.</p>
+</li>
+</ol>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://kotlinlang.org/docs/operator-overloading.html#augmented-assignments">Kotlin augmented assignments</a></p>
+</li>
+<li>
+<p><a href="https://docs.scala-lang.org/overviews/collections-2.13/overview.html">Scala mutable collection operators</a></p>
+</li>
+</ul>
+</div>
+<div class="sect2">
+<h3 id="_reference_implementation">Reference implementation</h3>
+<div class="paragraph">
+<p><em>TBD</em></p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_jira_issues">JIRA issues</h3>
+<div class="paragraph">
+<p><em>TBD</em></p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>1 (2026-04-12) Initial draft</p>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-2.html b/wiki/GEP-2.html
index 9522bda..b15ea0d 100644
--- a/wiki/GEP-2.html
+++ b/wiki/GEP-2.html
@@ -59,146 +59,286 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-2: AST Builder Support
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-2
-*Title*:: AST Builder Support
-*Version*:: 8
-*Type*:: Feature
-*Target*:: Groovy 1.7
-*Status*:: Final
-*Comment*:: Included in Groovy but somewhat _superseded by macros_
-*Leader*:: Hamlet D'Arcy
-*Created*:: 2009-04-01
-*Last modification* :: 2018-10-12
-****
-
-== Abstract
-
-Groovy 1.6 introduced the ability to perform local and global AST (Abstract Syntax Tree) transformations,
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-2</a></li><li><a href='#_abstract' class='anchor-link'>Abstract</a></li><li><a href='#_approach' class='anchor-link'>Approach</a></li><li><a href='#_references_and_useful_links' class='anchor-link'>References and useful links</a></li><li><a href='#_update_history' class='anchor-link'>Update history</a></ [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-2</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>AST Builder Support</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>8</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Target</strong>
+</td>
+<td class="hdlist2">
+<p>Groovy 1.7</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Final</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Comment</strong>
+</td>
+<td class="hdlist2">
+<p>Included in Groovy but somewhat <em>superseded by macros</em></p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Hamlet D’Arcy</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2009-04-01</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2018-10-12</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract">Abstract</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Groovy 1.6 introduced the ability to perform local and global AST (Abstract Syntax Tree) transformations,
allowing users to read and modify the AST of Groovy code as it is being compiled.
Reading information in the AST is relatively easy in Groovy.
The core library provides a strongly-typed visitor called GroovyCodeVisitor.
Nodes can be read and modified using the API provided through the subtypes of ASTNode.
Writing new AST nodes is not as simple. The AST generated from source is not always obvious,
and using constructor calls to generate trees of nodes can be verbose.
-This GEP proposes an ASTBuilder object that allows users to easily create AST.
-
-The ASTBuilder object allows AST to be created from:
-
-* strings containing Groovy source code
-* a closure containing Groovy source
-* a closure containing an AST creation DSL
-
-All three approaches share the same API: a builder object is instantiated and a build* method is invoked.
-
-== Approach
-
-=== ASTNode from String
-
-The simplest approach to implement is to provide an AST Builder with an API that takes a String and returns List<ASTNode>:
-
-```
-def builder = new AstBuilder()
-List<ASTNode> statements = builder.buildFromString(
+This GEP proposes an ASTBuilder object that allows users to easily create AST.</p>
+</div>
+<div class="paragraph">
+<p>The ASTBuilder object allows AST to be created from:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>strings containing Groovy source code</p>
+</li>
+<li>
+<p>a closure containing Groovy source</p>
+</li>
+<li>
+<p>a closure containing an AST creation DSL</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>All three approaches share the same API: a builder object is instantiated and a build* method is invoked.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_approach">Approach</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_astnode_from_string">ASTNode from String</h3>
+<div class="paragraph">
+<p>The simplest approach to implement is to provide an AST Builder with an API that takes a String and returns List<ASTNode>:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>def builder = new AstBuilder()
+List<ASTNode> statements = builder.buildFromString(
CompilePhase.CONVERSION,
true,
""" println "Hello World" """
-)
-```
-
-* phase parameter tells the builder from which phase to return AST. This parameter is optional, and the default
+)</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>phase parameter tells the builder from which phase to return AST. This parameter is optional, and the default
CompilePhase is CLASS_GENERATION. This provides a cleaner API for the common case, and CLASS_GENERATION was chosen
-because more types are available in later phases.
-* the "statementsOnly" boolean parameter is an optional parameter, and tells the builder to discard the generated
-top level Script ClassNode. Default is true.
-* The last String parameter is the input
-* The builder returns List<ASTNode>
-
-The above example produces the following AST:
-
-```
-BlockStatement
--> ExpressionStatement
- -> MethodCallExpression
- -> VariableExpression
- -> ConstantExpression
- -> ArgumentListExpression
- -> ConstantExpression
-```
-==== Alternatives
-
-* Some sort of AST Template was considered for this feature. Consider the following example:
-
-```
-def astTemplate = builder.buildAst ( "println $txt" ).head()
+because more types are available in later phases.</p>
+</li>
+<li>
+<p>the "statementsOnly" boolean parameter is an optional parameter, and tells the builder to discard the generated
+top level Script ClassNode. Default is true.</p>
+</li>
+<li>
+<p>The last String parameter is the input</p>
+</li>
+<li>
+<p>The builder returns List<ASTNode></p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>The above example produces the following AST:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>BlockStatement
+-> ExpressionStatement
+ -> MethodCallExpression
+ -> VariableExpression
+ -> ConstantExpression
+ -> ArgumentListExpression
+ -> ConstantExpression</code></pre>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_alternatives">Alternatives</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Some sort of AST Template was considered for this feature. Consider the following example:</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>def astTemplate = builder.buildAst ( "println $txt" ).head()
def constant = builder.buildAst ( "To be, or not to be: that is the question" ).head()
def methodCallExpression = astTemplate.apply(txt: constant)
-// method call expression not contains println "To be ... "
-```
-
-This templating approach adds complexity that may not be used. It overloads the GString $ operator,
+// method call expression not contains println "To be ... "</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This templating approach adds complexity that may not be used. It overloads the GString $ operator,
in that it is used here only with objects of type ASTNode but is used normally in GStrings with any Object type at all.
Also, the templating approach can create order of precedence confusion.
Consider source = "$expr * y", and later $expr is bound to "x+a". The result is "x + a * y", which was probably unintentional.
-At this time, the AST builder does not include such a feature.
-
-=== ASTNode from Code Block
-
-A useful API would be creating AST from code blocks.
-
-```
-AstBuilder builder = new AstBuilder()
+At this time, the AST builder does not include such a feature.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_astnode_from_code_block">ASTNode from Code Block</h3>
+<div class="paragraph">
+<p>A useful API would be creating AST from code blocks.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>AstBuilder builder = new AstBuilder()
def statementBlock = builder.buildFromCode (CompilePhase.CONVERSION, true) {
println "Hello World"
-}
-```
-
-* Expressing Groovy source within Groovy source seems the most natural way to write it (as opposed to putting Groovy source into a String).
-* Some IDE support is naturally available (highlighting, etc.), but IDE warnings will be misleading for variable scoping rules
-* Same issues and rules from "ASTNode from String" for phase and statementsOnly properties apply to this version
-* Provides similar API as builder from String, except the code property accepts any block of code that is legal in the context of a Closure.
-* Converting from a closure into AST is performed through a global compiler transformation.
-This requires the AstBuilder reference to be strongly typed so that the global annotation can be triggered.
-
-The above example produces the following AST:
-
-```
-BlockStatement
- -> ExpressionStatement
- -> MethodCallExpression
- -> VariableExpression
- -> ConstantExpression
- -> ArgumentListExpression
- -> ConstantExpression
-```
-
-==== Alternatives
-
-If @ASTSource annotation is used, then it would be very easy to let users reuse that annotation outside the builder.
-Consider the following example:
-
-
-```
-@AstSource(CompilePhase.CONVERSION)
-List<ASTNode> source = { println "compiled on: ${new Date()}" }
-```
-
-This option seems helpful; however, annotations on local variables are not yet supported. This approach will not be implemented.
-
-=== ASTNode from pseudo-specification
-
-Building AST conditionally, such as inserting an if-statement or looping, is not easily accomplished in the String or code based builders.
-Consider this example:
-
-```
-def builder = new AstBuilder()
-List<ASTNode> statements = builder.buildFromSpec {
+}</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Expressing Groovy source within Groovy source seems the most natural way to write it (as opposed to putting Groovy source into a String).</p>
+</li>
+<li>
+<p>Some IDE support is naturally available (highlighting, etc.), but IDE warnings will be misleading for variable scoping rules</p>
+</li>
+<li>
+<p>Same issues and rules from "ASTNode from String" for phase and statementsOnly properties apply to this version</p>
+</li>
+<li>
+<p>Provides similar API as builder from String, except the code property accepts any block of code that is legal in the context of a Closure.</p>
+</li>
+<li>
+<p>Converting from a closure into AST is performed through a global compiler transformation.
+This requires the AstBuilder reference to be strongly typed so that the global annotation can be triggered.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>The above example produces the following AST:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>BlockStatement
+ -> ExpressionStatement
+ -> MethodCallExpression
+ -> VariableExpression
+ -> ConstantExpression
+ -> ArgumentListExpression
+ -> ConstantExpression</code></pre>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_alternatives_2">Alternatives</h4>
+<div class="paragraph">
+<p>If @ASTSource annotation is used, then it would be very easy to let users reuse that annotation outside the builder.
+Consider the following example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>@AstSource(CompilePhase.CONVERSION)
+List<ASTNode> source = { println "compiled on: ${new Date()}" }</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This option seems helpful; however, annotations on local variables are not yet supported. This approach will not be implemented.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_astnode_from_pseudo_specification">ASTNode from pseudo-specification</h3>
+<div class="paragraph">
+<p>Building AST conditionally, such as inserting an if-statement or looping, is not easily accomplished in the String or code based builders.
+Consider this example:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>def builder = new AstBuilder()
+List<ASTNode> statements = builder.buildFromSpec {
methodCall {
variable "this"
constant "println"
@@ -208,73 +348,136 @@ List<ASTNode> statements = builder.buildFromSpec {
else constant "Ni hao"
}
}
-}
-```
-
-This library class is useful for several reasons:
-
-* Using conditionals or looping within an AST Builder will probably be a common occurrence
-* It is difficult to create a Field or Method references in any of the other approaches
-* Simply using the @Newify annotation does not sufficiently improve the syntax
-* This construct alleviates the need to distinguish between Statement and Expressions, since those words are dropped from the method names
-* There is no need for a phase or statementsOnly property in this approach
-* Many expressions take a type ClassNode, which wraps a Class. The syntax for ClassNode is to just pass
-a Class instance and the builder wraps it in a ClassNode automatically.
-
-==== Issues
-
-* Constructor parameter lists can be lengthy on ASTNode subtypes, and this approach removes the possibility for an IDE to help.
-This is the price to pay for a builder, and the planned builder metadata feature in 1.7 may alleviate this.
-* The class creating AST from the pseudo-specification should be implemented so that it does not create a
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>This library class is useful for several reasons:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Using conditionals or looping within an AST Builder will probably be a common occurrence</p>
+</li>
+<li>
+<p>It is difficult to create a Field or Method references in any of the other approaches</p>
+</li>
+<li>
+<p>Simply using the @Newify annotation does not sufficiently improve the syntax</p>
+</li>
+<li>
+<p>This construct alleviates the need to distinguish between Statement and Expressions, since those words are dropped from the method names</p>
+</li>
+<li>
+<p>There is no need for a phase or statementsOnly property in this approach</p>
+</li>
+<li>
+<p>Many expressions take a type ClassNode, which wraps a Class. The syntax for ClassNode is to just pass
+a Class instance and the builder wraps it in a ClassNode automatically.</p>
+</li>
+</ul>
+</div>
+<div class="sect3">
+<h4 id="_issues">Issues</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>Constructor parameter lists can be lengthy on ASTNode subtypes, and this approach removes the possibility for an IDE to help.
+This is the price to pay for a builder, and the planned builder metadata feature in 1.7 may alleviate this.</p>
+</li>
+<li>
+<p>The class creating AST from the pseudo-specification should be implemented so that it does not create a
mirror-image class hierarchy of the current AST types. This would force all changes to the AST types to be performed
in two places: once in the ASTNode subclass and once in this builder. If this is not possible, then at least the AST
-hierarchy doesn't change frequently.
-* Several ASTNode types have constructor signatures all of the same type: (Expression, Expression, Expression) most commonly.
-This means the parameters in the DSL are order dependent, and specifying arguments in the wrong order doesn't create
-an exception but causes drastically different results at runtime. This is fully documented on the mailing list.
-* The syntax for specifying Parameter objects is documented on the mailing list.
-* A few of the ASTNode types having naming conflicts with language keywords. For instance the ClassExpression type
-cannot be abbreviated to 'class' and IfStatement cannot be reduced to 'if'. This is fully documented on the mailing list.
-* Parameters have default values and can be varargs. A suitable syntax needs to be proposed.
-* Sometimes the order of the constructor parameters needed to be switched within the DSL. For instance,
-consider SwitchStatement(Expression expression, List<CaseStatement> caseStatements, Expression defaultStatement).
+hierarchy doesn’t change frequently.</p>
+</li>
+<li>
+<p>Several ASTNode types have constructor signatures all of the same type: (Expression, Expression, Expression) most commonly.
+This means the parameters in the DSL are order dependent, and specifying arguments in the wrong order doesn’t create
+an exception but causes drastically different results at runtime. This is fully documented on the mailing list.</p>
+</li>
+<li>
+<p>The syntax for specifying Parameter objects is documented on the mailing list.</p>
+</li>
+<li>
+<p>A few of the ASTNode types having naming conflicts with language keywords. For instance the ClassExpression type
+cannot be abbreviated to 'class' and IfStatement cannot be reduced to 'if'. This is fully documented on the mailing list.</p>
+</li>
+<li>
+<p>Parameters have default values and can be varargs. A suitable syntax needs to be proposed.</p>
+</li>
+<li>
+<p>Sometimes the order of the constructor parameters needed to be switched within the DSL. For instance,
+consider SwitchStatement(Expression expression, List<CaseStatement> caseStatements, Expression defaultStatement).
The current syntax of the DSL imposes a sort of VarArgs rigidity on the arguments: lists are just implied by repeated elements.
So having the middle parameter of SwitchStatement be a list is problematic because the natural way to convert the
-constructor is to have it become (Expression expression, CaseStatement... caseStatements, Expression default), which isn't possible.
-This is fully documented on the mailing list.
-
-==== Alternatives
-
-Template Haskell and Boo provide a special syntax for AST building statements.
-Quasi-quote (or Oxford quotes) can be used to trigger an AST building operation:
-
-```
-ConstantExpression exp = [| "Hello World" |]
-```
-
-Those languages also supply a splice operator $(...) to turn AST back into code. This is not part of the AstBuilder work.
-
-== References and useful links
-
-https://marc.info/?l=groovy-dev&m=123880759618095&w=2[groovy-dev: Groovy AST Builder discussion]
-
-https://marc.info/?l=groovy-dev&m=124187435114834&w=2[groovy-dev: Several issues with GEP-2 AST Builder "from specification"]
-
-https://en.wikipedia.org/wiki/Template_Haskell[Template Haskell]
-
-https://web.archive.org/web/20090213045341/http://blogs.codehaus.org:80/people/bamboo/archives/001593_boo_meta_methods.html[Boo meta methods]
-
-https://github.com/cython/cython/wiki/enhancements-metaprogramming[Cython Metaprogramming Proposal] by Martin C Martin - Contains nice write-up of some use cases
-
-=== JIRA issues:
-
-This feature is dependent on allowing annotations on local variables: https://issues.apache.org/jira/browse/GROOVY-3481[GROOVY-3481]
-
-== Update history
-
-7 (2009-06-17):: Version as extracted from Codehaus wiki
-8 (2018-10-11):: Added comment about macros
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-2</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-2</h1><hr/></div></div></div></div><footer id='footer'>
+constructor is to have it become (Expression expression, CaseStatement…​ caseStatements, Expression default), which isn’t possible.
+This is fully documented on the mailing list.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_alternatives_3">Alternatives</h4>
+<div class="paragraph">
+<p>Template Haskell and Boo provide a special syntax for AST building statements.
+Quasi-quote (or Oxford quotes) can be used to trigger an AST building operation:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>ConstantExpression exp = [| "Hello World" |]</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Those languages also supply a splice operator $(…​) to turn AST back into code. This is not part of the AstBuilder work.</p>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p><a href="https://marc.info/?l=groovy-dev&m=123880759618095&w=2">groovy-dev: Groovy AST Builder discussion</a></p>
+</div>
+<div class="paragraph">
+<p><a href="https://marc.info/?l=groovy-dev&m=124187435114834&w=2">groovy-dev: Several issues with GEP-2 AST Builder "from specification"</a></p>
+</div>
+<div class="paragraph">
+<p><a href="https://en.wikipedia.org/wiki/Template_Haskell">Template Haskell</a></p>
+</div>
+<div class="paragraph">
+<p><a href="https://web.archive.org/web/20090213045341/http://blogs.codehaus.org:80/people/bamboo/archives/001593_boo_meta_methods.html">Boo meta methods</a></p>
+</div>
+<div class="paragraph">
+<p><a href="https://github.com/cython/cython/wiki/enhancements-metaprogramming">Cython Metaprogramming Proposal</a> by Martin C Martin - Contains nice write-up of some use cases</p>
+</div>
+<div class="sect2">
+<h3 id="_jira_issues">JIRA issues:</h3>
+<div class="paragraph">
+<p>This feature is dependent on allowing annotations on local variables: <a href="https://issues.apache.org/jira/browse/GROOVY-3481">GROOVY-3481</a></p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">7 (2009-06-17)</dt>
+<dd>
+<p>Version as extracted from Codehaus wiki</p>
+</dd>
+<dt class="hdlist1">8 (2018-10-11)</dt>
+<dd>
+<p>Added comment about macros</p>
+</dd>
+</dl>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-3.html b/wiki/GEP-3.html
index f4c47fe..ec51a12 100644
--- a/wiki/GEP-3.html
+++ b/wiki/GEP-3.html
@@ -59,186 +59,450 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-3: Command Expression based DSL
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-3
-*Title*:: Command Expression based DSL
-*Version*:: 2
-*Type*:: Feature
-*Target*:: Groovy 1.8 or 2.0
-*Status*:: Final
-*Comment*:: Included in Groovy and has been further enhanced
-*Leader*:: Jochen "blackdrag" Theodorou
-*Created*:: 2009-06-30
-*Last modification* :: 2018-10-12
-****
-
-== Abstract
-
-Since Groovy 1.0 Groovy supports command expressions. These are method calls without parenthesizing the arguments.
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-3</a></li><li><a href='#_abstract' class='anchor-link'>Abstract</a></li><li><a href='#_rationale' class='anchor-link'>Rationale</a></li><li><a href='#_references_and_useful_links' class='anchor-link'>References and useful links</a></li><li><a href='#_update_history' class='anchor-link'>Update history</a> [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-3</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>Command Expression based DSL</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>2</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Target</strong>
+</td>
+<td class="hdlist2">
+<p>Groovy 1.8 or 2.0</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Final</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Comment</strong>
+</td>
+<td class="hdlist2">
+<p>Included in Groovy and has been further enhanced</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Jochen "blackdrag" Theodorou</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2009-06-30</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2018-10-12</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract">Abstract</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Since Groovy 1.0 Groovy supports command expressions. These are method calls without parenthesizing the arguments.
This would be in theory a nice base for DSLs, but our command expressions are too limited,
because we were not able to find easy rules on how to handle multiple arguments.
This proposal now tries to close the gap by defining the evaluation order and meaning of those arguments.
-The concept is very near to what Scala allows, but is not equal for historic reasons.
-
-== Rationale
-
-=== Current Command Expression
-
-Examples of current command expressions are:
-
-[options="header"]
-|===
-| Command expression | Meaning
-m| foo a1 m| foo (a1)
-m| foo {c} m| foo ({c})
-m| foo m {c} m| foo (m({c})
-m| foo a1, a2 m| foo (a1, a2)
-m| foo k1:v1, a2, k2:v2 m| foo ([k1:v1, k2:v2], a2)
-m| foo k1:m{c} m| foo ([k1:m({c})])
-|===
-
-Examples of current command expressions, that are not allowed:
-
-[options="header"]
-|===
-| Command expression | Possible meanings
-m| foo a1 a2
-a|
-----
-foo(a1,a2)
+The concept is very near to what Scala allows, but is not equal for historic reasons.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_rationale">Rationale</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_current_command_expression">Current Command Expression</h3>
+<div class="paragraph">
+<p>Examples of current command expressions are:</p>
+</div>
+<table class="tableblock frame-all grid-all stretch">
+<colgroup>
+<col style="width: 50%;">
+<col style="width: 50%;">
+</colgroup>
+<thead>
+<tr>
+<th class="tableblock halign-left valign-top">Command expression</th>
+<th class="tableblock halign-left valign-top">Meaning</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo (a1)</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo {c}</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo ({c})</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo m {c}</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo (m({c})</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1, a2</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo (a1, a2)</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo k1:v1, a2, k2:v2</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo ([k1:v1, k2:v2], a2)</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo k1:m{c}</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo ([k1:m({c})])</code></p></td>
+</tr>
+</tbody>
+</table>
+<div class="paragraph">
+<p>Examples of current command expressions, that are not allowed:</p>
+</div>
+<table class="tableblock frame-all grid-all stretch">
+<colgroup>
+<col style="width: 50%;">
+<col style="width: 50%;">
+</colgroup>
+<thead>
+<tr>
+<th class="tableblock halign-left valign-top">Command expression</th>
+<th class="tableblock halign-left valign-top">Possible meanings</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 a2</code></p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>foo(a1,a2)
foo(a1(a2))
-foo(a1).a2
-----
-
-m| foo a1 a2 a3
-a|
-----
-foo(a1,a2,a3)
+foo(a1).a2</pre>
+</div>
+</div></div></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 a2 a3</code></p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>foo(a1,a2,a3)
foo(a1(a2(a3)))
foo(a1).a2(a3)
-foo(a1,a2(a3))
-----
-|===
-
-This list is not intended to be complete.
-
-=== Constraints
-
-* existing valid usages must be kept as much as possible (for obvious backwards compatibility reasons)
-* the evaluation must be easily explainable
-* the grammar should support it
-
-=== Details
-
-What I want to allow are expressions such as:
-
-[options="header"]
-|===
-| Expression | Possible meanings | Allowed in old syntax
-m| foo {c} m| foo({c}) | icon:thumbs-up[] (same meaning)
-m| foo a1 m| foo(a1) | icon:thumbs-up[] (same meaning)
-m| foo a1() m| foo(a1()) | icon:thumbs-up[] (same meaning)
-m| foo a1 {c} m| foo(a1({c})) | icon:thumbs-up[] (same meaning)
-m| foo a1 a2 | icon:thumbs-down[] | icon:thumbs-down[]
-m| foo a1() a2 | icon:thumbs-down[] | icon:thumbs-down[]
-m| foo a1 a2() | icon:thumbs-down[] | icon:thumbs-down[]
-m| foo a1 a2 {c} | icon:thumbs-down[] | icon:thumbs-down[]
-m| foo a1 {c} a2 | icon:thumbs-down[] | icon:thumbs-down[]
-m| foo a1 {c} a2 {c} | icon:thumbs-down[] | icon:thumbs-down[]
-m| foo a1 a2 a3 m| foo(a1).a2(a3) | icon:thumbs-down[]
-m| foo a1() a2 a3() m| foo(a1()).a2(a3()) | icon:thumbs-down[]
-m| foo a1 a2() a3 | icon:thumbs-down[] | icon:thumbs-down[]
-m| foo a1 a2 a3 {c} m| foo(a1).a2(a3({c})) | icon:thumbs-down[]
-m| foo a1 a2 a3 a4 | icon:thumbs-down[] | icon:thumbs-down[]
-m| foo a1 a2 a3 a4 {c} | icon:thumbs-down[] | icon:thumbs-down[]
-m| foo a1 a2 a3 a4 a5 m| foo(a1).a2(a3).a4(a5) | icon:thumbs-down[]
-m| foo a1() a2 a3() a4 a5() m| foo(a1()).a2(a3()).a4(a5()) | icon:thumbs-down[]
-m| foo a1 a2 a3 a4 a5 {c} m| foo(a1).a2(a3).a4(a5({c}) | icon:thumbs-down[]
-|===
-
-The table shows enough to recognize the pattern. The attached block has a special role as it does not count as argument
+foo(a1,a2(a3))</pre>
+</div>
+</div></div></td>
+</tr>
+</tbody>
+</table>
+<div class="paragraph">
+<p>This list is not intended to be complete.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_constraints">Constraints</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>existing valid usages must be kept as much as possible (for obvious backwards compatibility reasons)</p>
+</li>
+<li>
+<p>the evaluation must be easily explainable</p>
+</li>
+<li>
+<p>the grammar should support it</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_details">Details</h3>
+<div class="paragraph">
+<p>What I want to allow are expressions such as:</p>
+</div>
+<table class="tableblock frame-all grid-all stretch">
+<colgroup>
+<col style="width: 33.3333%;">
+<col style="width: 33.3333%;">
+<col style="width: 33.3334%;">
+</colgroup>
+<thead>
+<tr>
+<th class="tableblock halign-left valign-top">Expression</th>
+<th class="tableblock halign-left valign-top">Possible meanings</th>
+<th class="tableblock halign-left valign-top">Allowed in old syntax</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo {c}</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo({c})</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs up]</span> (same meaning)</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo(a1)</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs up]</span> (same meaning)</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1()</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo(a1())</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs up]</span> (same meaning)</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 {c}</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo(a1({c}))</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs up]</span> (same meaning)</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 a2</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1() a2</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 a2()</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 a2 {c}</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 {c} a2</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 {c} a2 {c}</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 a2 a3</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo(a1).a2(a3)</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1() a2 a3()</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo(a1()).a2(a3())</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 a2() a3</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 a2 a3 {c}</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo(a1).a2(a3({c}))</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 a2 a3 a4</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 a2 a3 a4 {c}</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 a2 a3 a4 a5</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo(a1).a2(a3).a4(a5)</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1() a2 a3() a4 a5()</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo(a1()).a2(a3()).a4(a5())</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo a1 a2 a3 a4 a5 {c}</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>foo(a1).a2(a3).a4(a5({c})</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><span class="icon">[thumbs down]</span></p></td>
+</tr>
+</tbody>
+</table>
+<div class="paragraph">
+<p>The table shows enough to recognize the pattern. The attached block has a special role as it does not count as argument
on its own directly. Instead the block is always bound to the identifier before and makes a method call.
That itself is no command expression, but a normal method call expression. As can be seen too,
this syntax nicely extends the existing Groovy syntax. Of course this also means, it will not be possible to omit
-commas if multiple arguments are used. A case that is not supported today anyway. For a DSL that is not really a problem though.
-
-==== Summary of the pattern
-
-* A command-expression is composed of an even number of elements
-* The elements are alternating a method name, and its parameters (can be named and non-named parameters)
-* A parameter element can be any kind of expression (i.e. a method call foo(), foo{}, or some expression like x+y)
-* All those pairs of method name and parameters are actually chained method calls (i.e. send "hello" to "Guillaume"
-is two methods chained one after the other as send("hello").to("Guillaume"))
-
-==== Interesting benefit of the enhanced command expressions
-
-More and more do we see Java Fluent APIs that chain method calls, returning this, to "build" a new object.
-For instance, you can imagine a fluent API for building an Email message, that would look something like this in Java:
-```
-Email.from("foo@example.com").to("bar@example.com").subject("hello").body("how are you?")
-```
-In Groovy, with the extended command expressions, this could become:
-```
-Email.from "foo@example.com" to "bar@example.com" subject "hello" body "how are you?"
-```
-Notice the absence of parentheses and dots.
-
-==== Example: A DSL for SQL
-
-
-```
-SELECT "column_name"
+commas if multiple arguments are used. A case that is not supported today anyway. For a DSL that is not really a problem though.</p>
+</div>
+<div class="sect3">
+<h4 id="_summary_of_the_pattern">Summary of the pattern</h4>
+<div class="ulist">
+<ul>
+<li>
+<p>A command-expression is composed of an even number of elements</p>
+</li>
+<li>
+<p>The elements are alternating a method name, and its parameters (can be named and non-named parameters)</p>
+</li>
+<li>
+<p>A parameter element can be any kind of expression (i.e. a method call foo(), foo{}, or some expression like x+y)</p>
+</li>
+<li>
+<p>All those pairs of method name and parameters are actually chained method calls (i.e. send "hello" to "Guillaume"
+is two methods chained one after the other as send("hello").to("Guillaume"))</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_interesting_benefit_of_the_enhanced_command_expressions">Interesting benefit of the enhanced command expressions</h4>
+<div class="paragraph">
+<p>More and more do we see Java Fluent APIs that chain method calls, returning this, to "build" a new object.
+For instance, you can imagine a fluent API for building an Email message, that would look something like this in Java:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>Email.from("foo@example.com").to("bar@example.com").subject("hello").body("how are you?")</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>In Groovy, with the extended command expressions, this could become:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>Email.from "foo@example.com" to "bar@example.com" subject "hello" body "how are you?"</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Notice the absence of parentheses and dots.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_example_a_dsl_for_sql">Example: A DSL for SQL</h4>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>SELECT "column_name"
FROM "table_name"
-WHERE "column_name" IN ('value1', 'value2', ...)
-```
-In current Groovy this could be expressed by
-```
-sql.select(
+WHERE "column_name" IN ('value1', 'value2', ...)</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>In current Groovy this could be expressed by</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>sql.select(
"column_name",
from:"table_name",
where:"column_name",
- in:['value1','value2',...])
-```
-With this new command dsl you could also do
-```
-sql.
+ in:['value1','value2',...])</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>With this new command dsl you could also do</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>sql.
select "column_name" \\
from "table_name" \\
where "column_name" \\
- in ['value1','value2',...]
-```
-It should be noticed, that both cases have quite different semantics. In the second case the writer saves a lot of commas, but of course not all of them. Also the lack of any kind of operator like the comma makes it difficult to span the DSL across multiple lines. A more extended example would be
-```
-SELECT COUNT("column_name")
+ in ['value1','value2',...]</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>It should be noticed, that both cases have quite different semantics. In the second case the writer saves a lot of commas, but of course not all of them. Also the lack of any kind of operator like the comma makes it difficult to span the DSL across multiple lines. A more extended example would be</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>SELECT COUNT("column_name")
FROM "table_name"
-sql.select count("column_name") from "table_name"
-```
-To express this in map style is a bit difficult, because of where to place count... a possible version is maybe
-```
-sql.select(sql.count("column_name"), from:"table_name"
-```
-
-==== More example ideas
-
-Here are some additional examples which relate to various domains, which may make the idea more visual in our minds.
+sql.select count("column_name") from "table_name"</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>To express this in map style is a bit difficult, because of where to place count…​ a possible version is maybe</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>sql.select(sql.count("column_name"), from:"table_name"</code></pre>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_more_example_ideas">More example ideas</h4>
+<div class="paragraph">
+<p>Here are some additional examples which relate to various domains, which may make the idea more visual in our minds.
These examples also mix named and non-named arguments, the use closures or not.
-In comments, alongside the example, you'll see the equivalent non-command expression interpretation.
-
-```
-sell 100.shares of MSFT // sell(100.shares).of(MSFT)
+In comments, alongside the example, you’ll see the equivalent non-command expression interpretation.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>sell 100.shares of MSFT // sell(100.shares).of(MSFT)
every 10.minutes, execute {} // already possible with current command expressions
schedule executionOf { ... } every 10.minutes // scheduler(executionOf({})).every(10.minutes)
blend red, green of acrylic // blend(red, gree).of(acrylic)
// named parameters into the mix
-select from: users where age > 32 and sex == 'male'
-// equivalent to select(from: users).where(age > 32).and(sex == 'male')
+select from: users where age > 32 and sex == 'male'
+// equivalent to select(from: users).where(age > 32).and(sex == 'male')
// not that however for this example, it would be intersting
// to transparently convert the boolean conditions into closure expressions!
@@ -247,88 +511,171 @@ take mediumBowl
combine soySauce, vinegar, chiliPowder, garlic
place chicken in sauce
turn once to coat
-marinate 30.minutes at roomTemperature
-```
-
-==== Extension to command expressions in the case of assignments
-
-Currently, command expressions are allowed as standalone top-level statements or expressions, but you can't assign such an expression to a variable with keeping that nice DSL syntax. For instance, while you can do:
-```
-move left
-```
-If you wanted to assign that command (which could return a Position instance), you would like to do
-```
-def newPosition = move left
-```
-But you still have to do
-```
-def newPosition = move(left)
-```
-So the GEP-3 proposal also suggests we extend command expressions to be allowed on the RHS of assignments.
-
-==== Differences to Scala
-
-For historic reasons
-```
-println foo
-```
-has to be supported. This seems not to be a valid version in Scala, since that would be interpreted as
-```
-println.foo
-```
-and not as
-```
-this.println foo
-```
-On the other hand
-```
-foo bar a1
-```
-is interpreted as
-```
-foo.bar(a1)
-```
-in Scala and is invalid in current Groovy as well as after this proposal. So it could be stated, that this proposal is less object-oriented then Scala, because the DSL usually starts with the method, not the object. On the other hand it is possible to write
-```
-foo.bar a1
-```
-So the Groovy notation would be a bit more verbose, but not much.
-
-==== To be evaluated: Mixed case with explicit parentheses
-
-A possible supported case is also when mixing method calls with explicit parentheses within that extended command expression.
-The benefit would be to allow the ability to also be able to call methods not taking parameters, as well as allowing an odd number of "elements" (i.e. a method name or a parameter).
-```
-m1 a m2 b m3()
+marinate 30.minutes at roomTemperature</code></pre>
+</div>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_extension_to_command_expressions_in_the_case_of_assignments">Extension to command expressions in the case of assignments</h4>
+<div class="paragraph">
+<p>Currently, command expressions are allowed as standalone top-level statements or expressions, but you can’t assign such an expression to a variable with keeping that nice DSL syntax. For instance, while you can do:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>move left</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>If you wanted to assign that command (which could return a Position instance), you would like to do</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>def newPosition = move left</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>But you still have to do</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>def newPosition = move(left)</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>So the GEP-3 proposal also suggests we extend command expressions to be allowed on the RHS of assignments.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_differences_to_scala">Differences to Scala</h4>
+<div class="paragraph">
+<p>For historic reasons</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>println foo</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>has to be supported. This seems not to be a valid version in Scala, since that would be interpreted as</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>println.foo</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>and not as</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>this.println foo</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>On the other hand</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>foo bar a1</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>is interpreted as</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>foo.bar(a1)</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>in Scala and is invalid in current Groovy as well as after this proposal. So it could be stated, that this proposal is less object-oriented then Scala, because the DSL usually starts with the method, not the object. On the other hand it is possible to write</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>foo.bar a1</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>So the Groovy notation would be a bit more verbose, but not much.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_to_be_evaluated_mixed_case_with_explicit_parentheses">To be evaluated: Mixed case with explicit parentheses</h4>
+<div class="paragraph">
+<p>A possible supported case is also when mixing method calls with explicit parentheses within that extended command expression.
+The benefit would be to allow the ability to also be able to call methods not taking parameters, as well as allowing an odd number of "elements" (i.e. a method name or a parameter).</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>m1 a m2 b m3()
m1 a m2() m3 b
-m1() m2 a m3 b
-```
-would be respectively equivalent to:
-```
-m1(a).m2(b).m3()
+m1() m2 a m3 b</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>would be respectively equivalent to:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>m1(a).m2(b).m3()
m1(a).m2().m3(b)
-m1().m2(a).m3(b)
-```
-Note that the method calls with explicit parentheses could also take a number of arguments.
-For instance, this is also a valid mixed command expression:
-```
-m1 a m2(1, 2, 3) m3 b
-```
-
-== References and useful links
-
-=== JIRA issues:
-
-* Implement GEP-3: extended command expressions https://issues.apache.org/jira/browse/GROOVY-4384[GROOVY-4384]
-* Ability to use (extended) command expression on the RHS https://issues.apache.org/jira/browse/GROOVY-4401[GROOVY-4401]
-* Allow zero-args methods in the chain of calls https://issues.apache.org/jira/browse/GROOVY-4402[GROOVY-4402]
-* Disambiguate cases where minus something or [] or {} are used as the argument of extended command expressions https://issues.apache.org/jira/browse/GROOVY-4403[GROOVY-4403]
-
-== Update history
-
-1 (2009-06-17):: Version as extracted from Codehaus wiki
-2 (2018-10-11):: Numerous minor tweaks
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-3</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-3</h1><hr/></div></div></div></div><footer id='footer'>
+m1().m2(a).m3(b)</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Note that the method calls with explicit parentheses could also take a number of arguments.
+For instance, this is also a valid mixed command expression:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>m1 a m2(1, 2, 3) m3 b</code></pre>
+</div>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_jira_issues">JIRA issues:</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>Implement GEP-3: extended command expressions <a href="https://issues.apache.org/jira/browse/GROOVY-4384">GROOVY-4384</a></p>
+</li>
+<li>
+<p>Ability to use (extended) command expression on the RHS <a href="https://issues.apache.org/jira/browse/GROOVY-4401">GROOVY-4401</a></p>
+</li>
+<li>
+<p>Allow zero-args methods in the chain of calls <a href="https://issues.apache.org/jira/browse/GROOVY-4402">GROOVY-4402</a></p>
+</li>
+<li>
+<p>Disambiguate cases where minus something or [] or {} are used as the argument of extended command expressions <a href="https://issues.apache.org/jira/browse/GROOVY-4403">GROOVY-4403</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">1 (2009-06-17)</dt>
+<dd>
+<p>Version as extracted from Codehaus wiki</p>
+</dd>
+<dt class="hdlist1">2 (2018-10-11)</dt>
+<dd>
+<p>Numerous minor tweaks</p>
+</dd>
+</dl>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-4.html b/wiki/GEP-4.html
index 263e235..510daab 100644
--- a/wiki/GEP-4.html
+++ b/wiki/GEP-4.html
@@ -59,62 +59,151 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-4: AstBuilder AST Templates
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-4
-*Title*:: AstBuilder AST Templates
-*Version*:: 2
-*Type*:: Feature
-*Status*:: Rejected
-*Comment*:: The approach used in Groovy macros was pursued instead
-*Leader*:: Hamlet D'Arcy
-*Created*:: 2010-02-16
-*Last modification* :: 2018-10-12
-****
-
-== Abstract
-
-The AstBuilder was introduced in Groovy 1.7 as a way to ease the task of writing AST transformations.
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-4</a></li><li><a href='#_abstract' class='anchor-link'>Abstract</a></li><li><a href='#_approach' class='anchor-link'>Approach</a></li><li><a href='#_references_and_useful_links' class='anchor-link'>References and useful links</a></li><li><a href='#_update_history' class='anchor-link'>Update history</a></ [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-4</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>AstBuilder AST Templates</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>2</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Rejected</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Comment</strong>
+</td>
+<td class="hdlist2">
+<p>The approach used in Groovy macros was pursued instead</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Hamlet D’Arcy</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2010-02-16</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2018-10-12</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract">Abstract</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The AstBuilder was introduced in Groovy 1.7 as a way to ease the task of writing AST transformations.
The "fromCode" approach allows you to generate the AST from a piece of code. Currently, the AstBuilder fromCode API
accepts a closure as a parameter, and the code within the closure it transformed to AST.
A limitation of the AstBuilder is that the closure parameter does not allow variables in the surrounding
context to be referenced: there is no way to pass a parameter into the code block.
-It was initially discussed but the idea was deemed too much effort to fit into 1.7.
-
-This AST Template feature allows you to pass parameters into the AstBuilder.
+It was initially discussed but the idea was deemed too much effort to fit into 1.7.</p>
+</div>
+<div class="paragraph">
+<p>This AST Template feature allows you to pass parameters into the AstBuilder.
Similar to how a $ works in GString interpolation, there needs to be a way to bind a variable from the
enclosing scope into an AstBuilder closure. The syntax proposed is to use oxford brackets (see below).
-An AstBuilder closure containing GEP 4 - AstBuilder AST Templates will have the variable within the brackets bound in.
-
-== Approach
-
-The oxford brackets are used to bind, or quasi-quote, variables from the enclosing scope into an AstBuilder parameter.
-
-Example 1: String concatenation
-```
-def constant = new ConstantExpression("World")
-List<ASTNode> greeting = AstBuilder.buildFromCode { "Hello" + [ | constant | ] }
-```
-Produces the AST
-```
-BlockStatement
--> ExpressionStatement
- -> BinaryExpression +
- -> ConstantExpresssion - Hello
- -> ConstantExpression - World
-```
-Example 2: Producing a println
-```
-new AstBuilder().buildFromCode { println([ | message | ]) }[0]
-```
-is equivalent to invoking this method:
-```
-private Statement createPrintlnAst(String message) {
+An AstBuilder closure containing GEP 4 - AstBuilder AST Templates will have the variable within the brackets bound in.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_approach">Approach</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The oxford brackets are used to bind, or quasi-quote, variables from the enclosing scope into an AstBuilder parameter.</p>
+</div>
+<div class="paragraph">
+<p>Example 1: String concatenation</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>def constant = new ConstantExpression("World")
+List<ASTNode> greeting = AstBuilder.buildFromCode { "Hello" + [ | constant | ] }</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Produces the AST</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>BlockStatement
+-> ExpressionStatement
+ -> BinaryExpression +
+ -> ConstantExpresssion - Hello
+ -> ConstantExpression - World</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Example 2: Producing a println</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>new AstBuilder().buildFromCode { println([ | message | ]) }[0]</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>is equivalent to invoking this method:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>private Statement createPrintlnAst(String message) {
return new ExpressionStatement(
new MethodCallExpression(
new VariableExpression("this"),
@@ -124,13 +213,18 @@ private Statement createPrintlnAst(String message) {
)
)
)
-}
-```
-Example 3: Memoization of a method
-
-Presumably, you would have the existing method AST in a variable called "methodNode":
-```
-def methodNode = ...
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Example 3: Memoization of a method</p>
+</div>
+<div class="paragraph">
+<p>Presumably, you would have the existing method AST in a variable called "methodNode":</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>def methodNode = ...
def parameters = methodNode.parameters
def newMethod = new AstBuilder().buildFromCode {
@@ -142,47 +236,93 @@ def newMethod = new AstBuilder().buildFromCode {
return result
}
-methodNode.code = newMethod[0]
-```
-=== Alternatives
-
-There are many syntax alternatives:
-
-* Lisp uses ´ and ,
-* Template Haskell uses something similar to oxford brackets but with slightly different semantics
-* Boo uses GEP 4 - AstBuilder AST Templates and $ but with slightly different semantics
-
-A $ was considered but cannot be used as it is already a meaningful identifier.
+methodNode.code = newMethod[0]</code></pre>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_alternatives">Alternatives</h3>
+<div class="paragraph">
+<p>There are many syntax alternatives:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Lisp uses ´ and ,</p>
+</li>
+<li>
+<p>Template Haskell uses something similar to oxford brackets but with slightly different semantics</p>
+</li>
+<li>
+<p>Boo uses GEP 4 - AstBuilder AST Templates and $ but with slightly different semantics</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>A $ was considered but cannot be used as it is already a meaningful identifier.
Boo Metamethod Comparison
-The Boo Metamethod feature overlaps with the Groovy AST Transformation features. Instead of an @AstTransformation interface with a separately defined AstTransformation subclass, Boo offers Meta methods, where the AST Transformation is called and generated at compile time.
-
-While Groovy offers AstBuilder to turn code into AST, Boo uses the oxford brackets. And while GEP-4 proposed oxford brackets to signify an AST variable templating, Boo uses the $. Consider a simple println AST in Groovy
-```
-new AstBuilder().buildFromCode {
+The Boo Metamethod feature overlaps with the Groovy AST Transformation features. Instead of an @AstTransformation interface with a separately defined AstTransformation subclass, Boo offers Meta methods, where the AST Transformation is called and generated at compile time.</p>
+</div>
+<div class="paragraph">
+<p>While Groovy offers AstBuilder to turn code into AST, Boo uses the oxford brackets. And while GEP-4 proposed oxford brackets to signify an AST variable templating, Boo uses the $. Consider a simple println AST in Groovy</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>new AstBuilder().buildFromCode {
println([ | message | ])
-}[0]
-```
-Compared to a similar construct in Boo:
-```
-[Meta]
+}[0]</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Compared to a similar construct in Boo:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>[Meta]
static def methodname(expr as Expression):
- [| println($expr) |]
-```
-GEP-4 proposes the opposite syntax from Boo: oxford brackets for AST Templating instead of the $. The $ is already a character in Java, and can be part of a variable name.
-
-There are no real drawbacks to having an opposite syntax. The number of Boo AST Transformation writers migrating to Groovy is most likely quite low.
-
-== References and useful links
-
-Mailing-List Discussions
-
-* groovy-dev: https://marc.info/?l=groovy-dev&m=126632536126812&w=2[Groovy AstBuilder AST Templates]
-
-== Update history
-
-1 (2010-02-16):: Version as extracted from Codehaus wiki
-2 (2018-10-14):: Numerous minor tweaks
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-4</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-4</h1><hr/></div></div></div></div><footer id='footer'>
+ [| println($expr) |]</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>GEP-4 proposes the opposite syntax from Boo: oxford brackets for AST Templating instead of the $. The $ is already a character in Java, and can be part of a variable name.</p>
+</div>
+<div class="paragraph">
+<p>There are no real drawbacks to having an opposite syntax. The number of Boo AST Transformation writers migrating to Groovy is most likely quite low.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Mailing-List Discussions</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>groovy-dev: <a href="https://marc.info/?l=groovy-dev&m=126632536126812&w=2">Groovy AstBuilder AST Templates</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">1 (2010-02-16)</dt>
+<dd>
+<p>Version as extracted from Codehaus wiki</p>
+</dd>
+<dt class="hdlist1">2 (2018-10-14)</dt>
+<dd>
+<p>Numerous minor tweaks</p>
+</dd>
+</dl>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-5.html b/wiki/GEP-5.html
index be39b1b..a97255a 100644
--- a/wiki/GEP-5.html
+++ b/wiki/GEP-5.html
@@ -59,56 +59,165 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-5: File extension dependent AST transformations
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-5
-*Title*:: File extension dependent AST transformations
-*Version*:: 2
-*Type*:: Feature
-*Status*:: Rejected
-*Comment*:: A general compiler configuration mechanism was adopted instead and delivered in Groovy 1.8
-*Leader*:: Alex Tkachman
-*Created*:: 2010-02-26
-*Last modification* :: 2018-10-12
-****
-
-== Abstract: What is a file extension dependent AST transformations?
-
-AST transformations is powerful tool for creating DSLs. Two ways to define AST transformations exist today - via annotation and global transformation, which apply to everything. This proposal introduce new type - transformations, which apply only to source files with given extension.
-
-Such approach gives possibility to have better and unified way to organize code base containing groovy based DSLs.
-
-=== How to implement?
-
-There are two problems to be addressed:
-
-* how to make AST transformation extension aware
-* how to make Groovyc or FileSystemCompiler or even IDE aware about additional (to *.groovy) extensions to be compiled
-Interesting that first problem doesn't require any specific handling at all. Global AST transformation can use name of SourceUnit to filter what files to process.
-
-For second problem file `META-INF/services/org.codehaus.groovy.transform.ASTTransformation` where global AST transformations normally defined can be used. To keep things backward compatible following syntax is suggested
-```
-#files:<ext1>,<ext2>...
-```
-The main benefit of using configuration files are:
-
-* new frameworks using AST based transformations make compiler aware about files to be compiled just by dropping in to classpath
-* it is very easy for any incarnation of compiler (FileSystemCompiler or Groovyc or whatever) to scan classpath and find extensions to be compiled
-
-== URLs
-
-https://marc.info/?l=groovy-dev&m=126725425413269&w=2[groovy-dev: GEP 5 - file extension based AST transformations]
-
-== Update history
-
-1 (2010-02-16):: Version as extracted from Codehaus wiki
-2 (2018-10-14):: Numerous minor tweaks
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-5</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-5</h1><hr/></div></div></div></div><footer id='footer'>
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-5</a></li><li><a href='#_abstract_what_is_a_file_extension_dependent_ast_transformations' class='anchor-link'>Abstract: What is a file extension dependent AST transformations?</a></li><li><a href='#_urls' class='anchor-link'>URLs</a></li><li><a href='#_update_history' class='anchor-link'>Update history</ [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-5</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>File extension dependent AST transformations</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>2</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Rejected</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Comment</strong>
+</td>
+<td class="hdlist2">
+<p>A general compiler configuration mechanism was adopted instead and delivered in Groovy 1.8</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Alex Tkachman</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2010-02-26</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2018-10-12</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract_what_is_a_file_extension_dependent_ast_transformations">Abstract: What is a file extension dependent AST transformations?</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>AST transformations is powerful tool for creating DSLs. Two ways to define AST transformations exist today - via annotation and global transformation, which apply to everything. This proposal introduce new type - transformations, which apply only to source files with given extension.</p>
+</div>
+<div class="paragraph">
+<p>Such approach gives possibility to have better and unified way to organize code base containing groovy based DSLs.</p>
+</div>
+<div class="sect2">
+<h3 id="_how_to_implement">How to implement?</h3>
+<div class="paragraph">
+<p>There are two problems to be addressed:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>how to make AST transformation extension aware</p>
+</li>
+<li>
+<p>how to make Groovyc or FileSystemCompiler or even IDE aware about additional (to *.groovy) extensions to be compiled
+Interesting that first problem doesn’t require any specific handling at all. Global AST transformation can use name of SourceUnit to filter what files to process.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>For second problem file <code>META-INF/services/org.codehaus.groovy.transform.ASTTransformation</code> where global AST transformations normally defined can be used. To keep things backward compatible following syntax is suggested</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>#files:<ext1>,<ext2>...</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The main benefit of using configuration files are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>new frameworks using AST based transformations make compiler aware about files to be compiled just by dropping in to classpath</p>
+</li>
+<li>
+<p>it is very easy for any incarnation of compiler (FileSystemCompiler or Groovyc or whatever) to scan classpath and find extensions to be compiled</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_urls">URLs</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p><a href="https://marc.info/?l=groovy-dev&m=126725425413269&w=2">groovy-dev: GEP 5 - file extension based AST transformations</a></p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">1 (2010-02-16)</dt>
+<dd>
+<p>Version as extracted from Codehaus wiki</p>
+</dd>
+<dt class="hdlist1">2 (2018-10-14)</dt>
+<dd>
+<p>Numerous minor tweaks</p>
+</dd>
+</dl>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-6.html b/wiki/GEP-6.html
index 2c378a6..e9bcc33 100644
--- a/wiki/GEP-6.html
+++ b/wiki/GEP-6.html
@@ -59,95 +59,226 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-6: NIO2 Support for Groovy
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-6
-*Title*:: NIO2 Support for Groovy
-*Version*:: 2
-*Type*:: Feature
-*Status*:: Final
-*Comment*:: Delivered in Groovy 2.3
-*Leader*:: Merlyn Albery-Speyer/Hamlet D'Arcy
-*Created*:: 2010-09-25
-*Last modification* :: 2018-10-12
-****
-
-== Abstract
-
-JDK 7 includes a new java.nio.file package and Path class.
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-6</a></li><li><a href='#_abstract' class='anchor-link'>Abstract</a></li><li><a href='#_approach' class='anchor-link'>Approach</a></li><li><a href='#_references_and_useful_links' class='anchor-link'>References and useful links</a></li><li><a href='#_update_history' class='anchor-link'>Update history</a></ [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-6</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>NIO2 Support for Groovy</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>2</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Final</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Comment</strong>
+</td>
+<td class="hdlist2">
+<p>Delivered in Groovy 2.3</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Merlyn Albery-Speyer/Hamlet D’Arcy</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2010-09-25</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2018-10-12</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract">Abstract</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>JDK 7 includes a new java.nio.file package and Path class.
These provide extended capabilities for filesystem tasks.
-We should explore incorporation into Groovy.
-
-== Approach
-
-I propose:
-
-* Create an openjdk7 build of Groovy
-* Move NIO2 support to a Groovy Module for now
-* Move NIO2 Groovy Module to Groovy-core when JDK7 is officially released
-
-JDK7 is still in beta. It is subject to change. If we build NIO2 support into Groovy today and make a release,
-then we risk having JDK7 make an API change, which would force us to support 2 different APIs. That would be bad.
-
-=== Todo in Groovy NIO Module:
-
-* Support new Path object
-* All the GDK File API needs to be on Path
-* NIO2 contains a new WatchService API. We need to probably provide a GDK on WatchService to make it easy to work
-with using closures, etc. This is the most interesting piece of work IMO.
-
-=== Todo in Groovy Core:
-
-Groovy has a FileNameFinder and FileNameRegExFinder. This stuff needs to work with Paths as well:
-http://mrhaki.blogspot.com/2009/11/groovy-goodness-finding-files-with.html
-
-I haven't looked at each file in this list yet, but we need to analyze these Groovy source files and see if
-any parallel Path implementations are needed. The first 3 files look like the most important:
-
-```
-./groovy/util/IFileNameFinder.java
+We should explore incorporation into Groovy.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_approach">Approach</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>I propose:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Create an openjdk7 build of Groovy</p>
+</li>
+<li>
+<p>Move NIO2 support to a Groovy Module for now</p>
+</li>
+<li>
+<p>Move NIO2 Groovy Module to Groovy-core when JDK7 is officially released</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>JDK7 is still in beta. It is subject to change. If we build NIO2 support into Groovy today and make a release,
+then we risk having JDK7 make an API change, which would force us to support 2 different APIs. That would be bad.</p>
+</div>
+<div class="sect2">
+<h3 id="_todo_in_groovy_nio_module">Todo in Groovy NIO Module:</h3>
+<div class="ulist">
+<ul>
+<li>
+<p>Support new Path object</p>
+</li>
+<li>
+<p>All the GDK File API needs to be on Path</p>
+</li>
+<li>
+<p>NIO2 contains a new WatchService API. We need to probably provide a GDK on WatchService to make it easy to work
+with using closures, etc. This is the most interesting piece of work IMO.</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_todo_in_groovy_core">Todo in Groovy Core:</h3>
+<div class="paragraph">
+<p>Groovy has a FileNameFinder and FileNameRegExFinder. This stuff needs to work with Paths as well:
+<a href="http://mrhaki.blogspot.com/2009/11/groovy-goodness-finding-files-with.html" class="bare">http://mrhaki.blogspot.com/2009/11/groovy-goodness-finding-files-with.html</a></p>
+</div>
+<div class="paragraph">
+<p>I haven’t looked at each file in this list yet, but we need to analyze these Groovy source files and see if
+any parallel Path implementations are needed. The first 3 files look like the most important:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>./groovy/util/IFileNameFinder.java
./groovy/io/FileType.java
./groovy/io/FileVisitResult.java
./org/codehaus/groovy/runtime/WritableFile.java
./org/codehaus/groovy/ant/FileIterator.java
./org/codehaus/groovy/ant/FileScanner.java
-./org/codehaus/groovy/control/io/FileReaderSource.java
-```
-
-I couldn't find any instances of this in Groovy-core, but any `asType(File)` methods need a parallel
-`asType(Path)` - I believe `asWritable(Path)` is the only change required. In NIO2, I believe `File.list`
+./org/codehaus/groovy/control/io/FileReaderSource.java</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>I couldn’t find any instances of this in Groovy-core, but any <code>asType(File)</code> methods need a parallel
+<code>asType(Path)</code> - I believe <code>asWritable(Path)</code> is the only change required. In NIO2, I believe <code>File.list</code>
and another method now return an iterator, which enables this method to work better over networks.
We need to update the File GDK to use this approach by default to also support network dir or ls style listings.
-NIO2 has a new `FileVisitor` class. We need to unify this new `FileVisitor` JDK method with what Groovy does
-today in with GDK with the `.eachFile` method. As well as the `.eachFileXXX` methods and the `.eachDirXXX`
-methods we should include the `.traverse` method when looking through potential places for unification.
-The `.traverse` method's primary role was to make some `FileVisitor` like functionality available in the pre-JDK 7
+NIO2 has a new <code>FileVisitor</code> class. We need to unify this new <code>FileVisitor</code> JDK method with what Groovy does
+today in with GDK with the <code>.eachFile</code> method. As well as the <code>.eachFileXXX</code> methods and the <code>.eachDirXXX</code>
+methods we should include the <code>.traverse</code> method when looking through potential places for unification.
+The <code>.traverse</code> method’s primary role was to make some <code>FileVisitor</code> like functionality available in the pre-JDK 7
world but having NIO2 there might open up some more possibilities. There was also some thought at the time of having
additional overloaded traverse methods with a more statically typed flavor rather than just the current Map solution.
-I guess now is a good time to also look at that option.
-
-== References and useful links
-
-=== Mailing-list discussions
-
-* https://marc.info/?l=groovy-dev&m=128540553001110&w=2[groovy-dev: OpenJDK 7 Groovy Build and NIO2 support]
-* https://docs.oracle.com/javase/8/docs/technotes/guides/io/index.html[Java I/O, NIO and NIO.2]
-
-=== JIRA issues
-
-* https://issues.apache.org/jira/browse/GROOVY-4390[GROOVY-4390: Add GDK File methods to the NIO2 API]
-* https://issues.apache.org/jira/browse/GROOVY-4391[GROOVY-4391: Groovy build fails test target using Java 1.7.0]
-
-== Update history
-
-1 (2010-02-16):: Version as extracted from Codehaus wiki
-2 (2018-10-14):: Numerous minor tweaks
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-6</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-6</h1><hr/></div></div></div></div><footer id='footer'>
+I guess now is a good time to also look at that option.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_mailing_list_discussions">Mailing-list discussions</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://marc.info/?l=groovy-dev&m=128540553001110&w=2">groovy-dev: OpenJDK 7 Groovy Build and NIO2 support</a></p>
+</li>
+<li>
+<p><a href="https://docs.oracle.com/javase/8/docs/technotes/guides/io/index.html">Java I/O, NIO and NIO.2</a></p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_jira_issues">JIRA issues</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-4390">GROOVY-4390: Add GDK File methods to the NIO2 API</a></p>
+</li>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-4391">GROOVY-4391: Groovy build fails test target using Java 1.7.0</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">1 (2010-02-16)</dt>
+<dd>
+<p>Version as extracted from Codehaus wiki</p>
+</dd>
+<dt class="hdlist1">2 (2018-10-14)</dt>
+<dd>
+<p>Numerous minor tweaks</p>
+</dd>
+</dl>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-7.html b/wiki/GEP-7.html
index e3f3d6a..6b93e79 100644
--- a/wiki/GEP-7.html
+++ b/wiki/GEP-7.html
@@ -59,40 +59,123 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-7: JSON Support
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-7
-*Title*:: JSON Support
-*Version*:: 4
-*Type*:: Feature
-*Status*:: Final
-*Comment*:: Delivered in Groovy 1.8
-*Leader*:: Guillaume Laforge
-*Contributors*:: Andres Almiray
-*Created*:: 2010-10-25
-*Last modification* :: 2018-10-12
-****
-
-== Abstract: JSON Support
-
-Provide a builder/slurper combination for handling data in JSON format in a similar fashion as it's already done for XML.
-
-== Rationale
-
-JSON has become ubiquitous to the web. RESTful services exchange data in both POX (Plain Old XML) and JSON formats.
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-7</a></li><li><a href='#_abstract_json_support' class='anchor-link'>Abstract: JSON Support</a></li><li><a href='#_rationale' class='anchor-link'>Rationale</a></li><li><a href='#_references_and_useful_links' class='anchor-link'>References and useful links</a></li><li><a href='#_update_history' class='anch [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-7</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>JSON Support</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>4</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Final</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Comment</strong>
+</td>
+<td class="hdlist2">
+<p>Delivered in Groovy 1.8</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Guillaume Laforge</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Contributors</strong>
+</td>
+<td class="hdlist2">
+<p>Andres Almiray</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2010-10-25</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2018-10-12</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract_json_support">Abstract: JSON Support</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Provide a builder/slurper combination for handling data in JSON format in a similar fashion as it’s already done for XML.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_rationale">Rationale</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>JSON has become ubiquitous to the web. RESTful services exchange data in both POX (Plain Old XML) and JSON formats.
Groovy has excellent support for producing/consuming XML with MarkupBuilder, XmlSlurper and XmlParser but lacks this
-kind support for JSON. This GEP strives to remedy the situation, by providing a compatible builder approach.
-
-=== Producing JSON
-The following builder syntax is proposed
-
-```
-def builder = new groovy.json.JsonBuilder()
+kind support for JSON. This GEP strives to remedy the situation, by providing a compatible builder approach.</p>
+</div>
+<div class="sect2">
+<h3 id="_producing_json">Producing JSON</h3>
+<div class="paragraph">
+<p>The following builder syntax is proposed</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>def builder = new groovy.json.JsonBuilder()
def root = builder.people {
person {
firstName 'Guillame'
@@ -129,105 +212,166 @@ println builder.toString()
"Gr8conf"
]
}
-}
-```
-
-Valid node values are: `Number`, `String`, `GString`, `Boolean`, `Map`, `List`. `null` is reserved for object references.
-Arrays can not be null, but they can be empty. Anything else results in an IAE (or a more specialized exception) being thrown.
-
-=== Special cases
-
-There is a special case to be considered: when the top node results in an anonymous object or array.
-or objects a call() method on the builder is needed which takes a map as argument, for arrays call() takes a vararg of values. Here are some examples:
-
-```
-builder.foo "foo"
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Valid node values are: <code>Number</code>, <code>String</code>, <code>GString</code>, <code>Boolean</code>, <code>Map</code>, <code>List</code>. <code>null</code> is reserved for object references.
+Arrays can not be null, but they can be empty. Anything else results in an IAE (or a more specialized exception) being thrown.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_special_cases">Special cases</h3>
+<div class="paragraph">
+<p>There is a special case to be considered: when the top node results in an anonymous object or array.
+or objects a call() method on the builder is needed which takes a map as argument, for arrays call() takes a vararg of values. Here are some examples:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>builder.foo "foo"
// produces
-{foo: "foo"}
-```
-
-```
-builder([{
+{foo: "foo"}</code></pre>
+</div>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>builder([{
foo 'foo'
}])
// produces
-[{"foo": "foo"}]
-```
-
-```
-builder([[
+[{"foo": "foo"}]</code></pre>
+</div>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>builder([[
foo: 'foo'
]])
// produces, same as above
-[{"foo": "foo"}]
-```
-
-```
-builder {
+[{"foo": "foo"}]</code></pre>
+</div>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>builder {
elem 1, 2, 3
}
// produces
-{ "elem": [1, 2, 3] }
-```
-When a method is called on the builder without arguments, and empty JSON object is associated with the key:
-
-```
-builder.element()
+{ "elem": [1, 2, 3] }</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>When a method is called on the builder without arguments, and empty JSON object is associated with the key:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>builder.element()
// produces
-{ "element": {} }
-```
-
-You can also pass a map and a closure argument:
-```
-builder.person(name: "Guillaume", age: 33) { town "Paris" }
+{ "element": {} }</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>You can also pass a map and a closure argument:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>builder.person(name: "Guillaume", age: 33) { town "Paris" }
// produces
-{"name": "Guillaume", "age": 33, "town": "Paris}
-```
-
-Calls like the following, with a map and a value, don't have any meaningful representation in JSON (unlike in XML), and triggers a JsonException:
-
-```
-shouldFail(JsonException) {
+{"name": "Guillaume", "age": 33, "town": "Paris}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Calls like the following, with a map and a value, don’t have any meaningful representation in JSON (unlike in XML), and triggers a JsonException:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>shouldFail(JsonException) {
builder.elem(a: 1, b: 2, "some text value")
-}
-```
-
-In case of overlapping keys in the map and the closure, the closure wins – a visual clue for this rule is that the closure appears "after" the map key/value pairs.
-
-Consuming JSON
-The proposal is for the creation of a JsonSlurper class that can read JSON from a string (in a non-streaming fashion) and produce a hierarchy of maps and lists representing the JSON objects and arrays respectively.
-```
-String json = '{"person": {"firstName": "Guillaume", "lastName": "Laforge", "conferences": ["JavaOne", "Gr8conf"]}}'
+}</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>In case of overlapping keys in the map and the closure, the closure wins – a visual clue for this rule is that the closure appears "after" the map key/value pairs.</p>
+</div>
+<div class="paragraph">
+<p>Consuming JSON
+The proposal is for the creation of a JsonSlurper class that can read JSON from a string (in a non-streaming fashion) and produce a hierarchy of maps and lists representing the JSON objects and arrays respectively.</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>String json = '{"person": {"firstName": "Guillaume", "lastName": "Laforge", "conferences": ["JavaOne", "Gr8conf"]}}'
def root = new JsonSlurper().parseText(json)
assert root instanceof Map
assert root.person.conferences instanceof List
assert root.person.firstName == 'Guillaume'
-assert root.person.conferences[1] == 'Gr8conf'
-```
-JsonSlurper's API should mirror closely what XmlParser/XmlSlurper offers in terms of its parse* method variants.
-
-== References and useful links
-
-JSON Spec and Java implementations
-
-* http://json.org/[json.org]
-* http://tools.ietf.org/html/rfc4627[RFC-4627]
-* http://json-lib.sourceforge.net/[json-lib]
-
-=== Mailing-list discussions
-
-* https://marc.info/?l=groovy-dev&m=129623197505984&w=2[groovy-dev: Built-in JSON support in 1.8]
-
-=== JIRA issues
-
-* https://issues.apache.org/jira/browse/GROOVY-4644[GROOVY-4644: JSON support: provide a parser and a builder for JSON content]
-
-== Update history
-
-3 (2011-02-02):: Version as extracted from Codehaus wiki
-4 (2018-10-16):: Numerous minor tweaks
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-7</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-7</h1><hr/></div></div></div></div><footer id='footer'>
+assert root.person.conferences[1] == 'Gr8conf'</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>JsonSlurper’s API should mirror closely what XmlParser/XmlSlurper offers in terms of its parse* method variants.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>JSON Spec and Java implementations</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="http://json.org/">json.org</a></p>
+</li>
+<li>
+<p><a href="http://tools.ietf.org/html/rfc4627">RFC-4627</a></p>
+</li>
+<li>
+<p><a href="http://json-lib.sourceforge.net/">json-lib</a></p>
+</li>
+</ul>
+</div>
+<div class="sect2">
+<h3 id="_mailing_list_discussions">Mailing-list discussions</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://marc.info/?l=groovy-dev&m=129623197505984&w=2">groovy-dev: Built-in JSON support in 1.8</a></p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_jira_issues">JIRA issues</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-4644">GROOVY-4644: JSON support: provide a parser and a builder for JSON content</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">3 (2011-02-02)</dt>
+<dd>
+<p>Version as extracted from Codehaus wiki</p>
+</dd>
+<dt class="hdlist1">4 (2018-10-16)</dt>
+<dd>
+<p>Numerous minor tweaks</p>
+</dd>
+</dl>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-8.html b/wiki/GEP-8.html
index 8722f7a..a2f6407 100644
--- a/wiki/GEP-8.html
+++ b/wiki/GEP-8.html
@@ -59,43 +59,130 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-8: Static type checking
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-8
-*Title*:: Static type checking
-*Version*:: 9
-*Type*:: Feature
-*Status*:: Final
-*Comment*:: Delivered in Groovy 2.0 and enhanced in later versions
-*Leader*:: Cédric Champeau
-*Created*:: 2011-10-08
-*Last modification* :: 2018-10-12
-****
-
-== Abstract: Static Type Checking
-
-This GEP introduces a new feature in the language known as static type checking.
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-8</a></li><li><a href='#_abstract_static_type_checking' class='anchor-link'>Abstract: Static Type Checking</a></li><li><a href='#_rationale_static_type_checking_vs_static_compilation' class='anchor-link'>Rationale: Static Type Checking vs Static compilation</a></li><li><a href='#_references_and_useful_li [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-8</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>Static type checking</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>9</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Final</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Comment</strong>
+</td>
+<td class="hdlist2">
+<p>Delivered in Groovy 2.0 and enhanced in later versions</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Cédric Champeau</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2011-10-08</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2018-10-12</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract_static_type_checking">Abstract: Static Type Checking</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>This GEP introduces a new feature in the language known as static type checking.
It is often disturbing for developers coming from a statically typed language (say Java)
-to discover that the Groovy compiler will not complain at compile time:
-
-* when assignments are made on different types
-* when a method doesn't exist
-* when a property or variable doesn't exist
-* when returned object type doesn't match the method signature
-* ...
-
-All those are silent because the dynamic nature of the Groovy language makes such code perfectly valid.
+to discover that the Groovy compiler will not complain at compile time:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>when assignments are made on different types</p>
+</li>
+<li>
+<p>when a method doesn’t exist</p>
+</li>
+<li>
+<p>when a property or variable doesn’t exist</p>
+</li>
+<li>
+<p>when returned object type doesn’t match the method signature</p>
+</li>
+<li>
+<p>…​</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>All those are silent because the dynamic nature of the Groovy language makes such code perfectly valid.
However, in some situations, a developer may want Groovy to behave like a statically typed language
-and have the compiler give hints about such "errors". To do this, Groovy must introduce static type checking.
-
-== Rationale: Static Type Checking vs Static compilation
-
-It is important to make the difference between static type checking and static compilation.
+and have the compiler give hints about such "errors". To do this, Groovy must introduce static type checking.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_rationale_static_type_checking_vs_static_compilation">Rationale: Static Type Checking vs Static compilation</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>It is important to make the difference between static type checking and static compilation.
The goal of this GEP is to have an option to turn static type checking (STC) on.
If STC is activated, the compiler will be more verbose (you will also see the term "grumpy"),
but in the end, the generated bytecode and runtime behaviour will be exactly the same as if you
@@ -104,232 +191,388 @@ which will perform STC then produce a different bytecode and therefore produce d
The scope of this GEP is only a static type checker, and therefore should only be considered as a
feature which allows developers to write statically checked code, so is an elegant way for example
to leverage the Groovy syntax to reduce verbosity of Java code while still getting strongly checked code.
-Eventually, IDE could support the STC mode and provide information to the developer.
-
-=== Implementation details
-
-==== Development branch
-
-Since Groovy 2.0-beta-2, code has been merged into master branch. However, if heavy developments are
+Eventually, IDE could support the STC mode and provide information to the developer.</p>
+</div>
+<div class="sect2">
+<h3 id="_implementation_details">Implementation details</h3>
+<div class="sect3">
+<h4 id="_development_branch">Development branch</h4>
+<div class="paragraph">
+<p>Since Groovy 2.0-beta-2, code has been merged into master branch. However, if heavy developments are
done on the type checker, it is advisable to work on the grumpy branch. It adds an AST transformation
named TypeChecked. If set, then the AST transformation will perform type inference and store type
information in AST nodes metadata. Eventually, if errors are found, it will add errors to the compiler
through a dedicated addStaticTypeError method which basically does the same as the traditional
addError method but prefixes the messages with a "Static type checking" message.
This is done to help the developer determine whether the error they are seeing is a "plain Groovy" error,
-or an error thrown by the STC mode.
-
-==== The StaticTypeCheckingTestCase class
-
-Static type checking behaviour must be tested. As there are tons of possible checks to be done,
+or an error thrown by the STC mode.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_the_statictypecheckingtestcase_class">The StaticTypeCheckingTestCase class</h4>
+<div class="paragraph">
+<p>Static type checking behaviour must be tested. As there are tons of possible checks to be done,
a base test class provides a framework for testing this mode.
-Unit tests for static type checking should override this class.
-
-=== Decisions made
-
-==== About this section
-
-The goal of this section is to provide code samples which demonstrates in what case the STC transformation
+Unit tests for static type checking should override this class.</p>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_decisions_made">Decisions made</h3>
+<div class="sect3">
+<h4 id="_about_this_section">About this section</h4>
+<div class="paragraph">
+<p>The goal of this section is to provide code samples which demonstrates in what case the STC transformation
will actually complain and what is the expected error message, and serves as a basis to future STC documentation.
This section may not be up-to-date, and one should always take a look at the STC unit tests found in the
-`src/test/groovy/transform/stc` directory.
-
-[options="header"]
-|===
-| Feature | Example | Behavior | Status
-| Method does not exist a|
-----
-def method() {
+<code>src/test/groovy/transform/stc</code> directory.</p>
+</div>
+<table class="tableblock frame-all grid-all stretch">
+<colgroup>
+<col style="width: 25%;">
+<col style="width: 25%;">
+<col style="width: 25%;">
+<col style="width: 25%;">
+</colgroup>
+<thead>
+<tr>
+<th class="tableblock halign-left valign-top">Feature</th>
+<th class="tableblock halign-left valign-top">Example</th>
+<th class="tableblock halign-left valign-top">Behavior</th>
+<th class="tableblock halign-left valign-top">Status</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Method does not exist</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>def method() {
...
}
-methode() // typo
-----
-| Complains about undefined method | Implemented
-| Property does not exist a|
-----
-class A {
+methode() // typo</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Complains about undefined method</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Property does not exist</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>class A {
int x
}
A obj = new A()
-a.y = 2
-----
-| Complains about undefined property "y" | Implemented
-| Assignment type checking a|
-----
-int x = 2
-x = 'String'
-----
-| Assigning a String to an int is forbidden | Implemented
-| Incompatible binary expressions a|
-----
-1 + 'string'
-----
-| Checks that arguments of a binary expression are compatible (here, no 'plus' method is available | Implemented
-| Possible loss of precision (1/2) a|
-----
-long myLong = ...
-int myInt = myLong
-----
-| Complains about possible loss of precision | Implemented
-| Possible loss of precision (2/2) a|
-----
-int myInt = 2L
-----
-| Will not complain because '2' can be represented as an int | Implemented
-| Arrays components a|
-----
-String[] arr = { '1', '2', '3' }
-arr[2] = 200
-----
-| Cannot assign an int value in an array of type String[] | Implemented
-| Method return type check a|
-----
-String method() { 'Hello' }
-int x = method() // return types don't match
-----
-| Ensures that assignments are compatible with method return type | Implemented
-| Explicit return type checking a|
-----
-int method() {
+a.y = 2</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Complains about undefined property "y"</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Assignment type checking</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>int x = 2
+x = 'String'</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Assigning a String to an int is forbidden</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Incompatible binary expressions</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>1 + 'string'</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Checks that arguments of a binary expression are compatible (here, no 'plus' method is available</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Possible loss of precision (1/2)</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>long myLong = ...
+int myInt = myLong</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Complains about possible loss of precision</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Possible loss of precision (2/2)</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>int myInt = 2L</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Will not complain because '2' can be represented as an int</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Arrays components</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>String[] arr = { '1', '2', '3' }
+arr[2] = 200</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Cannot assign an int value in an array of type String[]</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Method return type check</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>String method() { 'Hello' }
+int x = method() // return types don't match</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Ensures that assignments are compatible with method return type</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Explicit return type checking</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>int method() {
return 'String' // return type is not compatible
-}
-----
-| Ensures that returned value is compatible with declared return type | Implemented
-| Implicit return type checking a|
-----
-int method() {
+}</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Ensures that returned value is compatible with declared return type</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implicit return type checking</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>int method() {
'String' // return type is not compatible
-}
-----
-| Ensures that returned value is compatible with declared return type | Implemented
-| Implicit toString() a|
-----
-String method(String name) {
+}</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Ensures that returned value is compatible with declared return type</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implicit toString()</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>String method(String name) {
StringBuilder sb = new StringBuilder()
- sb 'Hi ' << name << '!'
-}
-----
-| Implicit call to toString() | Implemented
-| Basic type inference a|
-----
-def str = 'My string'
-str.toUpperCase() // type of 'str' is inferred
-----
-| Method calls as well as property access are checked against inferred type | Implemented
-| Basic flow analysis a|
-----
-def o
+ sb 'Hi ' << name << '!'
+}</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implicit call to toString()</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Basic type inference</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>def str = 'My string'
+str.toUpperCase() // type of 'str' is inferred</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Method calls as well as property access are checked against inferred type</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Basic flow analysis</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>def o
...
if (o instanceof String) {
o.toUpperCase() // no explicit cast required
-}
-----
-| Casts should not be necessary when type can be inferred from a previous instanceof check | Implemented
-| DefaultGroovyMethods support a|
-----
-'123'.toInteger() // toInteger() is a Groovy extension method
-----
-| Method calls can be resolved against Groovy extension methods | Implemented
-| with a|
-----
-class A {
+}</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Casts should not be necessary when type can be inferred from a previous instanceof check</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">DefaultGroovyMethods support</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>'123'.toInteger() // toInteger() is a Groovy extension method</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Method calls can be resolved against Groovy extension methods</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">with</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>class A {
int x
}
def a = new A()
a.with {
x = 1
-}
-----
-| Method calls can be resolved against Groovy extension methods | Implemented
-| Categories a|
-----
-use (MyStringCategory) {
+}</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Method calls can be resolved against Groovy extension methods</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Categories</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>use (MyStringCategory) {
'string'.methodInStringCategory()
-}
-----
-| Compiler should be aware that extension method is found in a category | *N/A* (support will be limited as category support is inherently dynamic)
-| Groovy list constructor a|
-----
-Dimension d = [100, 200]
-----
-| Type checks the arguments and the number of arguments | Implemented
-| Groovy map constructor a|
-----
-Bean myBean = [x: 100, y: 200]
-----
-| Type checks the properties and checks for incorrect property names | Implemented
-| Closure parameter types a|
-----
-def closure = { int x, int y -> x + y }
+}</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Compiler should be aware that extension method is found in a category</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><strong>N/A</strong> (support will be limited as category support is inherently dynamic)</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Groovy list constructor</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>Dimension d = [100, 200]</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Type checks the arguments and the number of arguments</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Groovy map constructor</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>Bean myBean = [x: 100, y: 200]</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Type checks the properties and checks for incorrect property names</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Closure parameter types</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>def closure = { int x, int y -> x + y }
closure(1, 2)
-closure('1', '2') // complains
-----
-| Type checking the arguments when calling a closure | Implemented
-| Closure return type inference a|
-----
-def closure = { int x, int y -> x + y }
-int sum = closure(1, 2)
-----
-| Closure return type can be inferred from block | Implemented
-| Method return type inference a|
-----
-def method(int x, int y) { x + y }
-int sum = method(1, 2)
-----
-| Return type can be inferred from a method if the method is itself annotated with @TypeChecked (or class is annotated with @TypeChecked) | Implemented
-| Multiple assignments a|
-----
-def (x, y) = [1, 2]
-----
-| In case of inline declaration, type check arguments | Implemented
-| Multiple assignments from a variable a|
-----
-def (x, y) = list
-----
-| In case of inline declaration, type check arguments | Implemented
-| Generics a|
-----
-List<String> list = []
-List<String> list = ['a', 'b', 'c']
-List<String> list = [1, 2, 3] // should throw error
-----
-| Type checking of generic parameters | Implemented
-| Spread operator a|
-----
-def list = ['a', 'b', 'c']
-list*.toUpperCase()
-----
-| Type checking against component type | Implemented
-| Closure shared variables a|
-----
-def x = new Date()
+closure('1', '2') // complains</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Type checking the arguments when calling a closure</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Closure return type inference</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>def closure = { int x, int y -> x + y }
+int sum = closure(1, 2)</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Closure return type can be inferred from block</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Method return type inference</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>def method(int x, int y) { x + y }
+int sum = method(1, 2)</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Return type can be inferred from a method if the method is itself annotated with @TypeChecked (or class is annotated with @TypeChecked)</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Multiple assignments</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>def (x, y) = [1, 2]</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">In case of inline declaration, type check arguments</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Multiple assignments from a variable</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>def (x, y) = list</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">In case of inline declaration, type check arguments</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Generics</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>List<String> list = []
+List<String> list = ['a', 'b', 'c']
+List<String> list = [1, 2, 3] // should throw error</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Type checking of generic parameters</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Spread operator</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>def list = ['a', 'b', 'c']
+list*.toUpperCase()</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Type checking against component type</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Closure shared variables</p></td>
+<td class="tableblock halign-left valign-top"><div class="content"><div class="listingblock">
+<div class="content">
+<pre>def x = new Date()
def cl = { x = 'hello' }
cl()
-x.toUpperCase() // should throw an error because the toUpperCase() method doesn't belong to both Date and String classes
-----
-| Type check assignments of closure shared variables. The type checker is required to perform a two-pass verification,
-in order to check that method calls on a closure shared variables belong to the lowest upper bound of all assignment types. | Implemented
-|===
-
-=== Open discussions
-
-==== Closure parameter type inference
-
-With the current version of the checker, idiomatic constructs like :
-
-```
-['a','b','c'].collect { it.toUpperCase() }
-```
-
-Are not properly recognized. You have to explicitly set the type of the "it" parameter inside the closure.
+x.toUpperCase() // should throw an error because the toUpperCase() method doesn't belong to both Date and String classes</pre>
+</div>
+</div></div></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Type check assignments of closure shared variables. The type checker is required to perform a two-pass verification,
+in order to check that method calls on a closure shared variables belong to the lowest upper bound of all assignment types.</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Implemented</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_open_discussions">Open discussions</h3>
+<div class="sect3">
+<h4 id="_closure_parameter_type_inference">Closure parameter type inference</h4>
+<div class="paragraph">
+<p>With the current version of the checker, idiomatic constructs like :</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>['a','b','c'].collect { it.toUpperCase() }</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Are not properly recognized. You have to explicitly set the type of the "it" parameter inside the closure.
It is because the expected parameter types of closures are unknown at compile time.
There is a discussion about how to add this type information to source code so that the inference
engine can deal with them properly. The implementation of closure parameter type inference requires
-a change to the method signatures. It will probably not belong to the initial release of the type checker.
-
-==== Unification Types
-
-In cases of for example `x instanceof A || x instanceof B` with A and B being unrelated we could
+a change to the method signatures. It will probably not belong to the initial release of the type checker.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="_unification_types">Unification Types</h4>
+<div class="paragraph">
+<p>In cases of for example <code>x instanceof A || x instanceof B</code> with A and B being unrelated we could
still make an artificial union kind of type, that contains everything present in A and B,
to allow those kinds of method calls. The alternative to this is to allow only methods from Object here,
which is less interesting. This typing can also be used for multicatch, ensuring that a method call is
@@ -337,29 +580,73 @@ only valid if it exists on each of the exceptions for the multicatch.
In the current implementation (2011-10-14) the multicatch is already expanded at the point @TypeChecked will check.
Meaning effectively this already represents a kind of union type, as the same code is in each catch block
and thus the method call would fail, if the method is not available on each type.
-The proposed behaviour is therefore to align the instanceof case with multicatch.
-
-== References and useful links
-
-* https://web.archive.org/web/20150508041021/http://docs.codehaus.org/display/GroovyJSR/GEP+8+-+Static+type+checking[GEP-8: Static type checking] (web archive link with comments)
-* http://blackdragsview.blogspot.com/2011/10/flow-sensitive-typing.html[Flow Sensitive Typing?]
-* https://web.archive.org/web/20150508040745/http://www.jroller.com/melix/entry/groovy_static_type_checker_status[Groovy static type checker: status update] (web archive)
-
-=== Mailing-list discussions
-
-* https://marc.info/?l=groovy-user&m=131805623302039&w=2[groovy-user: [grumpy mode\] What to do on assignment?] Discussion about the expected behaviour when STC detects a potential error on assignment (for example, possible loss of precision on implicit number casts)
-
-=== JIRA issues
-
-* https://issues.apache.org/jira/browse/GROOVY-5073[GROOVY-5073: GEP-8 - Static type checking]
-* https://issues.apache.org/jira/browse/GROOVY-3014[GROOVY-3014: add an annotation that forces the compiler to check methods for their existence at compile time]
-* https://issues.apache.org/jira/browse/GROOVY-5081[GROOVY-5081: Handle explicit and implicit returns]
-
-== Update history
-
-8 (2012-02-21):: Version as extracted from Codehaus wiki
-9 (2018-10-16):: Numerous minor tweaks
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-8</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-8</h1><hr/></div></div></div></div><footer id='footer'>
+The proposed behaviour is therefore to align the instanceof case with multicatch.</p>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://web.archive.org/web/20150508041021/http://docs.codehaus.org/display/GroovyJSR/GEP+8+-+Static+type+checking">GEP-8: Static type checking</a> (web archive link with comments)</p>
+</li>
+<li>
+<p><a href="http://blackdragsview.blogspot.com/2011/10/flow-sensitive-typing.html">Flow Sensitive Typing?</a></p>
+</li>
+<li>
+<p><a href="https://web.archive.org/web/20150508040745/http://www.jroller.com/melix/entry/groovy_static_type_checker_status">Groovy static type checker: status update</a> (web archive)</p>
+</li>
+</ul>
+</div>
+<div class="sect2">
+<h3 id="_mailing_list_discussions">Mailing-list discussions</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://marc.info/?l=groovy-user&m=131805623302039&w=2">groovy-user: [grumpy mode] What to do on assignment?</a> Discussion about the expected behaviour when STC detects a potential error on assignment (for example, possible loss of precision on implicit number casts)</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_jira_issues">JIRA issues</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-5073">GROOVY-5073: GEP-8 - Static type checking</a></p>
+</li>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-3014">GROOVY-3014: add an annotation that forces the compiler to check methods for their existence at compile time</a></p>
+</li>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-5081">GROOVY-5081: Handle explicit and implicit returns</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">8 (2012-02-21)</dt>
+<dd>
+<p>Version as extracted from Codehaus wiki</p>
+</dd>
+<dt class="hdlist1">9 (2018-10-16)</dt>
+<dd>
+<p>Numerous minor tweaks</p>
+</dd>
+</dl>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/GEP-9.html b/wiki/GEP-9.html
index c1b1810..25d7e9f 100644
--- a/wiki/GEP-9.html
+++ b/wiki/GEP-9.html
@@ -59,190 +59,448 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= GEP-9: Modularization
-
-:icons: font
-
-.Metadata
-****
-[horizontal,options="compact"]
-*Number*:: GEP-9
-*Title*:: Modularization
-*Version*:: 5
-*Type*:: Feature
-*Status*:: Final
-*Comment*:: Parts incorporated in Groovy 2.0
-*Leader*:: Paul King
-*Created*:: 2011-10-26
-*Last modification* :: 2018-10-24
-****
-
-== Abstract: Modularization
-
-This GEP introduces the goals and proposed details behind a modularization effort that will:
-
-* provide a more streamlined jar for core Groovy with other jars comprising what might be considered optional parts of Groovy
-* provide Groovy library writers with hooks into the groovy runtime to allow them to extend Groovy in various ways - allowing "grapes" to be more like plugins than just traditional libraries
-* auxiliary details about how the modularization might affect other artifacts, e.g. the Groovy build, wiki, jira components, etc.
-
-This activity builds upon the work discussed previously: Groovy 2.0 modularization and the somewhat older profiles discussion Packaging and Modularity.
-
-=== Out of scope
-
-While we should keep a watching brief on other modularization efforts, at this stage we are anticipating structural
-changes to the Groovy classes which are orthogonal to eventually using something like OSGi or Java 8's Jigsaw modularization.
-
-=== Jar groupings
-
-At the moment, Groovy provides two main jar artifacts:
-
-* groovy.jar contains the core classes for Groovy and has a dependency on a small handful of critical dependent jars (i.e. asm, antlr, etc.)
-* groovy-all.jar contains the core classes for Groovy and bundled versions of the critical dependent jars
-
-After modularization, the main Groovy codebase will be packaged into additional jar artifacts:
-
-* groovy.jar or groovy-core.jar (name to be finalized) will contain a smaller set of core classes for Groovy and will retain its dependency on a small handful of critical dependent jars (i.e. asm, antlr, etc.)
-* numerous smaller "module/component" jars (exact names/numbers/contents to be finalized) but possibly things like groovy-bsf.jar, groovy-sql.jar, groovy-swing.jar, groovy-jmx.jar, groovy-xml, groovy-tools etc.
-* groovy-all.jar contains the core classes for Groovy, bundled versions of the critical dependent jars and all the classes from the module jars
-* optionally we may support other "profiles" - profiles being other "fat" jars we bundle together for other environments, e.g. groovy-android.jar might exclude the JMX or Swing modules for instance.
-
-Recommendations/suggestions for jar groupings are welcome. See some more details in the accompanying discussion: Groovy 2.0 modularization.
-
-One of the goals of this bundling effort is to facilitate Groovy's evolution as a language by enabling:
-
-* less relevant modules to become deprecated and removed from the main project but still available as external libraries, e.g. groovy-bsf might be deemed inessential now that most users will have jsr-223 (but it can be moved into a separate module and still available for anyone who needs it)
-* the controlled migration from legacy to new versions of some functionality, e.g. we could produce a groovy-xml-v2 library which might have breaking changes - the v2 library might be an optional module at first but later become the main supported option - legacy users would be able to "point back to the old version" so that their scripts don't break if they wished (further details later)
-* external modules could more easily be incorporated into the core distribution (with users able to customize certain aspects of what gets bundled)
-* we can provide "legacy" jars which contain deprecated features or unforeseen breaking changes - library writers can incorporate the legacy jar into their libraries to more easily support using their libraries across multiple versions of Groovy
-
-=== Configuring a Groovy installation
-
-Groovy bootstraps its configuration using a file in the conf/groovy-starter.conf file. It has entries like this:
-
-```
-# load required libraries
-load !{groovy.home}/lib/*.jar
-```
-
-with required jars being in a lib directory which is part of a Groovy install.
-
-The groovy install will now likely have a "modules" (or components or repository) directory.
-The groovy-starter.conf file will have additional entries such as:
-
-```
-# load SQL component
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-9</a></li><li><a href='#_abstract_modularization' class='anchor-link'>Abstract: Modularization</a></li><li><a href='#_references_and_useful_links' class='anchor-link'>References and useful links</a></li><li><a href='#_update_history' class='anchor-link'>Update history</a></li></ul></div><div class='col-l [...]
+<div class="sectionbody">
+<div class="sidebarblock">
+<div class="content">
+<div class="title">Metadata</div>
+<div class="hdlist">
+<table>
+<tr>
+<td class="hdlist1">
+<strong>Number</strong>
+</td>
+<td class="hdlist2">
+<p>GEP-9</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Title</strong>
+</td>
+<td class="hdlist2">
+<p>Modularization</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Version</strong>
+</td>
+<td class="hdlist2">
+<p>5</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Type</strong>
+</td>
+<td class="hdlist2">
+<p>Feature</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Status</strong>
+</td>
+<td class="hdlist2">
+<p>Final</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Comment</strong>
+</td>
+<td class="hdlist2">
+<p>Parts incorporated in Groovy 2.0</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Leader</strong>
+</td>
+<td class="hdlist2">
+<p>Paul King</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Created</strong>
+</td>
+<td class="hdlist2">
+<p>2011-10-26</p>
+</td>
+</tr>
+<tr>
+<td class="hdlist1">
+<strong>Last modification</strong> 
+</td>
+<td class="hdlist2">
+<p>2018-10-24</p>
+</td>
+</tr>
+</table>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_abstract_modularization">Abstract: Modularization</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>This GEP introduces the goals and proposed details behind a modularization effort that will:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>provide a more streamlined jar for core Groovy with other jars comprising what might be considered optional parts of Groovy</p>
+</li>
+<li>
+<p>provide Groovy library writers with hooks into the groovy runtime to allow them to extend Groovy in various ways - allowing "grapes" to be more like plugins than just traditional libraries</p>
+</li>
+<li>
+<p>auxiliary details about how the modularization might affect other artifacts, e.g. the Groovy build, wiki, jira components, etc.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>This activity builds upon the work discussed previously: Groovy 2.0 modularization and the somewhat older profiles discussion Packaging and Modularity.</p>
+</div>
+<div class="sect2">
+<h3 id="_out_of_scope">Out of scope</h3>
+<div class="paragraph">
+<p>While we should keep a watching brief on other modularization efforts, at this stage we are anticipating structural
+changes to the Groovy classes which are orthogonal to eventually using something like OSGi or Java 8’s Jigsaw modularization.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_jar_groupings">Jar groupings</h3>
+<div class="paragraph">
+<p>At the moment, Groovy provides two main jar artifacts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>groovy.jar contains the core classes for Groovy and has a dependency on a small handful of critical dependent jars (i.e. asm, antlr, etc.)</p>
+</li>
+<li>
+<p>groovy-all.jar contains the core classes for Groovy and bundled versions of the critical dependent jars</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>After modularization, the main Groovy codebase will be packaged into additional jar artifacts:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>groovy.jar or groovy-core.jar (name to be finalized) will contain a smaller set of core classes for Groovy and will retain its dependency on a small handful of critical dependent jars (i.e. asm, antlr, etc.)</p>
+</li>
+<li>
+<p>numerous smaller "module/component" jars (exact names/numbers/contents to be finalized) but possibly things like groovy-bsf.jar, groovy-sql.jar, groovy-swing.jar, groovy-jmx.jar, groovy-xml, groovy-tools etc.</p>
+</li>
+<li>
+<p>groovy-all.jar contains the core classes for Groovy, bundled versions of the critical dependent jars and all the classes from the module jars</p>
+</li>
+<li>
+<p>optionally we may support other "profiles" - profiles being other "fat" jars we bundle together for other environments, e.g. groovy-android.jar might exclude the JMX or Swing modules for instance.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Recommendations/suggestions for jar groupings are welcome. See some more details in the accompanying discussion: Groovy 2.0 modularization.</p>
+</div>
+<div class="paragraph">
+<p>One of the goals of this bundling effort is to facilitate Groovy’s evolution as a language by enabling:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>less relevant modules to become deprecated and removed from the main project but still available as external libraries, e.g. groovy-bsf might be deemed inessential now that most users will have jsr-223 (but it can be moved into a separate module and still available for anyone who needs it)</p>
+</li>
+<li>
+<p>the controlled migration from legacy to new versions of some functionality, e.g. we could produce a groovy-xml-v2 library which might have breaking changes - the v2 library might be an optional module at first but later become the main supported option - legacy users would be able to "point back to the old version" so that their scripts don’t break if they wished (further details later)</p>
+</li>
+<li>
+<p>external modules could more easily be incorporated into the core distribution (with users able to customize certain aspects of what gets bundled)</p>
+</li>
+<li>
+<p>we can provide "legacy" jars which contain deprecated features or unforeseen breaking changes - library writers can incorporate the legacy jar into their libraries to more easily support using their libraries across multiple versions of Groovy</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_configuring_a_groovy_installation">Configuring a Groovy installation</h3>
+<div class="paragraph">
+<p>Groovy bootstraps its configuration using a file in the conf/groovy-starter.conf file. It has entries like this:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code># load required libraries
+load !{groovy.home}/lib/*.jar</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>with required jars being in a lib directory which is part of a Groovy install.</p>
+</div>
+<div class="paragraph">
+<p>The groovy install will now likely have a "modules" (or components or repository) directory.
+The groovy-starter.conf file will have additional entries such as:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code># load SQL component
grab org.codehaus.groovy groovy-sql 1.9.0
# load XML component
-grab org.codehaus.groovy groovy-xml 1.9.0
-```
-
-Grapes are loaded via Ivy and configured from a settings file. This file might have an additional entry:
-
-```
-<ibiblio name="modules" root="file:${groovy.home}/modules/" m2compatible="true"/>
-```
-
-The Ivy library (or perhaps the wharf or aether libraries) will likely become a required jar - though it may be
-that only a very limited form of grab is supported in which case no additional library might be necessary.
-
-=== Runtime hooks/registration
-
-When downloading a grape, the classes from its jar are added (currently appended) to the classpath.
-In addition, we are planning on supporting additional integration points:
-
-[options="header"]
-|===
-| potential hook | purpose | status
-m| META-INF/services/ +
-org.codehaus.groovy.runtime.CategoryMethods | allow the module to define additional category methods | now in `META-INF/groovy/ +
- org.codehaus.groovy.runtime.ExtensionModuleSpec`
-m| META-INF/services/ +
-org.codehaus.groovy.runtime.StaticCategoryMethods | allow the module to define additional static category methods | now in `META-INF/groovy/ +
- org.codehaus.groovy.runtime.ExtensionModuleSpec`
-m| META-INF/services/ +
-org.codehaus.groovy.runtime.SerializedCategoryMethods | allow the module to define additional category methods which have been serialized | deferred
-m| META-INF/services/ +
-org.codehaus.groovy.runtime.ExpandoMethods | allow the module to define additional ExpandoMetaClass methods | deferred
-m| META-INF/services/ +
-org.codehaus.groovy.runtime.DefaultMetaClasses | allow the module to define additional metaclasses similar to the current magic package mechanism footnote:[This needs to mesh in with the existing magic package mechanism for defining custom metaclasses.] | deferred
-m| META-INF/services/groovy/defaultImports | allow the module to define additional normal, star, static imports, aliases | moved to compiler configuration
-m| META-INF/services/groovy/defaultExtensions | allow the module to define supported file extensions | moved to compiler configuration
-m| META-INF/services/groovy/defaultAstTransforms | allow the module to define AST transforms | now in `META-INF/services/ +
- org.codehaus.groovy.transform.ASTTransformation`
-| ? | provide a way to register builder metadata | deferred
-| ? | should there be a way to 'publish' new commandline level startup scripts e.g. java2groovy | deferred
-| ? | provide a way to register a runner class, e.g. EasyB - there might also be a need to detect runner types | now in `META-INF/groovy/ +
- org.apache.groovy.plugin.GroovyRunner`
-| ? | provide a way to register special compiler flags, e.g. '--indy' | deferred
-| ? | provide a way to inject special AST customizations | deferred
-|===
-
-This is also where we could specify additional requirements, e.g. require 'invoke dynamic' - but see later also. Could we declaratively specify our security policy requirements? Or can we disable specific aspects of functionality, e.g. disable some standard global AST transform because we want to provide a better one? (There are obviously security implications for this!)
-
-Another question is whether all these features will be available also via an API. Would such an API allow modules to be "unregistered"?
-
-=== Groovydoc/source pointers
-
-Some modularization systems support the "installation" of documentation (and/or sources) along with the module.
-Should a module have a pointer to (or be bundled with) its GroovyDoc and/or source.
-
-In the Java ecosystem, many libraries are published with their javadoc/sources according to common conventions or have javadoc available online. Do we rely on these established conventions or provide additional support? For users without access to sophisticated IDEs it could be convenient to have all the documentation available in "merged" form in one place.
-
-=== Runtime Introspection
-
-In Groovy you can currently determine the Groovy version using:
-
-```
-println GroovySystem.version
-```
-
-which returns a String.
-
-In GROOVY-2422 it talks about the desire for additional version checks.
-
-It also talks about listing capabilities. This could be "is invokeDynamic" available or could really just be about available loaded modules. In general, we would expect our dependencies to be specified as part of our pom and loaded for us automatically but it can sometimes be useful to do special things.
-
-In general, should we be able to find out the list of loaded modules and versions? Or ask about which module/version a particular class belongs to?
-
-=== Build Impacts
-
-Mostly discussed here: Groovy 2.0 modularization
-
-Should each "submodule" be able to be built on its own? Will it have its own javadoc, own coding style rules, own coverage metrics etc.
-
-=== Module robustness
-
-Should we provide a standard hook/mechanism to try to combat the following scenarios:
-
-* you are loading a jar that depends on classes managed by the root classloader?
-* a class with the same name is already on the classpath before yours?
-* a class with the same name as one of your dependencies but from an incompatible version is on the classpath already
-* an ability to register a "ping"/health check method to quickly test the component
-
-=== Assisting IDE support
-
-We may define a standard place or convention, e.g. META-INF/services/groovy/dsld or META-INF/services/groovy/gdsl where IDEs can find DSL descriptors relevant for that module.
-
-=== Logging
-
-Should modules themselves have a standard way to do logging? Is that j.u.l.Logger? Perhaps bridged with slf4j?
-
-== References and useful links
-
-=== Wiki pages (web archive)
-
-* https://web.archive.org/web/20150508040614/http://docs.codehaus.org/display/GROOVY/Groovy+2.0+modularization[Groovy 2.0 modularization]
-* https://web.archive.org/web/20150512231712/http://docs.codehaus.org/display/GroovyJSR/Packaging+and+Modularity[Packaging and Modularity]
-
-=== JIRA issues
-
-* https://issues.apache.org/jira/browse/GROOVY-2422[GROOVY-2422: API for checking version and capabilities of Groovy runtime]
-
-== Update history
-
-4 (2011-10-26):: Version as extracted from Codehaus wiki
-5 (2018-10-24):: Numerous minor tweaks
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>GEP-9</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>GEP-9</h1><hr/></div></div></div></div><footer id='footer'>
+grab org.codehaus.groovy groovy-xml 1.9.0</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Grapes are loaded via Ivy and configured from a settings file. This file might have an additional entry:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code><ibiblio name="modules" root="file:${groovy.home}/modules/" m2compatible="true"/></code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>The Ivy library (or perhaps the wharf or aether libraries) will likely become a required jar - though it may be
+that only a very limited form of grab is supported in which case no additional library might be necessary.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_runtime_hooksregistration">Runtime hooks/registration</h3>
+<div class="paragraph">
+<p>When downloading a grape, the classes from its jar are added (currently appended) to the classpath.
+In addition, we are planning on supporting additional integration points:</p>
+</div>
+<table class="tableblock frame-all grid-all stretch">
+<colgroup>
+<col style="width: 33.3333%;">
+<col style="width: 33.3333%;">
+<col style="width: 33.3334%;">
+</colgroup>
+<thead>
+<tr>
+<th class="tableblock halign-left valign-top">potential hook</th>
+<th class="tableblock halign-left valign-top">purpose</th>
+<th class="tableblock halign-left valign-top">status</th>
+</tr>
+</thead>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>META-INF/services/<br>
+org.codehaus.groovy.runtime.CategoryMethods</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">allow the module to define additional category methods</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">now in <code>META-INF/groovy/<br>
+ org.codehaus.groovy.runtime.ExtensionModuleSpec</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>META-INF/services/<br>
+org.codehaus.groovy.runtime.StaticCategoryMethods</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">allow the module to define additional static category methods</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">now in <code>META-INF/groovy/<br>
+ org.codehaus.groovy.runtime.ExtensionModuleSpec</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>META-INF/services/<br>
+org.codehaus.groovy.runtime.SerializedCategoryMethods</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">allow the module to define additional category methods which have been serialized</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">deferred</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>META-INF/services/<br>
+org.codehaus.groovy.runtime.ExpandoMethods</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">allow the module to define additional ExpandoMetaClass methods</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">deferred</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>META-INF/services/<br>
+org.codehaus.groovy.runtime.DefaultMetaClasses</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">allow the module to define additional metaclasses similar to the current magic package mechanism <sup class="footnote">[<a id="_footnoteref_1" class="footnote" href="#_footnotedef_1" title="View footnote.">1</a>]</sup></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">deferred</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>META-INF/services/groovy/defaultImports</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">allow the module to define additional normal, star, static imports, aliases</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">moved to compiler configuration</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>META-INF/services/groovy/defaultExtensions</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">allow the module to define supported file extensions</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">moved to compiler configuration</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><code>META-INF/services/groovy/defaultAstTransforms</code></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">allow the module to define AST transforms</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">now in <code>META-INF/services/<br>
+ org.codehaus.groovy.transform.ASTTransformation</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">?</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">provide a way to register builder metadata</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">deferred</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">?</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">should there be a way to 'publish' new commandline level startup scripts e.g. java2groovy</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">deferred</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">?</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">provide a way to register a runner class, e.g. EasyB - there might also be a need to detect runner types</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">now in <code>META-INF/groovy/<br>
+ org.apache.groovy.plugin.GroovyRunner</code></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">?</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">provide a way to register special compiler flags, e.g. '--indy'</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">deferred</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock">?</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">provide a way to inject special AST customizations</p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">deferred</p></td>
+</tr>
+</tbody>
+</table>
+<div class="paragraph">
+<p>This is also where we could specify additional requirements, e.g. require 'invoke dynamic' - but see later also. Could we declaratively specify our security policy requirements? Or can we disable specific aspects of functionality, e.g. disable some standard global AST transform because we want to provide a better one? (There are obviously security implications for this!)</p>
+</div>
+<div class="paragraph">
+<p>Another question is whether all these features will be available also via an API. Would such an API allow modules to be "unregistered"?</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_groovydocsource_pointers">Groovydoc/source pointers</h3>
+<div class="paragraph">
+<p>Some modularization systems support the "installation" of documentation (and/or sources) along with the module.
+Should a module have a pointer to (or be bundled with) its GroovyDoc and/or source.</p>
+</div>
+<div class="paragraph">
+<p>In the Java ecosystem, many libraries are published with their javadoc/sources according to common conventions or have javadoc available online. Do we rely on these established conventions or provide additional support? For users without access to sophisticated IDEs it could be convenient to have all the documentation available in "merged" form in one place.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_runtime_introspection">Runtime Introspection</h3>
+<div class="paragraph">
+<p>In Groovy you can currently determine the Groovy version using:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>println GroovySystem.version</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>which returns a String.</p>
+</div>
+<div class="paragraph">
+<p>In GROOVY-2422 it talks about the desire for additional version checks.</p>
+</div>
+<div class="paragraph">
+<p>It also talks about listing capabilities. This could be "is invokeDynamic" available or could really just be about available loaded modules. In general, we would expect our dependencies to be specified as part of our pom and loaded for us automatically but it can sometimes be useful to do special things.</p>
+</div>
+<div class="paragraph">
+<p>In general, should we be able to find out the list of loaded modules and versions? Or ask about which module/version a particular class belongs to?</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_build_impacts">Build Impacts</h3>
+<div class="paragraph">
+<p>Mostly discussed here: Groovy 2.0 modularization</p>
+</div>
+<div class="paragraph">
+<p>Should each "submodule" be able to be built on its own? Will it have its own javadoc, own coding style rules, own coverage metrics etc.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_module_robustness">Module robustness</h3>
+<div class="paragraph">
+<p>Should we provide a standard hook/mechanism to try to combat the following scenarios:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>you are loading a jar that depends on classes managed by the root classloader?</p>
+</li>
+<li>
+<p>a class with the same name is already on the classpath before yours?</p>
+</li>
+<li>
+<p>a class with the same name as one of your dependencies but from an incompatible version is on the classpath already</p>
+</li>
+<li>
+<p>an ability to register a "ping"/health check method to quickly test the component</p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_assisting_ide_support">Assisting IDE support</h3>
+<div class="paragraph">
+<p>We may define a standard place or convention, e.g. META-INF/services/groovy/dsld or META-INF/services/groovy/gdsl where IDEs can find DSL descriptors relevant for that module.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_logging">Logging</h3>
+<div class="paragraph">
+<p>Should modules themselves have a standard way to do logging? Is that j.u.l.Logger? Perhaps bridged with slf4j?</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_references_and_useful_links">References and useful links</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_wiki_pages_web_archive">Wiki pages (web archive)</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://web.archive.org/web/20150508040614/http://docs.codehaus.org/display/GROOVY/Groovy+2.0+modularization">Groovy 2.0 modularization</a></p>
+</li>
+<li>
+<p><a href="https://web.archive.org/web/20150512231712/http://docs.codehaus.org/display/GroovyJSR/Packaging+and+Modularity">Packaging and Modularity</a></p>
+</li>
+</ul>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_jira_issues">JIRA issues</h3>
+<div class="ulist">
+<ul>
+<li>
+<p><a href="https://issues.apache.org/jira/browse/GROOVY-2422">GROOVY-2422: API for checking version and capabilities of Groovy runtime</a></p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_history">Update history</h2>
+<div class="sectionbody">
+<div class="dlist">
+<dl>
+<dt class="hdlist1">4 (2011-10-26)</dt>
+<dd>
+<p>Version as extracted from Codehaus wiki</p>
+</dd>
+<dt class="hdlist1">5 (2018-10-24)</dt>
+<dd>
+<p>Numerous minor tweaks</p>
+</dd>
+</dl>
+</div>
+</div>
+</div>
+<div id="footnotes">
+<hr>
+<div class="footnote" id="_footnotedef_1">
+<a href="#_footnoteref_1">1</a>. This needs to mesh in with the existing magic package mechanism for defining custom metaclasses.
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/grails-proposal.html b/wiki/grails-proposal.html
index 2b6bd4a..a1465ef 100644
--- a/wiki/grails-proposal.html
+++ b/wiki/grails-proposal.html
@@ -59,199 +59,471 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= Grails Project Proposal
-
-== Abstract
-
-Grails is a powerful Groovy-based full-stack web application framework for the JVM built on top of Spring Boot.
-
-== Proposal
-
-Grails is a full-stack web application framework for the JVM. It is intended to be a high-productivity framework by following the "convention over configuration" paradigm, providing a stand-alone development environment and hiding much of the configuration detail from the developer. Grails has long been developed under an Apache License v2.0 under an open governance community management process.
-
-So far Grails has been a project mostly sponsored by a single company. It has become clear that the single vendor backed model previously used by Grails isn’t the best strategy to take it forward. We propose to bring the Grails community under the umbrella of the Apache Software Foundation with an initial goal that Grails core and its critical plugins are brought into the ASF (see more details in the “Initial Goals” section). We propose that the Groovy project act as the sponsoring organ [...]
-
-== Background
-
-Grails is a mature open source project. Work began in July 2005, with the 0.1 release on March 29, 2006, and the 1.0 release announced on February 18, 2008. Recent releases include 6.2.3 (Jan 2025) and pre-release 7.0.0-M1 (Dec 2024) . After 19 years of development, Grails has grown into a powerful web application framework which leverages many of the latest technologies for building web applications on the JVM.
-
-Numerous vendors have consulting businesses based on building web applications using Grails. Other organizations use Grails for their internal web application development. While the Grails community is large, the project itself is also large. The existing model of expecting a single vendor to do the bulk of its maintenance is no longer viable. Moving to the ASF provides a vendor neutral home where all community members can feel safe contributing to Grails.
-
-== Rationale
-
-Many modern web frameworks in the Java space are more complicated than needed and don’t embrace the Don’t Repeat Yourself (DRY) principles.
-Dynamic frameworks like Rails and Django helped pave the way to a more modern way of thinking about web applications. Grails builds on these concepts and dramatically reduces the complexity of building web applications on the Java platform. What makes it different, however, is that it does so by building on already established Java technologies.
-
-== Initial Goals
-
-The initial goals of the Grails transition to the ASF are:
-
-* To establish a new home for an already fully functioning project in a setting which is welcoming for multiple vendors and individuals alike.
-* While many Grails contributors have a long-time open source history and experience, not all are familiar with ASF governance practices. So, another goal will be to mentor and educate those involved if/as needed.
-* As Grails has evolved, it has been split into small manageable pieces. This has made it easy to release parts individually but has made it harder to move the entire ecosystem across large changes (e.g. there have sometimes been circular dependencies). Also, because of Grails’ longevity, there is a rich ecosystem of plugins, but numerous plugins are out of date. So, a goal of this transition will be to bring across a fresh version of all of the critical Grails plugins. This has been dub [...]
-* Since Spring Boot is now released every 6 months with only 12 months of OSS support per release, a Grails release will need to be released within 6 months of each Boot release to maintain Spring OSS support. Given the need for more frequent Grails releases due to Spring Boot, we will make an effort to reduce complexity and technical debt such that Grails releases take less effort with each release.
-
-== Current Status
-
-Currently, Grails provides a fully functional implementation licensed under ALv2. The project home is at https://grails.org/ and the majority of development is coordinated under various repos on GitHub at https://github.com/grails/. The project sports a very mature documentation and ecosystem of projects leveraging it.
-
-== Meritocracy
-
-Grails, up to now, has been run by a few core project members with a lot of contributions coming from a wide community of participants in the project.
-We want to expand our diverse developer and user community and run the Grails project in the Apache way clearly signaling not only the licensing, but also the governance choice.
-
-Users and new contributors will be treated with respect and welcomed; they will earn merit in the project by providing quality patches and support that move the project forward.
-Those with a proven support and quality patch track record will be encouraged to become committers.
-
-== Community
-
-There are just a few core team members with over a hundred contributors to the project. If Grails is accepted into the ASF, transitioning the community to embrace the Apache Way of governance would be a primary initial goal. We would solicit major existing contributors to become committers on the project from the get go.
-
-== Core Developers
-Core developers include folks who are extremely skilled in working in the openly governed communities on code bases licensed under the ALv2. The core developers are NOT currently affiliated with the ASF, although quite a few contributors are.
-
-== Alignment
-
-Grails is highly aligned with the Groovy project with many of the DSLs used within Grails being drivers for the requirements of DSL support within Groovy.
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>Grails Project Proposal</a></li><li><a href='#_abstract' class='anchor-link'>Abstract</a></li><li><a href='#_proposal' class='anchor-link'>Proposal</a></li><li><a href='#_background' class='anchor-link'>Background</a></li><li><a href='#_rationale' class='anchor-link'>Rationale</a></li><li><a href='#_initial_ [...]
+<h2 id="_abstract">Abstract</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Grails is a powerful Groovy-based full-stack web application framework for the JVM built on top of Spring Boot.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_proposal">Proposal</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Grails is a full-stack web application framework for the JVM. It is intended to be a high-productivity framework by following the "convention over configuration" paradigm, providing a stand-alone development environment and hiding much of the configuration detail from the developer. Grails has long been developed under an Apache License v2.0 under an open governance community management process.</p>
+</div>
+<div class="paragraph">
+<p>So far Grails has been a project mostly sponsored by a single company. It has become clear that the single vendor backed model previously used by Grails isn’t the best strategy to take it forward. We propose to bring the Grails community under the umbrella of the Apache Software Foundation with an initial goal that Grails core and its critical plugins are brought into the ASF (see more details in the “Initial Goals” section). We propose that the Groovy project act as the sponsoring or [...]
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_background">Background</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Grails is a mature open source project. Work began in July 2005, with the 0.1 release on March 29, 2006, and the 1.0 release announced on February 18, 2008. Recent releases include 6.2.3 (Jan 2025) and pre-release 7.0.0-M1 (Dec 2024) . After 19 years of development, Grails has grown into a powerful web application framework which leverages many of the latest technologies for building web applications on the JVM.</p>
+</div>
+<div class="paragraph">
+<p>Numerous vendors have consulting businesses based on building web applications using Grails. Other organizations use Grails for their internal web application development. While the Grails community is large, the project itself is also large. The existing model of expecting a single vendor to do the bulk of its maintenance is no longer viable. Moving to the ASF provides a vendor neutral home where all community members can feel safe contributing to Grails.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_rationale">Rationale</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Many modern web frameworks in the Java space are more complicated than needed and don’t embrace the Don’t Repeat Yourself (DRY) principles.
+Dynamic frameworks like Rails and Django helped pave the way to a more modern way of thinking about web applications. Grails builds on these concepts and dramatically reduces the complexity of building web applications on the Java platform. What makes it different, however, is that it does so by building on already established Java technologies.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_initial_goals">Initial Goals</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The initial goals of the Grails transition to the ASF are:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>To establish a new home for an already fully functioning project in a setting which is welcoming for multiple vendors and individuals alike.</p>
+</li>
+<li>
+<p>While many Grails contributors have a long-time open source history and experience, not all are familiar with ASF governance practices. So, another goal will be to mentor and educate those involved if/as needed.</p>
+</li>
+<li>
+<p>As Grails has evolved, it has been split into small manageable pieces. This has made it easy to release parts individually but has made it harder to move the entire ecosystem across large changes (e.g. there have sometimes been circular dependencies). Also, because of Grails’ longevity, there is a rich ecosystem of plugins, but numerous plugins are out of date. So, a goal of this transition will be to bring across a fresh version of all of the critical Grails plugins. This has been du [...]
+</li>
+<li>
+<p>Since Spring Boot is now released every 6 months with only 12 months of OSS support per release, a Grails release will need to be released within 6 months of each Boot release to maintain Spring OSS support. Given the need for more frequent Grails releases due to Spring Boot, we will make an effort to reduce complexity and technical debt such that Grails releases take less effort with each release.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_current_status">Current Status</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Currently, Grails provides a fully functional implementation licensed under ALv2. The project home is at <a href="https://grails.org/" class="bare">https://grails.org/</a> and the majority of development is coordinated under various repos on GitHub at <a href="https://github.com/grails/" class="bare">https://github.com/grails/</a>. The project sports a very mature documentation and ecosystem of projects leveraging it.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_meritocracy">Meritocracy</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Grails, up to now, has been run by a few core project members with a lot of contributions coming from a wide community of participants in the project.
+We want to expand our diverse developer and user community and run the Grails project in the Apache way clearly signaling not only the licensing, but also the governance choice.</p>
+</div>
+<div class="paragraph">
+<p>Users and new contributors will be treated with respect and welcomed; they will earn merit in the project by providing quality patches and support that move the project forward.
+Those with a proven support and quality patch track record will be encouraged to become committers.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_community">Community</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>There are just a few core team members with over a hundred contributors to the project. If Grails is accepted into the ASF, transitioning the community to embrace the Apache Way of governance would be a primary initial goal. We would solicit major existing contributors to become committers on the project from the get go.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_core_developers">Core Developers</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Core developers include folks who are extremely skilled in working in the openly governed communities on code bases licensed under the ALv2. The core developers are NOT currently affiliated with the ASF, although quite a few contributors are.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_alignment">Alignment</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Grails is highly aligned with the Groovy project with many of the DSLs used within Grails being drivers for the requirements of DSL support within Groovy.
The Groovy subproject Geb is often used for testing with Grails and Grails provides
-special Geb support. Grails also makes use of about a dozen ASF artifacts from other ASF projects (commons, logging, etc.)
-
-== Known Risks
-
-As noted above, development has been sponsored mostly by a single company and coordinated mostly by the core team so far.
-For Grails to fully transition to an "Apache Way" governance model it needs to start embracing the meritocracy-centric way of growing the community of contributors while balancing it with the needs for extreme stability and coherency of the core implementation.
-
-== Orphaned products
-
-The community proposing Grails for incubation is an active open source community. The primary vendor until now has been Object Computing (and for about a year, a related spin-off Unity Foundation). Currently Object Computing has paused significant new investment in the Grails project, but the size and diversity of the community should guarantee against the project being orphaned.
-
-== Inexperience with Open Source
-
-The majority of the proposers have day jobs that have them working near full-time on open source projects. Grails to date has always been developed as an open source project.
-
-== Homogeneous Developers
-
-Now that Object Computing is pausing significant new investment, the initial group of committers is expected to be heterogeneous when it comes to corporate affiliations. The Grails community is also extremely diverse in terms of geography and backgrounds of developers.
-
-== Reliance on Salaried Developers
-
-Most of the contributors are paid to work in the Java ecosystem. While we might wander from our current employers, we probably won’t go far from the Java family tree.
-
-== Relationships with Other Apache Products
-
-Grails relies fundamentally on Apache Groovy. It also depends on a number of other ASF projects including commons, ant, tomcat, and maven. Various Grails plugins (many are optional) also have ASF projects as dependencies.
-
-== An Excessive Fascination with the Apache Brand
-
-While we think that the Apache ‘branding’ will add strength to our project’s desire for ‘neutrality’, we have no plans for making excessive use of the Apache brand.
-
-== Documentation
-
-See https://docs.grails.org/6.2.0/guide/single.html for the current state of the Grails documentation.
-A mature project website is also available at https://grails.org/.
-
-== Initial Source
-
-Initial source is available on GitHub under the ALv2
-
-[cols="5,5"]
-|===
-| https://github.com/grails/grails-core | The Grails Web Application Framework
-| https://github.com/grails/grails-gradle-plugin | Gradle build plugin used by many projects and end Grails applications
-| https://github.com/grails/grails-static-website | Static version of the grails.org website
-| https://github.com/grails/grails-doc | Documentation Project For The Grails Web Application Framework
-| https://github.com/grails/grails-forge | This is Grails project creator. Grails projects may be created using the browser interface, Command Line, or via CURL.
-| https://github.com/grails/grails-forge-ui | React.js app for start.grails.org
-| https://github.com/grails/scaffolding | Scaffolding plugin for Grails® framework
-| https://github.com/gpc/fields | the fields plugin used by scaffolding and also independently. A core plugin for grails web projects
-| https://github.com/grails/grails-angularjs-scaffolding | A plugin for generating client side assets based on domain
-| https://github.com/grails/grails-gsp | GSP (Grails Server Pages) - A server-side view rendering technology based on Groovy
-| https://github.com/grails/grails-views | Additional View Technologies for Grails
-| https://github.com/grails/grails-boot | Grails integrations with Spring Boot
-| https://github.com/grails/grails-async | Repository for Grails async plugins
-| https://github.com/grails/grails-data-mapping | GORM - Groovy Object Mapping
-| https://github.com/grails/gorm-hibernate5 | GORM for Hibernate 5
-| https://github.com/grails/gorm-hibernate6 | GORM for Hibernate 6
-| https://github.com/grails/gorm-mongodb | GORM for MongoDB
-| https://github.com/grails/gorm-neo4j | GORM for Neo4j
-| https://github.com/grails/gorm-graphql | An automatic GraphQL schema generator for GORM
-| https://github.com/grails/grails-database-migration | Grails® framework Database Migration Plugin
-| https://github.com/grails/gorm-docs | Documentation for GORM
-| https://github.com/grails/grails-rxgorm-docs | Documentation for RxGORM https://gorm.grails.org/latest/rx/manual/index.html
-| https://github.com/grails/grails-spring-security-core | Grails Spring Security Core Plugin
-| https://github.com/grails/grails-spring-security-rest | Grails plugin to implement token-based, RESTful authentication using Spring Security
-| https://github.com/grails/grails-spring-security-ui | The Spring Security UI plugin provides CRUD screens and other user management workflows.
-| https://github.com/grails/grails-spring-security-oauth2 | Spring security Oauth Grails 3 plugin
-| https://github.com/grails/grails-spring-security-acl |
-| https://github.com/grails/grails-spring-security-cas |
-| https://github.com/grails-plugins/grails-spring-security-ldap |
-| https://github.com/grails/grails-testing-support | Trait-based testing library for Grails framework
-| https://github.com/grails/geb | Geb Functional Testing for Grails® framework
-| https://github.com/grails/grails-functional-tests | Functional Test Application for Grails 3
-| https://github.com/grails/grails-plugin-converters | Legacy converters plugin
-| https://github.com/grails/grails-plugins-metadata | grails-plugins.json used by https://grails.org/plugins.html
-| https://github.com/grails/grails-redis | Redis plugin for Grails
-| https://github.com/grails/grails-cache | Grails Cache Plugin
-| https://github.com/grails/elasticsearch-grails-plugin | The Elasticsearch Grails plugin
-| https://github.com/grails/grails-quartz | This project provides integration of the Quartz scheduling framework into the Grails Framework
-| https://github.com/grails/github-actions | custom github actions for workflows
-| https://github.com/grails/github-pages-deploy-action | GitHub action for building a project and deploying it to GitHub pages.
-| https://github.com/grails/grails-wrapper | Grails Wrapper
-| https://github.com/grails/grails-profiles | 10 active profiles with tests
-|===
-
-== Required Resources
-
-=== Mailing lists
-
-----
-users@grails.apache.org
+special Geb support. Grails also makes use of about a dozen ASF artifacts from other ASF projects (commons, logging, etc.)</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_known_risks">Known Risks</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>As noted above, development has been sponsored mostly by a single company and coordinated mostly by the core team so far.
+For Grails to fully transition to an "Apache Way" governance model it needs to start embracing the meritocracy-centric way of growing the community of contributors while balancing it with the needs for extreme stability and coherency of the core implementation.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_orphaned_products">Orphaned products</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The community proposing Grails for incubation is an active open source community. The primary vendor until now has been Object Computing (and for about a year, a related spin-off Unity Foundation). Currently Object Computing has paused significant new investment in the Grails project, but the size and diversity of the community should guarantee against the project being orphaned.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_inexperience_with_open_source">Inexperience with Open Source</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The majority of the proposers have day jobs that have them working near full-time on open source projects. Grails to date has always been developed as an open source project.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_homogeneous_developers">Homogeneous Developers</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Now that Object Computing is pausing significant new investment, the initial group of committers is expected to be heterogeneous when it comes to corporate affiliations. The Grails community is also extremely diverse in terms of geography and backgrounds of developers.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_reliance_on_salaried_developers">Reliance on Salaried Developers</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Most of the contributors are paid to work in the Java ecosystem. While we might wander from our current employers, we probably won’t go far from the Java family tree.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_relationships_with_other_apache_products">Relationships with Other Apache Products</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Grails relies fundamentally on Apache Groovy. It also depends on a number of other ASF projects including commons, ant, tomcat, and maven. Various Grails plugins (many are optional) also have ASF projects as dependencies.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_an_excessive_fascination_with_the_apache_brand">An Excessive Fascination with the Apache Brand</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>While we think that the Apache ‘branding’ will add strength to our project’s desire for ‘neutrality’, we have no plans for making excessive use of the Apache brand.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_documentation">Documentation</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>See <a href="https://docs.grails.org/6.2.0/guide/single.html" class="bare">https://docs.grails.org/6.2.0/guide/single.html</a> for the current state of the Grails documentation.
+A mature project website is also available at <a href="https://grails.org/" class="bare">https://grails.org/</a>.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_initial_source">Initial Source</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Initial source is available on GitHub under the ALv2</p>
+</div>
+<table class="tableblock frame-all grid-all stretch">
+<colgroup>
+<col style="width: 50%;">
+<col style="width: 50%;">
+</colgroup>
+<tbody>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-core" class="bare">https://github.com/grails/grails-core</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The Grails Web Application Framework</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-gradle-plugin" class="bare">https://github.com/grails/grails-gradle-plugin</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Gradle build plugin used by many projects and end Grails applications</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-static-website" class="bare">https://github.com/grails/grails-static-website</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Static version of the grails.org website</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-doc" class="bare">https://github.com/grails/grails-doc</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Documentation Project For The Grails Web Application Framework</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-forge" class="bare">https://github.com/grails/grails-forge</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">This is Grails project creator. Grails projects may be created using the browser interface, Command Line, or via CURL.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-forge-ui" class="bare">https://github.com/grails/grails-forge-ui</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">React.js app for start.grails.org</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/scaffolding" class="bare">https://github.com/grails/scaffolding</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Scaffolding plugin for Grails® framework</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/gpc/fields" class="bare">https://github.com/gpc/fields</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">the fields plugin used by scaffolding and also independently. A core plugin for grails web projects</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-angularjs-scaffolding" class="bare">https://github.com/grails/grails-angularjs-scaffolding</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">A plugin for generating client side assets based on domain</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-gsp" class="bare">https://github.com/grails/grails-gsp</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">GSP (Grails Server Pages) - A server-side view rendering technology based on Groovy</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-views" class="bare">https://github.com/grails/grails-views</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Additional View Technologies for Grails</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-boot" class="bare">https://github.com/grails/grails-boot</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Grails integrations with Spring Boot</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-async" class="bare">https://github.com/grails/grails-async</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Repository for Grails async plugins</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-data-mapping" class="bare">https://github.com/grails/grails-data-mapping</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">GORM - Groovy Object Mapping</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/gorm-hibernate5" class="bare">https://github.com/grails/gorm-hibernate5</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">GORM for Hibernate 5</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/gorm-hibernate6" class="bare">https://github.com/grails/gorm-hibernate6</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">GORM for Hibernate 6</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/gorm-mongodb" class="bare">https://github.com/grails/gorm-mongodb</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">GORM for MongoDB</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/gorm-neo4j" class="bare">https://github.com/grails/gorm-neo4j</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">GORM for Neo4j</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/gorm-graphql" class="bare">https://github.com/grails/gorm-graphql</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">An automatic GraphQL schema generator for GORM</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-database-migration" class="bare">https://github.com/grails/grails-database-migration</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Grails® framework Database Migration Plugin</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/gorm-docs" class="bare">https://github.com/grails/gorm-docs</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Documentation for GORM</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-rxgorm-docs" class="bare">https://github.com/grails/grails-rxgorm-docs</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Documentation for RxGORM <a href="https://gorm.grails.org/latest/rx/manual/index.html" class="bare">https://gorm.grails.org/latest/rx/manual/index.html</a></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-spring-security-core" class="bare">https://github.com/grails/grails-spring-security-core</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Grails Spring Security Core Plugin</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-spring-security-rest" class="bare">https://github.com/grails/grails-spring-security-rest</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Grails plugin to implement token-based, RESTful authentication using Spring Security</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-spring-security-ui" class="bare">https://github.com/grails/grails-spring-security-ui</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The Spring Security UI plugin provides CRUD screens and other user management workflows.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-spring-security-oauth2" class="bare">https://github.com/grails/grails-spring-security-oauth2</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Spring security Oauth Grails 3 plugin</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-spring-security-acl" class="bare">https://github.com/grails/grails-spring-security-acl</a></p></td>
+<td class="tableblock halign-left valign-top"></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-spring-security-cas" class="bare">https://github.com/grails/grails-spring-security-cas</a></p></td>
+<td class="tableblock halign-left valign-top"></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails-plugins/grails-spring-security-ldap" class="bare">https://github.com/grails-plugins/grails-spring-security-ldap</a></p></td>
+<td class="tableblock halign-left valign-top"></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-testing-support" class="bare">https://github.com/grails/grails-testing-support</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Trait-based testing library for Grails framework</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/geb" class="bare">https://github.com/grails/geb</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Geb Functional Testing for Grails® framework</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-functional-tests" class="bare">https://github.com/grails/grails-functional-tests</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Functional Test Application for Grails 3</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-plugin-converters" class="bare">https://github.com/grails/grails-plugin-converters</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Legacy converters plugin</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-plugins-metadata" class="bare">https://github.com/grails/grails-plugins-metadata</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">grails-plugins.json used by <a href="https://grails.org/plugins.html" class="bare">https://grails.org/plugins.html</a></p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-redis" class="bare">https://github.com/grails/grails-redis</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Redis plugin for Grails</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-cache" class="bare">https://github.com/grails/grails-cache</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Grails Cache Plugin</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/elasticsearch-grails-plugin" class="bare">https://github.com/grails/elasticsearch-grails-plugin</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">The Elasticsearch Grails plugin</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-quartz" class="bare">https://github.com/grails/grails-quartz</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">This project provides integration of the Quartz scheduling framework into the Grails Framework</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/github-actions" class="bare">https://github.com/grails/github-actions</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">custom github actions for workflows</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/github-pages-deploy-action" class="bare">https://github.com/grails/github-pages-deploy-action</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">GitHub action for building a project and deploying it to GitHub pages.</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-wrapper" class="bare">https://github.com/grails/grails-wrapper</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">Grails Wrapper</p></td>
+</tr>
+<tr>
+<td class="tableblock halign-left valign-top"><p class="tableblock"><a href="https://github.com/grails/grails-profiles" class="bare">https://github.com/grails/grails-profiles</a></p></td>
+<td class="tableblock halign-left valign-top"><p class="tableblock">10 active profiles with tests</p></td>
+</tr>
+</tbody>
+</table>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_required_resources">Required Resources</h2>
+<div class="sectionbody">
+<div class="sect2">
+<h3 id="_mailing_lists">Mailing lists</h3>
+<div class="listingblock">
+<div class="content">
+<pre>users@grails.apache.org
dev@grails.apache.org
private@grails.apache.org
notifications@grails.apache.org
-commits@grails.apache.org
-----
-
-=== Git Repository
-
-See Initial Source Above
-
-=== Issue Tracking
-
-GitHub Issues
-
-=== Other Resources
-
-Means of setting up regular builds for Grails on builds.apache.org
-
-== Initial Committers
-
-* Søren Berg Glasius (ASF: sbglasius)
-* James Fredley (GitHub: jamesfredley)
-* James Daugherty (GitHub: jdaugherty)
-* Mattias Reichel (GitHub: matrei)
-* Sergio del Amo Caballero (ASF: sdelamo)
-* Scott Murphy (GitHub: codeconsole)
-* David Estes (GitHub: davydotcom)
-* Brian Koehmstedt (GitHub: bkoehm)
-* Graeme Rocher (ASF: grocher)
-* Puneet Behl (GitHub: puneetbehl)
-* Michael Yan (GitHub: rainboyan)
-* Paul King (ASF: paulk)
-
-== Champion
-
-Paul King
-
-== Nominated Mentors
-
-Paul King
-Søren Berg Glasius
-
-== Sponsoring Entity
-
-We would like to propose the Groovy project to sponsor the incubation of Grails.
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>Grails Project Proposal</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>Grails Project Proposal</h1><hr/></div></div></div></div><footer id='footer'>
+commits@grails.apache.org</pre>
+</div>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_git_repository">Git Repository</h3>
+<div class="paragraph">
+<p>See Initial Source Above</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_issue_tracking">Issue Tracking</h3>
+<div class="paragraph">
+<p>GitHub Issues</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_other_resources">Other Resources</h3>
+<div class="paragraph">
+<p>Means of setting up regular builds for Grails on builds.apache.org</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_initial_committers">Initial Committers</h2>
+<div class="sectionbody">
+<div class="ulist">
+<ul>
+<li>
+<p>Søren Berg Glasius (ASF: sbglasius)</p>
+</li>
+<li>
+<p>James Fredley (GitHub: jamesfredley)</p>
+</li>
+<li>
+<p>James Daugherty (GitHub: jdaugherty)</p>
+</li>
+<li>
+<p>Mattias Reichel (GitHub: matrei)</p>
+</li>
+<li>
+<p>Sergio del Amo Caballero (ASF: sdelamo)</p>
+</li>
+<li>
+<p>Scott Murphy (GitHub: codeconsole)</p>
+</li>
+<li>
+<p>David Estes (GitHub: davydotcom)</p>
+</li>
+<li>
+<p>Brian Koehmstedt (GitHub: bkoehm)</p>
+</li>
+<li>
+<p>Graeme Rocher (ASF: grocher)</p>
+</li>
+<li>
+<p>Puneet Behl (GitHub: puneetbehl)</p>
+</li>
+<li>
+<p>Michael Yan (GitHub: rainboyan)</p>
+</li>
+<li>
+<p>Paul King (ASF: paulk)</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_champion">Champion</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Paul King</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_nominated_mentors">Nominated Mentors</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Paul King
+Søren Berg Glasius</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_sponsoring_entity">Sponsoring Entity</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>We would like to propose the Groovy project to sponsor the incubation of Grails.</p>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/groovy-release-discussion.html b/wiki/groovy-release-discussion.html
index 1f427b1..b1d2755 100644
--- a/wiki/groovy-release-discussion.html
+++ b/wiki/groovy-release-discussion.html
@@ -59,144 +59,314 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= Adapting the release process for Apache
-
-v1.1, March 28, 2018
-
-:teamcity: https://ci.groovy-lang.org
-:groovy: https://groovy-lang.org
-:bintray: https://bintray.com/[Bintray]
-:gradle: https://gradle.org[Gradle]
-:category: dev
-
-_NOTE_
-****
-This document captures some historical information and discussion about Groovy's release process both before joining Apache and during incubation.
-Many of the ideas went into Groovy's current release process which involves use of a gradle build at the following repo: https://github.com/apache/groovy-release/
-****
-
-== The Groovy Way
-
-Between 2010 and 2015, the Groovy team invested a lot of time in narrowing its release process to reduce human errors as much as possible. Releases were previously done from a despot personal computer, with a number of risks:
-
-* mix of development sources and sources found in the repository. This can happen if the release manager did the release without doing a clean checkout in a separate directory. Then there were risks that source files were present on the release manager computer and not in source control.
-* reliance on a local dependency repository. During development, committers usually do not suffer dependency management issues, because they do regular update and some third party dependencies are found in their local caches (Maven, Gradle). However, new developers may find themselves in a different situation, where they have no local cache. When they try to build, compilation fails because some dependencies cannot be fetched.
-* manual update of properties file for release numbers
-* manual tagging
-* manual update of VCS after release, that can easily be forgotten
-* upload of distribution to the Codehaus WebDAV repository, with a lot of failures due to the poor quality of the protocol (in particular stale lock files)
-* upload of documentation took up to several hours due to the WebDAV process, and were *erasing* previous versions of documentation (API, GAPI, GDK) so it wasn't possible to find online the reference API for a specific Groovy version.
-* Maven artifact uploading and signing done through the Codehaus repository, which was again very slow and error-prone
-
-It's worth noting that binary artifacts are currently published in the `org.codehaus.groovy` group id and that the build uses {gradle}.
-
-=== Automation
-
-For those reasons, we slowly migrated off the Codehaus infrastructure and built a new release process with a continuous integration server at its core. We reviewed several options and eventually found a sponsor, Jetbrains, for a {teamcity}[TeamCity continuous integration server]. The reasons to choose a dedicated server are not all related to the release process. The development process itself greatly benefits from it:
-
-* each branch of Groovy (currently 3 active branches: 2.3.x, 2.4.x, master) are built and tested against multiple JDKs : JDK 6, JDK 7, JDK 8, and older branches of Groovy are tested against older JDKs (JDK 5 for 1.8.x/2.x). Note that some Groovy versions are tested in two flavors: legacy and _invokedynamic_.
-* we build unreleased versions of OpenJDK from sources, so that we can test the master branch against upcoming JDK versions, such as JDK 8 updates and even JDK 9. Those builds allowed us to find a lot of bugs in the JDK before it was released.
-* some community projects are tested against development versions of Groovy (currently, Ratpack and Nextflow)
-
-Eventually, the {groovy}[new Groovy website] is built from https://github.com/groovy/groovy-website[sources] and deployed directly from the CI server, after each push on the _master_ branch.
-
-But in addition to those benefits, it's the release process itself which greatly improved:
-
-* the deployment infrastructure moved from Codehaus to {bintray} and http://www.jfrog.com/open-source/[Artifactory]
-* several build plans are dedicated to builds and releases:
-** the http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_UploadSnapshots&guest=1[snapshot upload] plan builds Groovy from sources and deploys the artifacts to the \http://oss.jfrog.org/oss-snapshot-local/org/codehaus/groovy/ [OSS Artifactory Snapshot Repository legacy URL].
-** the http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_ReleasePlan&guest=1[release plan] allows a release manager to release a new version of Groovy directly from the CI server
-** the http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_GvmBroadcast[GVM broadcast] plan allows us to announce a new release of Groovy to \http://gvmtool.net/ (obsolete - now SDKMAN) and its https://twitter.com/gvmtool[Twitter account] directly from the CI server
-** the http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_GvmMakeDefault[GVM default] plan allows us to notify GVM that a specific Groovy version is the new default version, directly from the CI server
-
-The last two GVM plans are separated because they need to be triggered manually, once we are ready to announce that a new Groovy version is out. Let's now describe what the release plan does, so that we can imagine what adaptations will be required to go the Apache Way.
-
-=== Release plan
-
-The release plan is at the core of the Groovy release process. It reduces human interactions to the bare minimal, dramatically reducing the potential errors. In particular:
-
-* builds are done using a verified JDK
-* the CI local Maven and Gradle repository caches are cleaned every day, making sure that the build is doable from source for any developer
-* release branches and tags are created automatically
-* properties files are updated automatically (sets the release version, then the next version to push on VCS)
-* binaries (sources, documentation, distribution, SDK) are uploaded to {bintray}
-* documentation is uploaded to the {groovy}[Groovy website] in a separate directory, so that each Groovy version has its own documentation readable online
-* all artifacts (binaries+maven) are signed through the {bintray} API
-* Maven artifacts are uploaded to https://bintray.com/bintray/jcenter[JCenter]
-* Maven Central synchronization is done through the {bintray} API
-* GVM gets notified that a new version is available
-
-To do this, the only requirement is to fill in a form and click a button. From that, everything is automated. So when the Groovy team decides that a new release can be done, after clicking the button, the release is available online in general less than 2 hours later. This has to be compared to the previous, error-prone process, which took up to 12 hours for a single release. Groovy has a tradition of maintaining multiple branches, so this time has to be multiplied by the number of activ [...]
-
-With that regards, the decision whether to release a new version or not is done collectively, on the mailing list or in a Skype channel where the core developers agree about releases. But once the decision is made, there is almost no human process involved anymore.
-
-Last but not least, Groovy doesn't make any difference between the source distribution (the zip of the source tree) and binary artifacts (distribution, documentation, maven artifacts). All are considered part of the release, and signed accordingly. But there is a technical difference between Maven artifacts and what we call the distribution (sources, binaries, documentation, SDKs). The distribution is only available in {bintray}. It consists of zip files that the developer can download f [...]
-
-To be able to upload the distribution, the release process automatically creates a new version of Groovy on {bintray}. This version is some kind of folder which will host files for this specific Groovy version. When the files are uploaded, they are kept in *staging* for at most 48 hours. Currently, the release process automatically publishes the artifacts, so there's effectively no staging for Groovy.
-
-It is unclear whether such a staging phase exists for the Maven artifacts uploaded to JCenter (but it seems we can), but it is clear that the Maven Central synchronization that is doable through {bintray} uses a staging phase, because it directly communicates with the Nexus OSS repository. Maven Central synchronization staging repositories are directly closed by {bintray}.
-
-Releasing a new version of Groovy also implies updating the website. Technically it involves two manual steps:
-
-* connect to the server and update the _symlinks_ in _/var/www/docs/docs_ for _latest_ and _next_ versions of Groovy, so that the latest documentation link points to the just released version of Groovy
-* *then* update the _sitemap.groovy_ file in the Groovy Website repo to add the new version, commit, and push, leading to the generation of the website. In particular, the static website generator will fetch the release notes from JIRA and generate a pretty page using the website template, as well as generating some documentation pages from the whole documentation, again decorated with the website template.
-
-Optionally, for major versions, release notes can be written in Asciidoctor format, and published through the website (see github.com/groovy/groovy-website/tree/master/site/src/site/releasenotes).
-
-Eventually, the joint builds on the CI server need to be updated so that they use the latest snapshot versions of Groovy. This is done by changing the `CI_GROOVY_VERSION` environment variable of each build configuration.
-
-== Adaptations required for Apache
-
-The following section is based on our understanding of the Apache Way of releasing. This section is going to be updated based on the feedback we have from our mentors or fellow Apache members.
-
-First of all, the main and only important artifact for Apache is the *sources of the project*. This is going to be very important for our adaptation of the process. This means that binaries, documentation, Maven artifacts and such are not considered equally, and are not mandatory to be able to release a version.
-
-A detailed guide of the release process *during incubation* can be found http://incubator.apache.org/guides/releasemanagement.html[here] but those are derived from the final release process. Below are the main points with comments about how far we are from there.
-
-* 1.1 Checksums and PGP signatures are valid.
-
-_There are no such checksums or multiple PGP signatures for Groovy, apart from those generated through {bintray}. It is implied here that signatures must be checked before the release is done, that is to say that we *require* a staging phase and the ability to perform *multiple signatures*. Signatures are those of committers._
-
-* 2.1 Build is successful including automated tests.
-
-_We're all clear on that. Groovy is tested before each release, and the CI server does much more in testing that a normal user can do. In particular, testing with multiple JDKs. The sources zip has been verified to build and test from sources without any issue._
-
-* 3.1 DISCLAIMER is correct, filenames include "incubating".
-
-_We need to add the *DISCLAIMER*. The "incubating" part is disturbing. In particular, Groovy is not a new project. It has been around for 12+ years, and the last release before Apache will be 2.4.2. Does it mean that the next release will have to be named 2.4.3-incubating? It will be very disturbing for our users, and it sounds pretty bad, just as if Groovy wasn't production ready. Should we do this, then the incubation phase should be shortened as much as possible. Another option that w [...]
-
-* 3.2 Top-level LICENSE and NOTICE are correct for each distribution.
-
-_We do have those files_.
-
-* 3.3 All source files have license headers where appropriate.
-
-_It has to be checked, but it should already be the case_
-
-* 3.4 The provenance of all source files is clear (ASF or software grants).
-
-_This is going to be done during the incubation phase._
-
-* 3.5 Dependencies licenses are ok as per http://apache.org/legal/
-
-_We will have to remove the only dependency which is now unused and not a standard OSS license: Simian._
-
-* 3.6 Release consists of source code only, no binaries. Each Apache release must contain a source package. This package may not contain compiled components (such as "jar" files) because compiled components are not open source, even if they were built from open source.
-
-_The source zip does contain a binary *dependency*: openbeans, which is not available in a third party Maven repository. We are unsure if the rule applies to it or not._
-
-It is also implied that we are going to change the group id from `org.codehaus.groovy` to `org.apache.groovy`. What it means for the release process (in particular synchronization with Maven Central through Bintray) are unclear.
-
-So it seems that the current process could be adapted if:
-
-* we only release the source zip on Apache, and only this item is voted
-* to do this we need to split the release process in at least 3 steps
-** building and deploying to a staging repository, including all artifacts. That staging period has to be extended to *at least* 72 hours, which is the minimal voting duration.
-** signing has to be done by individuals. This implies some way to download the full artifact list (there are more than 200 binary files in total !), sign them, and upload the signatures only.
-** publishing, which implies closing the Bintray staging repository, then synchronizing to Maven Central and publishing to GVM
-
-
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>Adapting the release process for Apache</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>Adapting the release process for Apache</h1><hr/></div></div></div></div><footer id='footer'>
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>Adapting the release process for Apache</a></li><li><a href='#_the_groovy_way' class='anchor-link'>The Groovy Way</a></li><li><a href='#_adaptations_required_for_apache' class='anchor-link'>Adaptations required for Apache</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>Adapting t [...]
+<div class="sectionbody">
+<div class="paragraph">
+<p>v1.1, March 28, 2018</p>
+</div>
+<div class="paragraph">
+<p><em>NOTE</em></p>
+</div>
+<div class="sidebarblock">
+<div class="content">
+<div class="paragraph">
+<p>This document captures some historical information and discussion about Groovy’s release process both before joining Apache and during incubation.
+Many of the ideas went into Groovy’s current release process which involves use of a gradle build at the following repo: <a href="https://github.com/apache/groovy-release/" class="bare">https://github.com/apache/groovy-release/</a></p>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_the_groovy_way">The Groovy Way</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Between 2010 and 2015, the Groovy team invested a lot of time in narrowing its release process to reduce human errors as much as possible. Releases were previously done from a despot personal computer, with a number of risks:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>mix of development sources and sources found in the repository. This can happen if the release manager did the release without doing a clean checkout in a separate directory. Then there were risks that source files were present on the release manager computer and not in source control.</p>
+</li>
+<li>
+<p>reliance on a local dependency repository. During development, committers usually do not suffer dependency management issues, because they do regular update and some third party dependencies are found in their local caches (Maven, Gradle). However, new developers may find themselves in a different situation, where they have no local cache. When they try to build, compilation fails because some dependencies cannot be fetched.</p>
+</li>
+<li>
+<p>manual update of properties file for release numbers</p>
+</li>
+<li>
+<p>manual tagging</p>
+</li>
+<li>
+<p>manual update of VCS after release, that can easily be forgotten</p>
+</li>
+<li>
+<p>upload of distribution to the Codehaus WebDAV repository, with a lot of failures due to the poor quality of the protocol (in particular stale lock files)</p>
+</li>
+<li>
+<p>upload of documentation took up to several hours due to the WebDAV process, and were <strong>erasing</strong> previous versions of documentation (API, GAPI, GDK) so it wasn’t possible to find online the reference API for a specific Groovy version.</p>
+</li>
+<li>
+<p>Maven artifact uploading and signing done through the Codehaus repository, which was again very slow and error-prone</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>It’s worth noting that binary artifacts are currently published in the <code>org.codehaus.groovy</code> group id and that the build uses <a href="https://gradle.org">Gradle</a>.</p>
+</div>
+<div class="sect2">
+<h3 id="_automation">Automation</h3>
+<div class="paragraph">
+<p>For those reasons, we slowly migrated off the Codehaus infrastructure and built a new release process with a continuous integration server at its core. We reviewed several options and eventually found a sponsor, Jetbrains, for a <a href="https://ci.groovy-lang.org">TeamCity continuous integration server</a>. The reasons to choose a dedicated server are not all related to the release process. The development process itself greatly benefits from it:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>each branch of Groovy (currently 3 active branches: 2.3.x, 2.4.x, master) are built and tested against multiple JDKs : JDK 6, JDK 7, JDK 8, and older branches of Groovy are tested against older JDKs (JDK 5 for 1.8.x/2.x). Note that some Groovy versions are tested in two flavors: legacy and <em>invokedynamic</em>.</p>
+</li>
+<li>
+<p>we build unreleased versions of OpenJDK from sources, so that we can test the master branch against upcoming JDK versions, such as JDK 8 updates and even JDK 9. Those builds allowed us to find a lot of bugs in the JDK before it was released.</p>
+</li>
+<li>
+<p>some community projects are tested against development versions of Groovy (currently, Ratpack and Nextflow)</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Eventually, the <a href="https://groovy-lang.org">new Groovy website</a> is built from <a href="https://github.com/groovy/groovy-website">sources</a> and deployed directly from the CI server, after each push on the <em>master</em> branch.</p>
+</div>
+<div class="paragraph">
+<p>But in addition to those benefits, it’s the release process itself which greatly improved:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>the deployment infrastructure moved from Codehaus to <a href="https://bintray.com/">Bintray</a> and <a href="http://www.jfrog.com/open-source/">Artifactory</a></p>
+</li>
+<li>
+<p>several build plans are dedicated to builds and releases:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>the <a href="http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_UploadSnapshots&guest=1">snapshot upload</a> plan builds Groovy from sources and deploys the artifacts to the http://oss.jfrog.org/oss-snapshot-local/org/codehaus/groovy/ [OSS Artifactory Snapshot Repository legacy URL].</p>
+</li>
+<li>
+<p>the <a href="http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_ReleasePlan&guest=1">release plan</a> allows a release manager to release a new version of Groovy directly from the CI server</p>
+</li>
+<li>
+<p>the <a href="http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_GvmBroadcast">GVM broadcast</a> plan allows us to announce a new release of Groovy to http://gvmtool.net/ (obsolete - now SDKMAN) and its <a href="https://twitter.com/gvmtool">Twitter account</a> directly from the CI server</p>
+</li>
+<li>
+<p>the <a href="http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_GvmMakeDefault">GVM default</a> plan allows us to notify GVM that a specific Groovy version is the new default version, directly from the CI server</p>
+</li>
+</ul>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>The last two GVM plans are separated because they need to be triggered manually, once we are ready to announce that a new Groovy version is out. Let’s now describe what the release plan does, so that we can imagine what adaptations will be required to go the Apache Way.</p>
+</div>
+</div>
+<div class="sect2">
+<h3 id="_release_plan">Release plan</h3>
+<div class="paragraph">
+<p>The release plan is at the core of the Groovy release process. It reduces human interactions to the bare minimal, dramatically reducing the potential errors. In particular:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>builds are done using a verified JDK</p>
+</li>
+<li>
+<p>the CI local Maven and Gradle repository caches are cleaned every day, making sure that the build is doable from source for any developer</p>
+</li>
+<li>
+<p>release branches and tags are created automatically</p>
+</li>
+<li>
+<p>properties files are updated automatically (sets the release version, then the next version to push on VCS)</p>
+</li>
+<li>
+<p>binaries (sources, documentation, distribution, SDK) are uploaded to <a href="https://bintray.com/">Bintray</a></p>
+</li>
+<li>
+<p>documentation is uploaded to the <a href="https://groovy-lang.org">Groovy website</a> in a separate directory, so that each Groovy version has its own documentation readable online</p>
+</li>
+<li>
+<p>all artifacts (binaries+maven) are signed through the <a href="https://bintray.com/">Bintray</a> API</p>
+</li>
+<li>
+<p>Maven artifacts are uploaded to <a href="https://bintray.com/bintray/jcenter">JCenter</a></p>
+</li>
+<li>
+<p>Maven Central synchronization is done through the <a href="https://bintray.com/">Bintray</a> API</p>
+</li>
+<li>
+<p>GVM gets notified that a new version is available</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>To do this, the only requirement is to fill in a form and click a button. From that, everything is automated. So when the Groovy team decides that a new release can be done, after clicking the button, the release is available online in general less than 2 hours later. This has to be compared to the previous, error-prone process, which took up to 12 hours for a single release. Groovy has a tradition of maintaining multiple branches, so this time has to be multiplied by the number of ac [...]
+</div>
+<div class="paragraph">
+<p>With that regards, the decision whether to release a new version or not is done collectively, on the mailing list or in a Skype channel where the core developers agree about releases. But once the decision is made, there is almost no human process involved anymore.</p>
+</div>
+<div class="paragraph">
+<p>Last but not least, Groovy doesn’t make any difference between the source distribution (the zip of the source tree) and binary artifacts (distribution, documentation, maven artifacts). All are considered part of the release, and signed accordingly. But there is a technical difference between Maven artifacts and what we call the distribution (sources, binaries, documentation, SDKs). The distribution is only available in <a href="https://bintray.com/">Bintray</a>. It consists of z [...]
+</div>
+<div class="paragraph">
+<p>To be able to upload the distribution, the release process automatically creates a new version of Groovy on <a href="https://bintray.com/">Bintray</a>. This version is some kind of folder which will host files for this specific Groovy version. When the files are uploaded, they are kept in <strong>staging</strong> for at most 48 hours. Currently, the release process automatically publishes the artifacts, so there’s effectively no staging for Groovy.</p>
+</div>
+<div class="paragraph">
+<p>It is unclear whether such a staging phase exists for the Maven artifacts uploaded to JCenter (but it seems we can), but it is clear that the Maven Central synchronization that is doable through <a href="https://bintray.com/">Bintray</a> uses a staging phase, because it directly communicates with the Nexus OSS repository. Maven Central synchronization staging repositories are directly closed by <a href="https://bintray.com/">Bintray</a>.</p>
+</div>
+<div class="paragraph">
+<p>Releasing a new version of Groovy also implies updating the website. Technically it involves two manual steps:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>connect to the server and update the <em>symlinks</em> in <em>/var/www/docs/docs</em> for <em>latest</em> and <em>next</em> versions of Groovy, so that the latest documentation link points to the just released version of Groovy</p>
+</li>
+<li>
+<p><strong>then</strong> update the <em>sitemap.groovy</em> file in the Groovy Website repo to add the new version, commit, and push, leading to the generation of the website. In particular, the static website generator will fetch the release notes from JIRA and generate a pretty page using the website template, as well as generating some documentation pages from the whole documentation, again decorated with the website template.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Optionally, for major versions, release notes can be written in Asciidoctor format, and published through the website (see github.com/groovy/groovy-website/tree/master/site/src/site/releasenotes).</p>
+</div>
+<div class="paragraph">
+<p>Eventually, the joint builds on the CI server need to be updated so that they use the latest snapshot versions of Groovy. This is done by changing the <code>CI_GROOVY_VERSION</code> environment variable of each build configuration.</p>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_adaptations_required_for_apache">Adaptations required for Apache</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The following section is based on our understanding of the Apache Way of releasing. This section is going to be updated based on the feedback we have from our mentors or fellow Apache members.</p>
+</div>
+<div class="paragraph">
+<p>First of all, the main and only important artifact for Apache is the <strong>sources of the project</strong>. This is going to be very important for our adaptation of the process. This means that binaries, documentation, Maven artifacts and such are not considered equally, and are not mandatory to be able to release a version.</p>
+</div>
+<div class="paragraph">
+<p>A detailed guide of the release process <strong>during incubation</strong> can be found <a href="http://incubator.apache.org/guides/releasemanagement.html">here</a> but those are derived from the final release process. Below are the main points with comments about how far we are from there.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>1.1 Checksums and PGP signatures are valid.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p><em>There are no such checksums or multiple PGP signatures for Groovy, apart from those generated through <a href="https://bintray.com/">Bintray</a>. It is implied here that signatures must be checked before the release is done, that is to say that we <strong>require</strong> a staging phase and the ability to perform <strong>multiple signatures</strong>. Signatures are those of committers.</em></p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>2.1 Build is successful including automated tests.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p><em>We’re all clear on that. Groovy is tested before each release, and the CI server does much more in testing that a normal user can do. In particular, testing with multiple JDKs. The sources zip has been verified to build and test from sources without any issue.</em></p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>3.1 DISCLAIMER is correct, filenames include "incubating".</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p><em>We need to add the <strong>DISCLAIMER</strong>. The "incubating" part is disturbing. In particular, Groovy is not a new project. It has been around for 12+ years, and the last release before Apache will be 2.4.2. Does it mean that the next release will have to be named 2.4.3-incubating? It will be very disturbing for our users, and it sounds pretty bad, just as if Groovy wasn’t production ready. Should we do this, then the incubation phase should be shortened as much as poss [...]
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>3.2 Top-level LICENSE and NOTICE are correct for each distribution.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p><em>We do have those files</em>.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>3.3 All source files have license headers where appropriate.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p><em>It has to be checked, but it should already be the case</em></p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>3.4 The provenance of all source files is clear (ASF or software grants).</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p><em>This is going to be done during the incubation phase.</em></p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>3.5 Dependencies licenses are ok as per <a href="http://apache.org/legal/" class="bare">http://apache.org/legal/</a></p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p><em>We will have to remove the only dependency which is now unused and not a standard OSS license: Simian.</em></p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>3.6 Release consists of source code only, no binaries. Each Apache release must contain a source package. This package may not contain compiled components (such as "jar" files) because compiled components are not open source, even if they were built from open source.</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p><em>The source zip does contain a binary <strong>dependency</strong>: openbeans, which is not available in a third party Maven repository. We are unsure if the rule applies to it or not.</em></p>
+</div>
+<div class="paragraph">
+<p>It is also implied that we are going to change the group id from <code>org.codehaus.groovy</code> to <code>org.apache.groovy</code>. What it means for the release process (in particular synchronization with Maven Central through Bintray) are unclear.</p>
+</div>
+<div class="paragraph">
+<p>So it seems that the current process could be adapted if:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>we only release the source zip on Apache, and only this item is voted</p>
+</li>
+<li>
+<p>to do this we need to split the release process in at least 3 steps</p>
+<div class="ulist">
+<ul>
+<li>
+<p>building and deploying to a staging repository, including all artifacts. That staging period has to be extended to <strong>at least</strong> 72 hours, which is the minimal voting duration.</p>
+</li>
+<li>
+<p>signing has to be done by individuals. This implies some way to download the full artifact list (there are more than 200 binary files in total !), sign them, and upload the signatures only.</p>
+</li>
+<li>
+<p>publishing, which implies closing the Bintray staging repository, then synchronizing to Maven Central and publishing to GVM</p>
+</li>
+</ul>
+</div>
+</li>
+</ul>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>
diff --git a/wiki/initial-release-process-proposal.html b/wiki/initial-release-process-proposal.html
index 6901274..7bada2a 100644
--- a/wiki/initial-release-process-proposal.html
+++ b/wiki/initial-release-process-proposal.html
@@ -59,105 +59,214 @@
</ul>
</div>
</div>
- </div><asciidocText attributes='{DOCS_BASEURL=https://docs.groovy-lang.org/latest}'>= Initial release process proposal
-
-v1.2, March 28, 2018
-
-:teamcity: https://ci.groovy-lang.org
-:groovy: https://groovy-lang.org
-:bintray: https://bintray.com/[Bintray]
-:gradle: https://gradle.org[Gradle]
-
-_NOTE_
-****
-This document captures some historical information and discussion about Groovy's release process that occurred soon after the Groovy project joined Apache.
-Many of the ideas went into Groovy's current release process which involves use of a gradle build at the following repo: https://github.com/apache/groovy-release/
-If any of the steps in the automated process fail, this documentation might prove useful to understand what manual rectification steps that might be needed.
-****
-
-== Background
-
-The goal of this document is to guide the release manager in order to perform a release under the Apache Incubator. This document, reflecting the status of incubation, is work in progress and will be adapted in regard to comments from the community, mentors and IPMC.
-
-== Initiating a release
-
-Releases can be initiated by a committer, as long as:
-
-* an email has been sent to the dev mailing list, where a committer volunteers for a release
-* there's a general agreement that a release can be done. There's still no explicit rule telling when a new Groovy version can be released, but the history of the project shows that releases are usually done when a significant amount of bugfixes have been done justifying a release, or that new major features are ready.
-* release manager has their personal setup ready. In particular:
-** release manager can log into their people.apache.org account using SSH
-** release manager has administration privileges on {teamcity}[the CI server]
-
-Releases are launched from the CI server. A release should never be done from a personal computer.
-
-== Preparing a release
-
-Releases are done from the CI server, but since it will involve creating tags, branches and several commits, and that the CI server doesn't have privileges to do it, we cannot work on the Apache Git origin. Instead, it is required that the release manager forks the repository and pushes changes to their personal fork. Given that `GROOVY_2_4_X` is the branch to release, `upstream` references Apache Git, and `origin` the release manager fork on GitHub, preparing for a release usually starts with:
-
-```
-git checkout GROOVY_2_4_X
+ </div><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>Initial release process proposal</a></li><li><a href='#_background' class='anchor-link'>Background</a></li><li><a href='#_initiating_a_release' class='anchor-link'>Initiating a release</a></li><li><a href='#_preparing_a_release' class='anchor-link'>Preparing a release</a></li><li><a href='#_set_up_the_teamci [...]
+<div class="sectionbody">
+<div class="paragraph">
+<p>v1.2, March 28, 2018</p>
+</div>
+<div class="paragraph">
+<p><em>NOTE</em></p>
+</div>
+<div class="sidebarblock">
+<div class="content">
+<div class="paragraph">
+<p>This document captures some historical information and discussion about Groovy’s release process that occurred soon after the Groovy project joined Apache.
+Many of the ideas went into Groovy’s current release process which involves use of a gradle build at the following repo: <a href="https://github.com/apache/groovy-release/" class="bare">https://github.com/apache/groovy-release/</a>
+If any of the steps in the automated process fail, this documentation might prove useful to understand what manual rectification steps that might be needed.</p>
+</div>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_background">Background</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>The goal of this document is to guide the release manager in order to perform a release under the Apache Incubator. This document, reflecting the status of incubation, is work in progress and will be adapted in regard to comments from the community, mentors and IPMC.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_initiating_a_release">Initiating a release</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Releases can be initiated by a committer, as long as:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>an email has been sent to the dev mailing list, where a committer volunteers for a release</p>
+</li>
+<li>
+<p>there’s a general agreement that a release can be done. There’s still no explicit rule telling when a new Groovy version can be released, but the history of the project shows that releases are usually done when a significant amount of bugfixes have been done justifying a release, or that new major features are ready.</p>
+</li>
+<li>
+<p>release manager has their personal setup ready. In particular:</p>
+<div class="ulist">
+<ul>
+<li>
+<p>release manager can log into their people.apache.org account using SSH</p>
+</li>
+<li>
+<p>release manager has administration privileges on <a href="https://ci.groovy-lang.org">the CI server</a></p>
+</li>
+</ul>
+</div>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Releases are launched from the CI server. A release should never be done from a personal computer.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_preparing_a_release">Preparing a release</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Releases are done from the CI server, but since it will involve creating tags, branches and several commits, and that the CI server doesn’t have privileges to do it, we cannot work on the Apache Git origin. Instead, it is required that the release manager forks the repository and pushes changes to their personal fork. Given that <code>GROOVY_2_4_X</code> is the branch to release, <code>upstream</code> references Apache Git, and <code>origin</code> the release manager fork on Git [...]
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>git checkout GROOVY_2_4_X
git pull --rebase upstream GROOVY_2_4_X
-git push origin GROOVY_2_4_X
-```
-
-If you haven't done it already, create a token on https://github.com/settings/tokens[your GitHub profile] so that the CI server can have write access on your fork. Keep the token safe!
-
-== Set up the TeamCity release configuration
-
-Go to the http://ci.groovy-lang.org/admin/editBuild.html?id=buildType:Groovy_BintrayIntegration_ReleasePlan[TeamCity release plan] configuration and open the VCS settings. If the VCS root attached to the configuration is not your GitHub fork, attach your VCS root, or create a new VCS root if you haven't done it already. The VCS root MUST have write access using the token authentication.
-
-
-== Trigger the release
-
-Go to the http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_ReleasePlan&tab=artifactory[Artifactory Release Management tab] and fill the form appropriately:
-
-* _groovyVersion_
-** _release version_ must be set to the version number of Groovy you are releasing. For example `2.4.6`.
-** _next integration version_ *must* be set to the subsequent version number of Groovy you are releasing and as it will be a development version, *must* end with `-SNAPSHOT`. For example `2.4.5-SNAPSHOT`.
-* _groovyBundleVersion_
-** _release version_ must be set to the OSGi bundle version number of Groovy you are releasing. For example `2.4.6`.
-** _next integration version_ *must* be set to the subsequent OSGi bundle version number of Groovy you are releasing and as it will be a development version, *must* end with `.SNAPSHOT`. For example `2.4.5.SNAPSHOT`.
-* _Checkout branch:_ must be set to the branch you are releasing. For example, if you are releasing a 2.4.x version of Groovy, `GROOVY_2_4_X`.
-* _Use release branch_ must be checked, and it will automate the creation of a release branch. Use a branch name in the form of `REL_BRANCH_2_4_3`
-* _Create VCS tag_ must be checked, and it will automate the creation of a release tag. Use a tag name in the form of `GROOVY_2_4_4`
-* _Tag comment_ must be set to something useful describing the release version
-* _Repository to stage the release to (Artifactory Pro):_ must be set to `oss-release-local`
-* _Staging comment_ should be set with something useful like `release of Groovy 2.4.6`
-
-Hit the release button.
-
-== Upload to Apache servers
-
-At this point, if the release build was successful, artifacts are staging on Bintray. You must log into Bintray and download the distribution artifacts. The URL for
-the staging distribution should be in the form of https://bintray.com/groovy/maven/groovy/2.4.6[https://bintray.com/groovy/maven/groovy/2.4.6].
-
-Downloads of the following files are only possible if you use the (groovy-operator,<api key>) credentials. If you don't have them please ask one of the PPMC members:
-
-* apache-groovy-src-_version_.zip
-* apache-groovy-binary-_version_.zip
-* apache-groovy-docs-_version_.zip
-* apache-groovy-sdk-_version_.zip
-
-as well as the corresponding _asc_ and _md5_ files. There should therefore be a total of _12_ files.
-
-NOTE: at this point it is possible that the MD5 files are missing, in which cases you would have to create them locally before uploading to Apache.
-```
-for f in `ls *.zip`; do md5sum $f > $f.md5; done
-```
-
-It is in general not accepted that the release is signed using the CI server key, so you *must* replace the signatures with your own. If you didn't yet,
-add your public key to the `KEYS` file, then sign each zip individually. This can be done, for each file, with a command line like:
-
-```
-gpg --armor --output apache-groovy-src-2.4.6.zip.asc --detach-sign apache-groovy-src-2.4.6.zip
-```
-
-Now you are ready to upload to the dev space on _dist.apache.org_. First of all, please make sure your local layout
-looks like this:
-
-```
-|-- KEYS
+git push origin GROOVY_2_4_X</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>If you haven’t done it already, create a token on <a href="https://github.com/settings/tokens">your GitHub profile</a> so that the CI server can have write access on your fork. Keep the token safe!</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_set_up_the_teamcity_release_configuration">Set up the TeamCity release configuration</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Go to the <a href="http://ci.groovy-lang.org/admin/editBuild.html?id=buildType:Groovy_BintrayIntegration_ReleasePlan">TeamCity release plan</a> configuration and open the VCS settings. If the VCS root attached to the configuration is not your GitHub fork, attach your VCS root, or create a new VCS root if you haven’t done it already. The VCS root MUST have write access using the token authentication.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_trigger_the_release">Trigger the release</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>Go to the <a href="http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_ReleasePlan&tab=artifactory">Artifactory Release Management tab</a> and fill the form appropriately:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p><em>groovyVersion</em></p>
+<div class="ulist">
+<ul>
+<li>
+<p><em>release version</em> must be set to the version number of Groovy you are releasing. For example <code>2.4.6</code>.</p>
+</li>
+<li>
+<p><em>next integration version</em> <strong>must</strong> be set to the subsequent version number of Groovy you are releasing and as it will be a development version, <strong>must</strong> end with <code>-SNAPSHOT</code>. For example <code>2.4.5-SNAPSHOT</code>.</p>
+</li>
+</ul>
+</div>
+</li>
+<li>
+<p><em>groovyBundleVersion</em></p>
+<div class="ulist">
+<ul>
+<li>
+<p><em>release version</em> must be set to the OSGi bundle version number of Groovy you are releasing. For example <code>2.4.6</code>.</p>
+</li>
+<li>
+<p><em>next integration version</em> <strong>must</strong> be set to the subsequent OSGi bundle version number of Groovy you are releasing and as it will be a development version, <strong>must</strong> end with <code>.SNAPSHOT</code>. For example <code>2.4.5.SNAPSHOT</code>.</p>
+</li>
+</ul>
+</div>
+</li>
+<li>
+<p><em>Checkout branch:</em> must be set to the branch you are releasing. For example, if you are releasing a 2.4.x version of Groovy, <code>GROOVY_2_4_X</code>.</p>
+</li>
+<li>
+<p><em>Use release branch</em> must be checked, and it will automate the creation of a release branch. Use a branch name in the form of <code>REL_BRANCH_2_4_3</code></p>
+</li>
+<li>
+<p><em>Create VCS tag</em> must be checked, and it will automate the creation of a release tag. Use a tag name in the form of <code>GROOVY_2_4_4</code></p>
+</li>
+<li>
+<p><em>Tag comment</em> must be set to something useful describing the release version</p>
+</li>
+<li>
+<p><em>Repository to stage the release to (Artifactory Pro):</em> must be set to <code>oss-release-local</code></p>
+</li>
+<li>
+<p><em>Staging comment</em> should be set with something useful like <code>release of Groovy 2.4.6</code></p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>Hit the release button.</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_upload_to_apache_servers">Upload to Apache servers</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>At this point, if the release build was successful, artifacts are staging on Bintray. You must log into Bintray and download the distribution artifacts. The URL for
+the staging distribution should be in the form of <a href="https://bintray.com/groovy/maven/groovy/2.4.6">https://bintray.com/groovy/maven/groovy/2.4.6</a>.</p>
+</div>
+<div class="paragraph">
+<p>Downloads of the following files are only possible if you use the (groovy-operator,<api key>) credentials. If you don’t have them please ask one of the PPMC members:</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>apache-groovy-src-<em>version</em>.zip</p>
+</li>
+<li>
+<p>apache-groovy-binary-<em>version</em>.zip</p>
+</li>
+<li>
+<p>apache-groovy-docs-<em>version</em>.zip</p>
+</li>
+<li>
+<p>apache-groovy-sdk-<em>version</em>.zip</p>
+</li>
+</ul>
+</div>
+<div class="paragraph">
+<p>as well as the corresponding <em>asc</em> and <em>md5</em> files. There should therefore be a total of <em>12</em> files.</p>
+</div>
+<div class="admonitionblock note">
+<table>
+<tr>
+<td class="icon">
+<div class="title">Note</div>
+</td>
+<td class="content">
+at this point it is possible that the MD5 files are missing, in which cases you would have to create them locally before uploading to Apache.
+</td>
+</tr>
+</table>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>for f in `ls *.zip`; do md5sum $f > $f.md5; done</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>It is in general not accepted that the release is signed using the CI server key, so you <strong>must</strong> replace the signatures with your own. If you didn’t yet,
+add your public key to the <code>KEYS</code> file, then sign each zip individually. This can be done, for each file, with a command line like:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>gpg --armor --output apache-groovy-src-2.4.6.zip.asc --detach-sign apache-groovy-src-2.4.6.zip</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Now you are ready to upload to the dev space on <em>dist.apache.org</em>. First of all, please make sure your local layout
+looks like this:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>|-- KEYS
|-- 2.4.6
| |
| -- distribution
@@ -173,38 +282,49 @@ looks like this:
| |-- sources
|-- apache-groovy-src-2.4.6.zip
|-- apache-groovy-src-2.4.6.zip.asc
- `-- apache-groovy-src-2.4.6.zip.md5
-```
-
-Then you need to perform the upload:
-
-```
-svn https://dist.apache.org/repos/dist/dev/incubator/groovy groovy-release
+ `-- apache-groovy-src-2.4.6.zip.md5</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>Then you need to perform the upload:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>svn https://dist.apache.org/repos/dist/dev/incubator/groovy groovy-release
cd groovy-release
-cp -r ../path/to/local/groovy/<version> .
-svn add <version>
-svn ci <version>
-```
-
-== Push the tag and new HEAD
-
-```
-git fetch origin --tags
+cp -r ../path/to/local/groovy/<version> .
+svn add <version>
+svn ci <version></code></pre>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_push_the_tag_and_new_head">Push the tag and new HEAD</h2>
+<div class="sectionbody">
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>git fetch origin --tags
git push upstream GROOVY_2_4_4
-git push upstream GROOVY_2_4_X
-```
-
-== Send a [VOTE] thread
-
-You can use the following template to send a VOTE thread on the dev@ list:
-
-```
-Dear community,
+git push upstream GROOVY_2_4_X</code></pre>
+</div>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_send_a_vote_thread">Send a [VOTE] thread</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>You can use the following template to send a VOTE thread on the dev@ list:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>Dear community,
I am happy to start the VOTE thread for a Groovy x.y.z!
This release includes bugfixes for ...
-The changelog for this release can be found here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12331941
+The changelog for this release can be found here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12331941
Tag: https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=19f70958f39f0cc5c6b4d3e9471fd297400647d2
@@ -222,18 +342,20 @@ The vote is open for the next 72 hours and passes if a majority of at least thre
Here is my vote:
-+1 (binding)
-```
-
-After 72h, send another email summarizing the result of the vote. If it passed, you *must* send another vote to
-`general@incubator.apache.org` to ask the IPMC to vote:
-
-```
-Hi all!
++1 (binding)</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>After 72h, send another email summarizing the result of the vote. If it passed, you <strong>must</strong> send another vote to
+<code>general@incubator.apache.org</code> to ask the IPMC to vote:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>Hi all!
The Apache Groovy PMC has successfully voted the release of Apache Groovy 2.4.6 [1], with 6 "+1" binding votes, one "+1" non binding, no "0" votes and one "-1" vote (see the explanation below). We are now asking the IPMC to vote it too. Since it is our first release under the Apache Software Foundation umbrella, let me give a few more details:
-<description of the release>
+<description of the release>
Vote on dev list: http://mail-archives.apache.org/mod_mbox/groovy-dev/201507.mbox/%3CCADQzvm%3DzDNCxpOua3LQ1ZNo62Aq40QZM7SJwgER5MfkArWrTeA%40mail.gmail.com%3E
Result of vote on dev list: http://mail-archives.apache.org/mod_mbox/groovy-dev/201507.mbox/%3CCADQzvmn1yEMMz_ZaCL5QqqUtQJdgd0NNcy8v7BVY8Lt4Uog0Zg%40mail.gmail.com%3E
@@ -241,10 +363,10 @@ Relicensing of the documentation tracking: https://issues.apache.org/jira/browse
Vote for relicensing the docs: http://mail-archives.apache.org/mod_mbox/groovy-dev/201506.mbox/%3CCADQzvm%3DMfajQuMxoZJmpLe%2B4W22a_MDY_dC4W%2BNMWiakEEOyNg%40mail.gmail.com%3E
Result of vote for relicensing the docs: http://mail-archives.apache.org/mod_mbox/groovy-dev/201506.mbox/%3CCADQzvmkQyOEk3ofOrnTHfnvTKO5xECY87hKAGf5pD%2BuePyA8UA%40mail.gmail.com%3E
-The changelog for this release can be found here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12331941
+The changelog for this release can be found here: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12331941
Tag for the release: https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=commit;h=716b0b1bd56eeab04e4441eecc91c2cd8bfda8b6
-<https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=19f70958f39f0cc5c6b4d3e9471fd297400647d2>
+<https://git1-us-west.apache.org/repos/asf?p=groovy.git;a=tag;h=19f70958f39f0cc5c6b4d3e9471fd297400647d2>
The artifacts to be voted on are located here: https://dist.apache.org/repos/dist/dev/incubator/groovy/
@@ -254,43 +376,85 @@ Vote is open for at least 72 hours. Artifacts will be moved to dist as soon as t
[ ] +1, release Apache Groovy 2.4.6
[ ] 0, I don't care
-[ ] -1, because...
-```
-
-If the vote passes:
-
-== Publish the release
-
-* Open `https://bintray.com/groovy/maven/groovy/2.4.6` and click `Publish` on the notice message (something like `ou have 532 unpublished item(s) for this version (expiring in 21 hours)`)
-* Perform Maven Central synchronization: on https://bintray.com/groovy/maven/groovy/2.4.6/view?sort=&order=#central[this page (update the link to the appropriate version)], click 'sync'. This step may take several minutes to complete.
-* Update the documentation symlinks on the website. You need credentials on the server:
-```
-cd /var/www/docs/docs
+[ ] -1, because...</code></pre>
+</div>
+</div>
+<div class="paragraph">
+<p>If the vote passes:</p>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_publish_the_release">Publish the release</h2>
+<div class="sectionbody">
+<div class="ulist">
+<ul>
+<li>
+<p>Open <code><a href="https://bintray.com/groovy/maven/groovy/2.4.6" class="bare">https://bintray.com/groovy/maven/groovy/2.4.6</a></code> and click <code>Publish</code> on the notice message (something like <code>ou have 532 unpublished item(s) for this version (expiring in 21 hours)</code>)</p>
+</li>
+<li>
+<p>Perform Maven Central synchronization: on <a href="https://bintray.com/groovy/maven/groovy/2.4.6/view?sort=&order=#central">this page (update the link to the appropriate version)</a>, click 'sync'. This step may take several minutes to complete.</p>
+</li>
+<li>
+<p>Update the documentation symlinks on the website. You need credentials on the server:</p>
+</li>
+</ul>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>cd /var/www/docs/docs
rm -f latest
-ln -s groovy-2.4.6 latest
-```
-* Publish to GVM. Open http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_GvmPublish[the publish configuration], click on the 3 dots near `run` then on the _parameters_ tab, fill
-in the `groovyVersion` parameter. Click on `run build`.
-* if the release is NOT a beta or a release candidate, make it the default version on GVM. Open http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_GvmMakeDefault[the GVM make default configuration], click on the 3 dots near `run` then on the _parameters_ tab, fill
-in the `groovyVersion` parameter. Click on `run build`.
-
-== Update the website
-
-If you don't have it locally, checkout `https://github.com/groovy/groovy-website`.
-
-* Update the https://github.com/melix/groovy-website/blob/master/site/src/site/sitemap.groovy[site map] to include the newly released version.
-* Push the changes
-* Wait for the http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_Website[CI website deployment build] to complete.
-
-== Send an announcement email
-
-You should wait 24h before doing this (in order for `dist.apache.org` to be properly mirrored).
-Email `dev@`, `user@` and `announce@apache.org`.
-
-You can use this template. Please make sure that the email at least contains the DISCLAIMER:
-
-```
-Dear community,
+ln -s groovy-2.4.6 latest</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Publish to GVM. Open <a href="http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_GvmPublish">the publish configuration</a>, click on the 3 dots near <code>run</code> then on the <em>parameters</em> tab, fill
+in the <code>groovyVersion</code> parameter. Click on <code>run build</code>.</p>
+</li>
+<li>
+<p>if the release is NOT a beta or a release candidate, make it the default version on GVM. Open <a href="http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_GvmMakeDefault">the GVM make default configuration</a>, click on the 3 dots near <code>run</code> then on the <em>parameters</em> tab, fill
+in the <code>groovyVersion</code> parameter. Click on <code>run build</code>.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_update_the_website">Update the website</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>If you don’t have it locally, checkout <code><a href="https://github.com/groovy/groovy-website" class="bare">https://github.com/groovy/groovy-website</a></code>.</p>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Update the <a href="https://github.com/melix/groovy-website/blob/master/site/src/site/sitemap.groovy">site map</a> to include the newly released version.</p>
+</li>
+<li>
+<p>Push the changes</p>
+</li>
+<li>
+<p>Wait for the <a href="http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_Website">CI website deployment build</a> to complete.</p>
+</li>
+</ul>
+</div>
+</div>
+</div>
+<div class="sect1">
+<h2 id="_send_an_announcement_email">Send an announcement email</h2>
+<div class="sectionbody">
+<div class="paragraph">
+<p>You should wait 24h before doing this (in order for <code>dist.apache.org</code> to be properly mirrored).
+Email <code>dev@</code>, <code>user@</code> and <code>announce@apache.org</code>.</p>
+</div>
+<div class="paragraph">
+<p>You can use this template. Please make sure that the email at least contains the DISCLAIMER:</p>
+</div>
+<div class="listingblock">
+<div class="content">
+<pre class="prettyprint highlight"><code>Dear community,
We are pleased to announce the first release of Apache Groovy done under the Apache Software Foundation
Incubator sponsorship! Apache Groovy is a multi-facet programming language for the JVM. Details can be
@@ -310,13 +474,19 @@ We would like to thank all people who contributed to this release. In particular
having hard days at explaining the Apache Way :) Despite comments we received about this release, we felt that
the security issue is so important that we deserved this to our community.
-Best regards,
-
-```
-
-* Broadcast the release on GVM. Open http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_GvmBroadcast[the GVM broadcast configuration], click on the 3 dots near `run` then on the _parameters_ tab, fill
-in the `groovyVersion` parameter. Click on `run build`.
-</asciidocText><div id='content' class='page-1'><div class='row'><div class='row-fluid'><div class='col-lg-3'><ul class='nav-sidebar'><li class='active'><a href='#doc'>Initial release process proposal</a></li></ul></div><div class='col-lg-8 col-lg-pull-0'><a name='doc'></a><h1>Initial release process proposal</h1><hr/></div></div></div></div><footer id='footer'>
+Best regards,</code></pre>
+</div>
+</div>
+<div class="ulist">
+<ul>
+<li>
+<p>Broadcast the release on GVM. Open <a href="http://ci.groovy-lang.org/viewType.html?buildTypeId=Groovy_BintrayIntegration_GvmBroadcast">the GVM broadcast configuration</a>, click on the 3 dots near <code>run</code> then on the <em>parameters</em> tab, fill
+in the <code>groovyVersion</code> parameter. Click on <code>run build</code>.</p>
+</li>
+</ul>
+</div>
+</div>
+</div></div></div></div></div><footer id='footer'>
<div class='row'>
<div class='colset-3-footer'>
<div class='col-1'>