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 2022/10/20 10:38:01 UTC
[groovy-dev-site] branch asf-site updated: 2022/10/20 10:37:59: Generated dev website from groovy-website@bb3262c
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 2e43d2f 2022/10/20 10:37:59: Generated dev website from groovy-website@bb3262c
2e43d2f is described below
commit 2e43d2f6286d51c7298e73d2283a202fe4d8ca84
Author: jenkins <bu...@apache.org>
AuthorDate: Thu Oct 20 10:37:59 2022 +0000
2022/10/20 10:37:59: Generated dev website from groovy-website@bb3262c
---
wiki/GEP-11.html | 62 +++++++++++++++---------------
wiki/GEP-12.html | 8 ++--
wiki/GEP-2.html | 10 ++---
wiki/GEP-3.html | 20 +++++-----
wiki/GEP-4.html | 8 ++--
wiki/GEP-6.html | 2 +-
wiki/GEP-7.html | 2 +-
wiki/GEP-9.html | 6 +--
wiki/groovy-release-discussion.html | 4 +-
wiki/initial-release-process-proposal.html | 12 +++---
10 files changed, 67 insertions(+), 67 deletions(-)
diff --git a/wiki/GEP-11.html b/wiki/GEP-11.html
index cc89810..328aa0f 100644
--- a/wiki/GEP-11.html
+++ b/wiki/GEP-11.html
@@ -162,9 +162,9 @@ But since this is a confusing feature of limited use, it should be removed.</p>
<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
+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 an syntax element, making this automatic feature not needed.
+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.
@@ -175,7 +175,7 @@ Looking at user code you will find barely intended usages of this. Thus it shoul
<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 intend of safe navigation to avoid a NullPointerException. Thus this should be changed to stop the
+This defies the intent of safe navigation to avoid a NullPointerException. Thus this should be changed to stop the
evaluation of the path expression.</p>
</div>
</div>
@@ -196,7 +196,7 @@ Not only because of bugs like GROOVY-5019 there should be a replacement of the I
</div>
</div>
<div class="sect2">
-<h3 id="_some_of_the_leading_design_ideas_of_this_mop">Some of the leading design ideas of this MOP</h3>
+<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,
@@ -214,7 +214,7 @@ missing methods, as well as being able to invalidate a cached version and/or to
<p><span class="image"><img src="img/mop_2.jpg" alt="image"></span></p>
</div>
<div class="paragraph">
-<p>in meta class of x in pseudo code:</p>
+<p>in metaclass of x in pseudocode:</p>
</div>
<div class="listingblock">
<div class="content">
@@ -234,13 +234,13 @@ invoke(cachable)</code></pre>
<li>
<p>getMethodInterceptor<br>
Extension point for the user to register an interceptor, that will be used for all method calls.
-This is equal what GroovyInterceptable does using invokeMethod, only that in MOP1 the method is directly called.
+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</p>
</li>
<li>
<p>getFittingMethod<br>
-Predefined way to select a method through meta class. This method will return an
+Predefined way to select a method through metaclass. This method will return an
object which then can be used to invoke the selected method.</p>
</li>
<li>
@@ -250,7 +250,7 @@ The then invoked method is comparable to what methodMissing in MOP1 would be doi
</li>
<li>
<p>MethodMissingException<br>
-thrown if none of the above methods is bearing a non null result</p>
+thrown if none of the above methods is bearing a non-null result</p>
</li>
<li>
<p>storeInCallSite<br>
@@ -267,26 +267,26 @@ Predefined method to do the Initial invocation of the cachable. Subsequent invoc
<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 meta classes with a context element and an always existing default.
+<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" meta class, which won’t get influenced by outside
-meta classes or to allow for example calling private methods and not allowing them in other cases.
-This makes 3 possible meta class variations currently:</p>
+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:</p>
</div>
<div class="ulist">
<ul>
<li>
-<p>Default meta class<br>
-Behaves pretty much like what Java allows in regards of method calls (same class private methods are available)
+<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</p>
</li>
<li>
-<p>Sealed meta class<br>
-Like the default meta class, but meta programming changes from outside the class are not visible.
+<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.</p>
</li>
<li>
-<p>Test meta class (un)sealed<br>
+<p>Test metaclass (un)sealed<br>
Like the two before but with the addition that private members will always be available.</p>
</li>
</ul>
@@ -295,11 +295,11 @@ Like the two before but with the addition that private members will always be av
<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 meta class that can be generated without its context.
+<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 meta class could be stored later in the call site object context changes are to be avoided,
+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.</p>
</div>
</div>
@@ -321,7 +321,7 @@ A call m() with the SSC A and done on an instance of B (extends A) will be using
</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 mutimethods are not visible. Thus we can directly use the meta class super(SSC), but we will dispatch only on the public methods of that meta class.</p>
+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">
@@ -378,19 +378,19 @@ It would be great if this mechanism be made pluggable.</p>
<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 meta classes.
+<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 meta class change is visible in a realm, if the change is done to the meta class in
-the same realm or to a meta class in a higher realm.
-Script execution engines are able to set a realm for example to prevent them changing meta classes they should not change.
-This can be used for unit tests to isolate meta class changes done during the tests as well.
+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.
+Script execution engines are able to set a realm for example to prevent them changing metaclasses they should not change.
+This can be used for unit tests to isolate metaclass changes done during the tests as well.
A library can have its own realm (defined through an annotation) to prevent other classes to
leak their changes into that library, while the library can still use a higher realm to make
changes more public visible, if the realm allows that. Realms can have a setting that prevents
code executed from there to make changes to higher realms. Calling a method is always done using
-the meta classes from the current realm, even if the called class then calls other classes 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 meta class flavor, to for example allow access to private methods and fields.</p>
+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">
@@ -404,16 +404,16 @@ A realm can also use a different meta class flavor, to for example allow access
<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 ScriptBytecodeAdpater as well as all the custom call site caching classes</p>
+<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 meta class into an immutable</p>
+<p>turn metaclass into an immutable</p>
</li>
<li>
-<p>implement meta class views</p>
+<p>implement metaclass views</p>
</li>
</ul>
</div>
@@ -566,7 +566,7 @@ A realm can also use a different meta class flavor, to for example allow access
<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>
+feature branch on GitHub</p>
</li>
</ul>
</div>
diff --git a/wiki/GEP-12.html b/wiki/GEP-12.html
index 56b17ac..341d03d 100644
--- a/wiki/GEP-12.html
+++ b/wiki/GEP-12.html
@@ -139,9 +139,9 @@ A SAM type is an abstract class or interface with a single abstract method.
SAM coercion involves transforming a
<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 of the types provided by Closure itself,
+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 sub type to all SAM types.
+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.</p>
</div>
@@ -241,7 +241,7 @@ interface SAM extends ParentOfSAM {}</code></pre>
<div class="ulist">
<ul>
<li>
-<p>abstract class with a abstract and a non abstract method:</p>
+<p>abstract class with an abstract and a non-abstract method:</p>
</li>
</ul>
</div>
@@ -443,7 +443,7 @@ found here: <a href="http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.1/F.html" cl
<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>
+<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>
diff --git a/wiki/GEP-2.html b/wiki/GEP-2.html
index 5f1b2ab..666198c 100644
--- a/wiki/GEP-2.html
+++ b/wiki/GEP-2.html
@@ -278,7 +278,7 @@ def statementBlock = builder.buildFromCode (CompilePhase.CONVERSION, true) {
<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>
+<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>
@@ -288,7 +288,7 @@ def statementBlock = builder.buildFromCode (CompilePhase.CONVERSION, true) {
</li>
<li>
<p>Converting from a closure into AST is performed through a global compiler transformation.
-This requires that the AstBuilder reference be strongly typed so that the global annotation can be triggered.</p>
+This requires the AstBuilder reference to be strongly typed so that the global annotation can be triggered.</p>
</li>
</ul>
</div>
@@ -309,7 +309,7 @@ This requires that the AstBuilder reference be strongly typed so that the global
<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 of the builder.
+<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">
@@ -324,7 +324,7 @@ List<ASTNode> source = { println "compiled on: ${new Date()}" }</code></pr
</div>
</div>
<div class="sect2">
-<h3 id="_astnode_from_psuedo_specification">ASTNode from psuedo-specification</h3>
+<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>
@@ -445,7 +445,7 @@ Quasi-quote (or Oxford quotes) can be used to trigger an AST building operation:
<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>
+<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>
diff --git a/wiki/GEP-3.html b/wiki/GEP-3.html
index f5883e9..ab10225 100644
--- a/wiki/GEP-3.html
+++ b/wiki/GEP-3.html
@@ -396,10 +396,10 @@ commas if multiple arguments are used. A case that is not supported today anyway
<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 (ie. a method call foo(), foo{}, or some expression like x+y)</p>
+<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 (ie. send "hello" to "Guillaume"
+<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>
@@ -408,7 +408,7 @@ is two methods chained one after the other as send("hello").to("Guillaume"))</p>
<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, so as to "build" a new object.
+<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">
@@ -438,7 +438,7 @@ WHERE "column_name" IN ('value1', 'value2', ...)</code></pre>
</div>
</div>
<div class="paragraph">
-<p>In current Groovy this could maybe expressed by</p>
+<p>In current Groovy this could be expressed by</p>
</div>
<div class="listingblock">
<div class="content">
@@ -462,7 +462,7 @@ WHERE "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 diifivult to span the DSL across multiple lines. A more extended example would be</p>
+<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">
@@ -472,7 +472,7 @@ 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 mabye</p>
+<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">
@@ -512,7 +512,7 @@ marinate 30.minutes at roomTemperature</code></pre>
<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-leval 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>
+<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">
@@ -550,7 +550,7 @@ marinate 30.minutes at roomTemperature</code></pre>
</div>
</div>
<div class="paragraph">
-<p>has to be supported. This seems to not to be a valid version in Scala, since that would be interpreted as</p>
+<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">
@@ -582,7 +582,7 @@ marinate 30.minutes at roomTemperature</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>
+<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">
@@ -597,7 +597,7 @@ marinate 30.minutes at roomTemperature</code></pre>
<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" (ie. a method name or a parameter).</p>
+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">
diff --git a/wiki/GEP-4.html b/wiki/GEP-4.html
index 5fd0b6b..a0d274a 100644
--- a/wiki/GEP-4.html
+++ b/wiki/GEP-4.html
@@ -143,7 +143,7 @@
<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 generate the AST from a piece of code. Currently, the AstBuilder fromCode API
+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.
@@ -247,14 +247,14 @@ methodNode.code = newMethod[0]</code></pre>
<p>Template Haskell uses something similar to oxford brackets but with slightly different semantics</p>
</li>
<li>
-<p>Boo uses uses GEP 4 - AstBuilder AST Templates and $ but with slightly different semantics</p>
+<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 Meta Method Comparison
-The Boo Metamethod feature overlaps with the Groovy AST Transformation features. Instead of an @AstTransformation interface with a seperately defined AstTransformation subclass, Boo offers Meta methods, where the AST Transformation is called and generated at compile time.</p>
+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.</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>
diff --git a/wiki/GEP-6.html b/wiki/GEP-6.html
index f8bc3c9..bd56522 100644
--- a/wiki/GEP-6.html
+++ b/wiki/GEP-6.html
@@ -179,7 +179,7 @@ then we risk having JDK7 make an API change, which would force us to support 2 d
<p>Support new Path object</p>
</li>
<li>
-<p>All of the GDK File API needs to be on Path</p>
+<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
diff --git a/wiki/GEP-7.html b/wiki/GEP-7.html
index 2f0a547..aff0477 100644
--- a/wiki/GEP-7.html
+++ b/wiki/GEP-7.html
@@ -211,7 +211,7 @@ println builder.toString()
</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>
+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">
diff --git a/wiki/GEP-9.html b/wiki/GEP-9.html
index 995ae86..6ae9278 100644
--- a/wiki/GEP-9.html
+++ b/wiki/GEP-9.html
@@ -194,7 +194,7 @@ changes to the Groovy classes which are orthogonal to eventually using something
<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 of the classes from the module jars</p>
+<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>
@@ -338,7 +338,7 @@ org.codehaus.groovy.runtime.DefaultMetaClasses</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">should there by a way to 'publish' new commandline level startup scripts e.g. java2groovy</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>
@@ -360,7 +360,7 @@ org.codehaus.groovy.runtime.DefaultMetaClasses</code></p></td>
</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>
+<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>
diff --git a/wiki/groovy-release-discussion.html b/wiki/groovy-release-discussion.html
index 288b011..23b1b14 100644
--- a/wiki/groovy-release-discussion.html
+++ b/wiki/groovy-release-discussion.html
@@ -202,7 +202,7 @@ Many of the ideas went into Groovy’s current release process which involve
</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 [...]
+<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>
@@ -278,7 +278,7 @@ Many of the ideas went into Groovy’s current release process which involve
</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 [...]
+<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>
diff --git a/wiki/initial-release-process-proposal.html b/wiki/initial-release-process-proposal.html
index 4392691..ea30ee0 100644
--- a/wiki/initial-release-process-proposal.html
+++ b/wiki/initial-release-process-proposal.html
@@ -53,7 +53,7 @@
</ul>
</div>
</div>
- </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='#_setup_the_teamcit [...]
+ </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>
@@ -76,7 +76,7 @@ If any of the steps in the automated process fail, this documentation might prov
<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 with regards to comments from the community, mentors and IPMC.</p>
+<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>
@@ -133,7 +133,7 @@ git push origin GROOVY_2_4_X</code></pre>
</div>
</div>
<div class="sect1">
-<h2 id="_setup_the_teamcity_release_configuration">Setup the TeamCity release configuration</h2>
+<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>
@@ -175,7 +175,7 @@ git push origin GROOVY_2_4_X</code></pre>
</div>
</li>
<li>
-<p><em>Checkout branch:</em> must be set to the branch your are releasing. For example, if you are releasing a 2.4.x version of Groovy, <code>GROOVY_2_4_X</code>.</p>
+<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>
@@ -416,7 +416,7 @@ in the <code>groovyVersion</code> parameter. Click on <code>run build</code>.</p
</div>
</div>
<div class="sect1">
-<h2 id="_update_the_web_site">Update the web site</h2>
+<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>
@@ -441,7 +441,7 @@ in the <code>groovyVersion</code> parameter. Click on <code>run build</code>.</p
<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).
-Send an email to <code>dev@</code>, <code>user@</code> and <code>announce@apache.org</code>.</p>
+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>