You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@groovy.apache.org by pa...@apache.org on 2017/04/25 23:06:02 UTC
[02/20] groovy-user-site git commit: move content to asf-site branch
http://git-wip-us.apache.org/repos/asf/groovy-user-site/blob/de805f31/site/src/site/releasenotes/groovy-2.3.adoc
----------------------------------------------------------------------
diff --git a/site/src/site/releasenotes/groovy-2.3.adoc b/site/src/site/releasenotes/groovy-2.3.adoc
deleted file mode 100644
index ce0e923..0000000
--- a/site/src/site/releasenotes/groovy-2.3.adoc
+++ /dev/null
@@ -1,834 +0,0 @@
-Groovy 2.3 is the new major release of Groovy, featuring
-official *support for running Groovy on JDK 8*, *traits*, new and improved
-AST transformations like `@TailRecursive`, `@Builder` and `@Sortable`, a
-new _NIO2 module_ with `Path` support, *lightening fast JSON* parsing and
-building,*closure parameter type inference*, a new *markup template engine*,
-Groovysh and GroovyConsole ease of use improvements, a
-new `GroovyAssert` test utility, more `@BaseScript` class capabilities,
-and more.
-
-[[Groovy2.3releasenotes-OfficialsupportforrunningGroovyonJDK8]]
-== Official support for running Groovy on JDK 8
-
-This is the first version of Groovy to be officially compatible with JDK
-8.
-
-JDK 8 and its interface default methods introduced some
-incompatibilities with a few methods of the Groovy Development Kit, so
-we had to adapt to the situation, introducing minor breaking changes for
-the affected methods and their outcome.
-
-Note that we\u2019re not planning to backport the changes to older versions
-of Groovy, so if you want to run Groovy on JDK 8, you\u2019ll have to upgrade
-to the shiniest version of Groovy!
-
-Groovy 2.3 doesn\u2019t support the new syntax constructs offered by Java 8
-(such as lambdas, method references, default methods in interfaces,
-etc), but you can very well already *use the new APIs offered by JDK
-8*, and even *use Groovy closures in lieu of Java 8 lambdas*.
-
-For reference, here are a couple of examples which use Java 8 streams,
-for iterating over a stream of ints, or over the lines of a file:
-
-[source,groovy]
-----
-IntStream.range(1, 100).forEach { println it }
-
-Files.lines(Paths.get('README.adoc'))
- .map { it.toUpperCase() }
- .forEach { println it }
-----
-
-
-In particular, in the two statements above, notice that we replaced Java
-8 lambdas with Groovy closures, as Groovy provides a closure coercion
-mechanism which transforms a Groovy closure into a functional interface
-\u2014 unlike Java, Groovy also provides that coercion mechanism for abstract
-classes containing a single abstract method.
-
-In future versions of Groovy, certain Java 8 syntax constructs, or
-particular Groovy methods decorating JDK 8 APIs might be added.
-
-[[Groovy2.3releasenotes-Traits]]
-== Traits
-
-A major highlight for Groovy 2.3 is the introduction of the *concept of traits*.
-
-link:{DOCS_BASEURL}/html/documentation/core-traits.html[Traits]
-are reusable components of behavior that your classes can implement, and
-are an additional Object-Oriented concept alongside classes and
-interfaces.
-
-Below, we create a trait with a concrete method `fly()` which returns a
-`String`.
-
-[source,groovy]
-----
-trait FlyingAbility {
- String fly() { "I'm flying!" }
-}
-----
-
-Then we create a class, `Bird`, that implements that trait, and
-instantiate it:
-
-[source,groovy]
-----
-class Bird implements FlyingAbility {}
-def b = new Bird()
-----
-
-We can check that the Bird instance does have the new `fly()` method
-mixed-in:
-
-[source,groovy]
-----
-assert b.fly() == "I'm flying!"
-----
-
-Groovy traits are stateful (unlike Java 8 interface default methods).
-A trait can have Groovy properties like plain classes:
-
-[source,groovy]
-----
-trait Named {
- String name
-}
-----
-
-This time, the `Bird` class implements that `Named` trait:
-
-[source,groovy]
-----
-class Bird implements Named {}
-----
-
-We can instantiate the Bird with the named-argument constructor shortcut
-provided by Groovy:
-
-[source,groovy]
-----
-def b = new Bird(name: 'Colibri')
-----
-
-We assert that the instantiated Bird does have the name property added
-to it:
-
-[source,groovy]
-----
-assert b.name == 'Colibri'
-----
-
-They allow the composition of behavior without going into the "diamond
-inheritance" problem allowing you to decide which behavior prevails
-upon conflict, either by convention (last trait declared wins) or by
-explicitly overriding the conflicting method:
-
-[source,groovy]
-----
-trait KiteSurfer { String surf() { 'kite' } }
-
-trait WebSurfer { String surf() { 'web' } }
-
-class Person { String name }
-
-class Hipster extends Person
- implements KiteSurfer, WebSurfer {}
-
-def h = new Hipster()
-assert h.surf() == 'web'
-----
-
-Above, the `surf()` method from `WebSurfer` wins, as it\u2019s the last declared
-trait, but you can reverse the trait implementation order if you want
-kite to be returned. If you want to be more explicit, your `Hipster` class
-can override the `surf()` method itself, and call `WebSurfer.super.foo()` or
-`KiteSurfer.super.foo()` or do something entirely different.
-
-Traits support inheritance, thus a trait can extend another trait or
-implement an interface, as shown below:
-
-[source,groovy]
-----
-trait Named { String name }
-
-trait FlyingAbility extends Named {
- String fly() { "I'm a flying ${name}!" }
-}
-
-class Bird implements FlyingAbility {}
-def b = new Bird(name: 'Colibri')
-
-assert b.name == 'Colibri'
-assert b.fly() == "I'm a flying Colibri!"
-----
-
-Traits are compatible with static type checking and compilation, as well
-as our usual dynamic behavior. Trait mixed-in methods are actually
-"real" methods (ie. visible from Java as well) and not just dynamic.
-Note however, that not all existing AST transformations are compatible
-with traits.
-
-Traits can also be implemented at runtime with `as` or with
-`withTraits` if you just want to add behavior of a trait to an object
-you\u2019re instantiating, without having to create an intermediary
-artificial class just for that purpose (also called per-instance
-traits):
-
-[source,groovy]
-----
-trait Named { String name }
-
-trait Quacks {
- String quack() { 'Quack!' }
-}
-
-class Animal {}
-
-def na = new Animal().withTraits Named, Quacks
-na.name = 'Daffy'
-assert na.name == 'Daffy'
-assert na.quack() == 'Quack!'
-----
-
-You can find more information on traits in the
-exhaustive link:{DOCS_BASEURL}/html/documentation/core-traits.html[traits documentation].
-
-[[Groovy2.3releasenotes-NewandupdatedASTtransformations]]
-== New and updated AST transformations
-
-[[Groovy2.3releasenotes-Newtransformations]]
-=== New transformations
-
-[[Groovy2.3releasenotes-TailRecursive]]
-==== @TailRecursive
-
-`@TailRecursive` on methods adds tail recursion to methods which are
-recursive and call themselves at the last operation of the method body,
-which helps avoid blowing up the stack with the recursive calls
-(link:https://issues.apache.org/jira/browse/GROOVY-6570[GROOVY-6570]).
-
-Here\u2019s a slightly rewritten factorial implementation, that is friendly
-to tail-call transformation:
-
-[source,groovy]
-----
-import groovy.transform.TailRecursive
-
-@TailRecursive
-def fact(BigInteger n, accu = 1G) {
- if (n < 2) accu
- else fact(n - 1, n * accu)
-}
-
-assert fact(1000) > 10e2566
-----
-
-[[Groovy2.3releasenotes-Builder]]
-==== @Builder
-
-Recent Java APIs have adopted the builder pattern (not to be confused
-with Groovy\u2019s builders) to instantiate complex objects, without
-requiring to multiply the number of constructors with variants taking
-various combination of parameters. Groovy 2.3 introduces a `@Builder`
-transformation to automate the creation of such builder APIs
-(link:https://issues.apache.org/jira/browse/GROOVY-6484[GROOVY-6484]).
-
-The `@Builder` transformation offers different implementation strategies
-that you can choose from:
-
-* a simple strategy for creating chained setters
-* an external strategy where you annotate an explicit builder class
-while leaving some buildee class being built untouched
-* a default strategy which creates a nested helper class for instance
-creation
-* and an initializer strategy which creates a nested helper class for
-instance creation which when used with `@CompileStatic` allows type-safe
-object creation
-
-Here\u2019s an example with the default strategy:
-
-[source,groovy]
------
-import groovy.transform.builder.Builder
-
-@Builder
-class Person {
- String firstName
- String lastName
- int age
-}
-
-def person = Person.builder()
- .firstName("Robert")
- .lastName("Lewandowski")
- .age(21)
- .build()
-
-assert person.firstName == "Robert"
-assert person.lastName == "Lewandowski"
-assert person.age == 21
------
-
-You can have a look at
-the link:{DOCS_BASEURL}/html/documentation/core-metaprogramming.html#xform-Builder[@Builder documentation]
-for the other builder variants.
-
-[[Groovy2.3releasenotes-Sortable]]
-==== @Sortable
-
-`@Sortable` on classes implements comparison methods for you (through
-implementing the `Comparable` interface), according to the declaration
-order of your properties
-(link:https://issues.apache.org/jira/browse/GROOVY-6649[GROOVY-6649]).
-
-For the following `Person` class, its instances will be sorted by last
-name, then by first name, and by age, in that order:
-
-[source,groovy]
-----
-import groovy.transform.*
-
-@Sortable
-@Canonical
-class Person {
- String last
- String first
- int age
-}
-
-def folks = [
- new Person('Simpson', 'Bart', 12),
- new Person('Simpson', 'Homer', 40),
- new Person('Kent', 'Clark', 36)
-]
-
-assert folks.sort()*.first == ['Clark', 'Bart', 'Homer']
-----
-
-Additionally, you can define included / excluded fields, access
-individual field comparators with methods like `comparatorByFirst()`.
-
-More details on
-the {DOCS_BASEURL}/html/documentation/core-metaprogramming.html#xform-Sortable[@Sortable documentation] page.
-
-[[Groovy2.3releasenotes-SourceURI]]
-==== @SourceURI
-
-With `@SourceURI`, you can annotate a `java.net.URI` or even a
-`java.lang.String` script variable or class field so that the variable or
-field are injected the URI of the Groovy file.
-
-If you evaluate or compile a Groovy script or class, the variable or
-field will contain a data URI, for example, for the following example:
-
-[source,groovy]
-----
-import groovy.transform.SourceURI
-
-@SourceURI String src
-
-println src
-----
-
-The `src` variable will contain the following data URI:
-
-----
-data:,import%20groovy.transform.SourceURI%0A%0A@SourceURI%20String%20src%0A%0Aprintln%20src
-----
-
-If you save the script in a file called `sourceuri.groovy` in `/tmp`, and
-run that script with the `groovy` command, you\u2019ll see an absolute `File`
-path printed:
-
-----
-file:/tmp/sourceuri.groovy
-----
-
-As we mentioned above, you can also write `@SourceURI URI src`, if you want
-to have a `URI` instead of a `String`.
-
-[[Groovy2.3releasenotes-Updatedtransformations]]
-=== Updated transformations
-
-[[Groovy2.3releasenotes-Delegateimprovements]]
-==== @Delegate improvements
-
-`@Delegate` supports `includeTypes` and `excludeTypes` attributes to give you
-fine-grained control over which methods to include or exclude from
-delegation. Rather than just matching on name, this option matches on
-the name and parameter types expressed in an interface type
-(link:https://issues.apache.org/jira/browse/GROOVY-6329[GROOVY-6329]).
-
-[[Groovy2.3releasenotes-BaseScriptclassimprovements]]
-==== @BaseScript class improvements
-
-{DOCS_BASEURL}/html/gapi/groovy/transform/BaseScript.html[@BaseScript]
-is a fairly recent addition in Groovy, and it allowed to annotate a
-variable in your script to instruct the compiler to use a particular
-base script class for this script. Now we have another notation which is
-nicer as you can annotate an import or a package
-(link:https://issues.apache.org/jira/browse/GROOVY-6592[GROOVY-6592]) to indicate
-that base script class:
-
-[source,groovy]
-----
-@BaseScript(MyScript)
-import groovy.transform.BaseScript
-----
-
-Additionally, base script classes can now use any abstract method for
-the script body. This means that you can implement the `run()` method to
-implement specific behavior like setup and tear down in tests
-(link:https://issues.apache.org/jira/browse/GROOVY-6585[GROOVY-6585]
-and link:https://issues.apache.org/jira/browse/GROOVY-6615[GROOVY-6615]).
-
-Given the following custom base script class, where we implement the
-default `run()` method, we also create a new abstract method called
-`internalRun()`:
-
-[source,groovy]
-----
-abstract class CustomBase extends Script {
- def run() {
- before()
- internalRun()
- after()
- }
-
- abstract internalRun()
-
- def before() { println 'before' }
- def after() { println 'after' }
-}
-----
-
-We can then have the script below transparently implement the
-`internalRun()` method instead of the usual `run()` one:
-
-[source,groovy]
-----
-import groovy.transform.BaseScript
-@BaseScript CustomBase script
-
-println 'Hello'
-----
-
-[[Groovy2.3releasenotes-NewNIOmoduleforJava7]]
-== New NIO module for Java 7+
-
-On JDK 7 and beyond, you can benefit from the same methods as the ones
-of File but for the new NIO2 class `Path`.
-
-See link:https://issues.apache.org/jira/browse/GROOVY-6377[GROOVY-6377] and
-the link:https://github.com/groovy/groovy-core/pull/260/files[pull request]
-for some further hints of the new methods.
-
-You\u2019ll find familiar methods of the Groovy GDK on `File` also available on
-`Path` like these ones:
-
-[source,groovy]
-----
-path.withReader { Reader r -> ... }
-path.eachLine { String line -> ... }
-path.eachFileRecurse { Path p -> ... }
-path << 'some content'
-path << bytes
-path.readLines()
-----
-
-[[Groovy2.3releasenotes-Performanceimprovements]]
-== Performance improvements
-
-[[Groovy2.3releasenotes-Miscellanousimprovements]]
-=== Miscellanous improvements
-
-Various minor *performance improvements across the board*, for static
-compilation, the `invokedynamic` backend, as well as "normal"
-dynamic Groovy, have been worked on.
-
-[[Groovy2.3releasenotes-DrasticJSONparsingandserializationperformanceimprovements]]
-=== Drastic JSON parsing and serialization performance improvements
-
-Groovy JSON support has been refactored and tailored towards
-performance, making Groovy 2.3\u2019s JSON support usually
-*faster than all the JSON libraries* available in the Java ecosystem.
-
-Rick Hightower and Andrey Bleschestov covered the performance gains,
-both in parsing and seralization, in
-a link:http://rick-hightower.blogspot.fr/2014/04/groovy-and-boon-provide-fastest-json.html[benchmarks on Rick\u2019s blog]
-and on link:https://github.com/bura/json-benchmarks[Andrey\u2019s JSON benchmark project on Github].
-The results are impressive, as the *parsing is generally roughly 2x to 4x faster* with Groovy\u2019s new
-parsers compared to existing libraries, and *~21x faster than pre-Groovy 2.3 parsing*.
-On the serialization front, Groovy\u2019s
-new *serialization is also ~17x faster than before*, and at the same
-level as competing libraries.
-
-[[Groovy2.3releasenotes-JSONslurperandbuilderenhancements]]
-== JSON slurper and builder enhancements
-
-Beside the performance improvements of the JSON module, other updates
-have taken place.
-
-With link:{DOCS_BASEURL}/html/gapi/groovy/json/JsonSlurper.html[JsonSlurper],
-you\u2019ll be able to set
-different link:{DOCS_BASEURL}/html/gapi/groovy/json/JsonParserType.html[parser types]
-depending on the kind of input you wish to parse, particularly if
-you know the size of the payload you expect to parse, or whether you
-want a more tolerant parser which accepts elements like comments which
-are not normally supported by the JSON specification.
-
-Here\u2019s an example showing how to parse a non-conformant JSON payload:
-
-[source,groovy]
-----
-import groovy.json.*
-import static groovy.json.JsonParserType.*
-
-def parser = new JsonSlurper().setType(LAX)
-
-def conf = parser.parseText '''
- // configuration file
- {
- // no quote for key, single quoted value
- environment: 'production'
- # pound-style comment
- 'server': 5
- }
-'''
-
-assert conf.environment == 'production'
-assert conf.server == 5
-----
-
-[[Groovy2.3releasenotes-Closureparametertypeinference]]
-== Closure parameter type inference
-
-We closed a gap which forced you to type your closure parameters to get
-correct type inference with static type checking or static compilation
-enabled. In situations like the following, you would have to explicitly
-give the type of the parameter, but it\u2019s no longer required:
-
-[source,groovy]
-----
-['a','b'].each { it.toUpperCase() }
-----
-
-In the signature of your methods taking closures as arguments, you\u2019ll
-also be able to annotate the closure parameter
-with link:{DOCS_BASEURL}/html/gapi/groovy/transform/stc/ClosureParams.html[@ClosureParams]
-to give additional hints to the type checker to infer the type of the
-parameters passed to your closure.
-
-You can also find more about this in C�dric\u2019s blog post
-on link:http://melix.github.io/blog/2014/01/closure_param_inference.html[closure parameter type inference].
-
-[[Groovy2.3releasenotes-Newmarkuptemplateengine]]
-== New markup template engine
-
-Groovy now has an additional template engine, in the form of the Markup
-template engine, which gives you a very fast template engine (thanks to
-static compilation), based on the familiar Markup builder approach and
-notation, but also offering formatting options (indentation, escaping),
-internationalization, includes, as well as proposing type checked
-templates and models.
-
-More details about the
-new link:{DOCS_BASEURL}/html/documentation/markup-template-engine.html[Markup template engine]
-in the documentation, as well as in C�dric\u2019s link:http://melix.github.io/blog/[blog], if you want to learn more
-about the "behind the scenes" stories!
-
-To illustrate the basic usage, consider you have the following template:
-
-[source,groovy]
-----
-def tpl = '''
- cars {
- cars.each {
- car(make: it.make, name: it.name)
- }
- }
-'''
-----
-
-And have the following model:
-
-[source,groovy]
-----
-model = [cars: [
- new Car(make: 'Peugeot', name: '508'),
- new Car(make: 'Toyota', name: 'Prius')
-]]
-----
-
-You would generate the following XML (or HTML) output:
-
-[source,xml]
-----
-<cars>
- <car make='Peugeot' name='508'/>
- <car make='Toyota' name='Prius'/>
-</cars>
-----
-
-By doing the following:
-
-[source,groovy]
-----
-import groovy.text.markup.*
-
-def config = new TemplateConfiguration()
-def engine = new MarkupTemplateEngine(config)
-def tmpl = engine.createTemplate(tpl)
-System.out << tmpl.make(model)
-----
-
-You have useful methods available to your templates, like for including
-other templates:
-
-[source,groovy]
-----
-// include another template
-include template: 'foo.tpl'
-
-// include raw content
-include unescaped: 'raw.txt'
-
-// escape & include
-include escaped: 'to_escape.txt'
-----
-
-And if you want to have your model be type checked, you can either
-define the model types inside the template like so:
-
-[source,groovy]
-----
-modelTypes = {
- List<Car> cars
-}
-----
-
-Or by using the dedicated template creation method:
-
-[source,groovy]
-----
-def modelTypes = [cars: "List<Car>"]
-
-def tmpl = engine.createTypeCheckedModelTemplate(tpl, modelTypes)
-----
-
-Note that this template engine is super fast as it\u2019s statically
-compiled.
-
-[[Groovy2.3releasenotes-JUnit4GroovyAssertclass]]
-== JUnit 4 GroovyAssert class
-
-The
-venerable link:{DOCS_BASEURL}/html/gapi/groovy/util/GroovyTestCase.html[GroovyTestCase]
-(JUnit 3 based approach) has often been used as a base class for your
-test classes \u2014 unless you\u2019ve been using
-the link:http://www.spockframework.org/[Spock testing framework], of course.
-One of the drawback of this class is that your test classes can\u2019t extend
-your own classes, but must derive from `GroovyTestCase` to benefit from
-the additional assertion methods.
-
-In earlier versions of Groovy we introduced the JUnit
-4-friendly link:{DOCS_BASEURL}/html/gapi/groovy/util/GroovyAssert.html[GroovyAssert],
-which is a convenient class offering the usual assertion methods of
-`GroovyTestCase`, but in the form of static methods that you can static
-import in your test class. In Groovy 2.3 we\u2019ve enriched `GroovyAssert`
-with additional features. There should be no reason to move on from
-JUnit 3 if you haven\u2019t already done so. We didn\u2019t include all of the
-myriad of `assertEquals` methods from `GroovyTestCase` as they are typically
-less useful than Groovy\u2019s built-in power assert, but it provides some
-handy `shouldFail()` and `assertScript()` methods
-(link:https://issues.apache.org/jira/browse/GROOVY-6588[GROOVY-6588]).
-
-For instance, if you want to leverage the `shouldFail(String)` and
-`assertScript(String)` methods, you can do so as follows:
-
-[source,groovy]
-----
-import static groovy.test.GroovyAssert.shouldFail
-
-
-import org.junit.Test
-
-class AssertTest {
- @Test void checkBadAddition() {
- shouldFail '''
- groovy.test.GroovyAssert.assertScript 'assert 1 + 1 == 3'
- '''
- }
-}
-----
-
-[[Groovy2.3releasenotes-ConfigSlurper]]
-== ConfigSlurper
-
-ConfigSlurper has previously supported a single "environments"
-non-configurational conditional block, but you couldn\u2019t define your own.
-With Groovy 2.3 you can also create your own such blocks. For instance
-if you wanted to support "flavors" like OS variants
-(link:https://issues.apache.org/jira/browse/GROOVY-6383[GROOVY-6383]).
-
-Concretely, instead of the familiar environments / production blocks in
-Grails, let\u2019s register a flavors / prod pair:�
-
-[source,groovy]
-----
-def conf = '''
- a.b.c = 1
- flavors {
- prod {
- a.b.c = 2
- }
- }
-'''
-
-def slurper = new ConfigSlurper('prod')
-slurper.registerConditionalBlock('flavors', 'prod')
-
-def config = slurper.parse(conf)
-
-assert config.a.b.c == 2
-----
-
-In addition, the `isSet()` / `hasSet()` combo methods
-(link:https://issues.apache.org/jira/browse/GROOVY-4639[GROOVY-4639]) have been
-added so you can double check if a given node of your configuration has
-been defined. Before, whether the node wasn\u2019t defined or containing
-`null`, you couldn\u2019t differentiate either case easily.
-
-[[Groovy2.3releasenotes-Toolsenhancements]]
-== Tools enhancements
-
-[[Groovy2.3releasenotes-Groovysh]]
-=== Groovysh
-
-Along with a slightly reduced startup time, Groovysh has seen new
-improvements in its code-completion capabilities:
-
-* completion for keywords
-(link:https://issues.apache.org/jira/browse/GROOVY-6399[GROOVY-6399])
-* completion for properties
-(link:https://issues.apache.org/jira/browse/GROOVY-6395[GROOVY-6395])
-
-Commands are now prefixed with ``:''
-(link:https://issues.apache.org/jira/browse/GROOVY-6397).
-
-[[Groovy2.3releasenotes-GroovyConsole]]
-=== GroovyConsole
-
-It is now possible to configure the font used by the console
-(link:https://issues.apache.org/jira/browse/GROOVY-6303[GROOVY-6303], although
-without a UI dialog yet), and also to be able to run a selected snippet
-of code reusing the imports defined in your script making it easier to
-just run quick snippets of your script. The ability to comment or
-uncomment selected code by pressing `Ctrl +` was added
-with�link:https://issues.apache.org/jira/browse/GROOVY-6459[GROOVY-6459].
-
-
-[[Groovy2.3releasenotes-Documentation]]
-== Documentation
-
-[[Groovy2.3releasenotes-Newdocumentation]]
-=== New documentation
-
-We are still working on the
-brand link:{DOCS_BASEURL}/html/documentation/[new documentation] for Groovy
-(in Asciidoc(tor) format), so you can already
-have a glimpse at what\u2019s already covered or not.
-
-We\u2019re looking forward to your help for fleshing out the various TBD ("To
-Be Done") sections of the documentation, as it\u2019s a gigantic task to
-re-document each and every aspect of the language and its libraries! So
-please shout if you want to *contribute to the new documentation*! All
-help is warmly welcome!
-
-[[Groovy2.3releasenotes-RefreshedGroovyDocdocumentationstyle]]
-=== Refreshed GroovyDoc documentation style
-
-GroovyDoc has been updated with a new fresh and modern skin that will be
-part of the future visual identity of the Groovy website. Those style
-updates are also available by default for your own usage of GroovyDoc,
-making your own documentation nicer on the eye.
-
-You can have a look at
-the link:http://docs.groovy-lang.org/2.3.0/html/gapi/[GroovyDoc
-documentation for Groovy 2.3.0].
-
-[[Groovy2.3releasenotes-RefreshedGroovyGDKdocumentationstyle]]
-=== Refreshed Groovy GDK documentation style
-
-We also took the opportunity to apply the same stylesheet to our
-`DocGenerator` tool which is responsible for the generation of the GDK
-documentation, showing the methods the Groovy library adds on top of the
-JDK classes.
-
-Please also have a look at the
-new link:{DOCS_BASEURL}/html/groovy-jdk/[restyled GDK documentation].
-
-[[Groovy2.3releasenotes-Dependencyupgrades]]
-== Dependency upgrades
-
-The following dependencies have been upgraded:
-
-* *GPars 1.2* for all your concurrency, asynchronous or parallelism needs:
-** improvements in the dataflow area, such as lazy tasks and easy
-fork-and-join on Promises
-** actors and dataflow operators now use the Groovy `@DelegatesTo`
-annotation to allow for statically compiled bodies
-** GPars timers and thread-locals have been made more friendly towards
-managed environments and the GParsConfig class now allows GPars to be
-completely shutdown
-* *Gradle 1.10* for building Groovy
-* *ASM 5.0.1* library for generating our bytecode (also needed for our JDK 8 support)
-* *JLine 2.11* and *JANSI 1.11* library for Groovysh
-* *Ant 1.9.3* for the Ant builder
-* *TestNG 6.8.8* for the TestNG module
-
-[[Groovy2.3releasenotes-Breakingchanges]]
-== Breaking changes
-
-Groovy 2.3.0 introduces a limited list of breaking changes.
-
-First of all,*Groovy 2.3.0 now requires JDK 6* as its minimal JDK
-requirement. Some parts of Groovy 2.3.0 might still run under JDK 5 but
-no testing has been done on that platform and some parts are known not
-to work. We encourage everyone to move to at least JDK 6.
-
-In Groovy 2.3.0, we *reworked our implementation of generics handling*.
-Although we don\u2019t know of any particular breakage so far, the static
-type checker might report new errors as it can be stricter than before.
-If ever you encounter such new errors in this area, please report them
-as soon as you encounter them.
-
-With the introduction of "traits" in Groovy 2.3, the `trait` keyword
-is an addition to the list of keyword of the languages, with the
-consequence that *variables or fields that would use `trait` as name
-with yield a compilation error*. So you would have to change the name of
-your variable and recompile your code.
-
-A few updates have been made to the *XML support around whitespace
-handling, and text node handling*:
-
-* https://issues.apache.org/jira/browse/GROOVY-6685[GROOVY-6685]
-* https://issues.apache.org/jira/browse/GROOVY-6683[GROOVY-6683]
-* https://issues.apache.org/jira/browse/GROOVY-6682[GROOVY-6682]
-* https://issues.apache.org/jira/browse/GROOVY-6678[GROOVY-6678]
-* https://issues.apache.org/jira/browse/GROOVY-6621[GROOVY-6621]
-
-With the new default methods on interfaces in JDK 8, there was
-particularly one,
-a link:https://issues.apache.org/jira/browse/GROOVY-6465[List#sort(Comparable) method], which *conflicted with one of the GDK*,
-so we had to remove ours to stay compliant with JDK 8.
-
-We fixed a link:https://issues.apache.org/jira/browse/GROOVY-6456[race condition in AbstractHttpServler#applyResourceNameMatcher]
-which incurred a small change in behavior. This feature is seldomly used and doesn\u2019t seem to
-have impacted users of the Groovy servlet machinery so far.
-
-You can look at the list of
-the link:https://issues.apache.org/jira/browse/GROOVY-6685?jql=project%20%3D%20GROOVY%20AND%20fixVersion%20in%20%28%222.3.0-rc-3%22%2C%20%222.3.0-beta-1%22%2C%20%222.3.0-beta-2%22%2C%20%222.3.0-rc-1%22%2C%20%222.3.0-rc-2%22%29%20AND%20labels%20%3D%20breaking%20AND%20status%20in%20%28Resolved%2C%20Closed%29[breaking changes from our JIRA]
-issue tracker.
-
http://git-wip-us.apache.org/repos/asf/groovy-user-site/blob/de805f31/site/src/site/releasenotes/groovy-2.4.adoc
----------------------------------------------------------------------
diff --git a/site/src/site/releasenotes/groovy-2.4.adoc b/site/src/site/releasenotes/groovy-2.4.adoc
deleted file mode 100644
index caaee43..0000000
--- a/site/src/site/releasenotes/groovy-2.4.adoc
+++ /dev/null
@@ -1,220 +0,0 @@
-[[Android]]
-== Android Support
-With Groovy 2.4, you can write Android applications in Groovy!
-
-A quick link:{DOCS_BASEURL}/html/documentation/tools-groovyc.html#section-android[getting
-started guide] is available on the Groovy website.
-
-To build your Android applications with the Groovy support, you\u2019ll be
-able to use
-the link:https://github.com/groovy/groovy-android-gradle-plugin[Gradle Groovy Android plugin].
-
-The link:https://github.com/Arasthel/SwissKnife[SwissKnife] library builds
-upon the Groovy support to offer very useful AST transformations that
-kill the usual Android boilerplate code, for instance for dealing with
-UI events, with logic to be run in background threads, or make objects
-easily "parcelables", etc.
-
-To further understand the new Android support, you can read the
-following articles by C�dric Champeau:
-
-* Introduction: link:http://melix.github.io/blog/2014/06/grooid.html[http://melix.github.io/blog/2014/06/grooid.html]
-* Technical details: link:http://melix.github.io/blog/2014/06/grooid2.html[http://melix.github.io/blog/2014/06/grooid2.html]
-
-And discover presentations on the Android support:
-
-* link:https://speakerdeck.com/melix/groovy-and-android-a-winning-pair-1[Groovy and Android, a winning pair] by C�dric Champeau
-* link:https://speakerdeck.com/glaforge/groovy-on-android-groovy-grails-exchange-2014[Groovy on Android] by Guillaume Laforge
-
-The work on the Android support also lead to various optimizations in
-terms of bytecode generation, as explained further down, as well as, for
-instance, improving the handling of overloaded setters
-(link:https://issues.apache.org/jira/browse/GROOVY-2049[GROOVY-2049],link:https://issues.apache.org/jira/browse/GROOVY-6084[GROOVY-6084],
-link:https://issues.apache.org/jira/browse/GROOVY-2500[GROOVY-2500])
-which are frequent in the Android SDK.
-
-[[Groovy2.4releasenotes-Performanceimprovementsandreducedbytecode]]
-== Performance improvements and reduced bytecode
-
-This new major release of Groovy has seen various improvements across
-the board to reduce the quantity of bytecode produced, to lower memory
-consumption of internal data structures, fine tune bytecode for better
-performance.
-
-Here are some of the tickets related to the topic:
-
-* Cheaper comparison operations
-(link:https://issues.apache.org/jira/browse/GROOVY-7194[GROOVY-7194])
-* Reduced memory consumption for `respondsTo()`
-(link:https://issues.apache.org/jira/browse/GROOVY-7178[GROOVY-7178])
-* For fully statically compiled classes, MOP related generated methods
-are not needed
-(link:https://issues.apache.org/jira/browse/GROOVY-6990[GROOVY-6990])
-* Remove unneeded inner class distributor methods when no inner classes
-are present (link:https://issues.apache.org/jira/browse/GROOVY-6993[GROOVY-6993])
-* Removal of the timestamp in Groovy classes
-(link:https://issues.apache.org/jira/browse/GROOVY-6308[GROOVY-6308])
-* Optimization of primitive type conversions with the as operator
-(link:https://issues.apache.org/jira/browse/GROOVY-7140[GROOVY-7140])
-
-[[Groovy2.4releasenotes-TraitsSelfTypeannotation]]
-== Traits @SelfType annotation
-
-Sometimes, it\u2019s desired to be able to restrict a trait\u2019s application so
-that it can only be applied to subclasses of a certain type. That\u2019s what
-the `@SelfType` annotation is for
-(link:https://issues.apache.org/jira/browse/GROOVY-7134[GROOVY-7134]).
-
-Here\u2019s a concrete example of `@SelfType` in action.
-
-[source,groovy]
-----
-import groovy.transform.*
-
-class Component {
- void doSomething() {
- println "Done!"
- }
-}
-
-@SelfType(Component)
-@TypeChecked
-trait ComponentDecorator {
- void logAndDoSomething() {
- println "Going to do something"
- doSomething()
- }
-}
-
-class ConcreteComponent
- extends Component
- implements ComponentDecorator {}
-
-def c = new ConcreteComponent()
-c.logAndDoSomething()
-----
-
-The `ComponentDecorator` trait is calling the `doSomething()` method from
-the `Component` sub-class to which it will be applied. If you don\u2019t
-specify the `@SelfType(Component)` annotation, when using static type
-checking or static compilation, the compiler will throw a compilation
-error as it wouldn\u2019t know where the `doSomething()` method would be coming
-from. With the annotation, you instruct the compiler to figure out that
-this trait will only be applied to child of Component that will have
-that method available. `@SelfType` is interesting in the context of static
-type checking or compilation, but is not needed if your code is dynamic
-as the resolution will take place at runtime as usual.
-
-[[Groovy2.4releasenotes-GDKimprovements]]
-== GDK improvements
-
-* `System.currentTimeSeconds()` to get the current time in seconds
-(link:https://issues.apache.org/jira/browse/GROOVY-6294[GROOVY-6294])
-* `List#getIndices()` to get a range representing the indices of the
-elements of the list
-(link:https://issues.apache.org/jira/browse/GROOVY-7171[GROOVY-7171])
-* More collection related methods are moved to iterator-based variants
-to apply to all iterable collection types
-(link:https://issues.apache.org/jira/browse/GROOVY-6863[GROOVY-6863]) and missing
-methods have been added like `init()`, `dropRight()`, `takeRight()`
-(link:https://issues.apache.org/jira/browse/GROOVY-6867[GROOVY-6867])
-* `Iterable` gets `disjoin()`, `minus()` and `toSpreadMap()` methods
-(link:https://issues.apache.org/jira/browse/GROOVY-6920[GROOVY-6920])
-* Refinements and concistency for existing collection methods,
-leveraging iterable approaches for stream-like traversals, consistency
-for mutation in place vs �new collection creation, minor optimizations,
-etc. (link:https://issues.apache.org/jira/browse/GROOVY-6945[GROOVY-6945])
-* New `List#removeAt(index)` and `Collection#removeElement(Object)` methods
-(link:https://issues.apache.org/jira/browse/GROOVY-6952[GROOVY-6952])
-* `Iterable` gets a `size()` method like iterators
-(link:https://issues.apache.org/jira/browse/GROOVY-7085[GROOVY-7085])
-
-[[Groovy2.4releasenotes-ASTtransformations]]
-== AST transformations
-
-* The `@ToString` transformation offers an `includeSuperProperties`
-parameter so properties from the super class are also present in the
-string representation
-(link:https://issues.apache.org/jira/browse/GROOVY-7161[GROOVY-7161])
-* You can define the compilation phase for the `@ASTTest` transformation
-for testing your AST transformations
-(link:https://issues.apache.org/jira/browse/GROOVY-6968[GROOVY-6968])
-* `@Synchronized` supports explicit static locks to be used by instance
-methods if needed
-(link:https://issues.apache.org/jira/browse/GROOVY-7030[GROOVY-7030])
-* Clean up generated code for `@AutoExternalizable`
-(link:https://issues.apache.org/jira/browse/GROOVY-6889[GROOVY-6889]) and
-`@EqualsAndHashCode`
-(link:https://issues.apache.org/jira/browse/GROOVY-6893[GROOVY-6893]) the when
-using `@CompileStatic`
-* `@Builder`\u2019s default and initializer strategies improved Java
-integration (link:https://issues.apache.org/jira/browse/GROOVY-6875[GROOVY-6875])
-* `@PackageScope` allowed on constructors too
-(link:https://issues.apache.org/jira/browse/GROOVY-6839[GROOVY-6839])
-
-[[Groovy2.4releasenotes-Groovyshimprovements]]
-== Groovysh improvements
-
-The venerable Groovysh shell continues seeing some useful improvements:
-
-* Groovysh supports custom .rc and .profile scripts to be loaded on
-startup (link:https://issues.apache.org/jira/browse/GROOVY-6943[GROOVY-6943])
-* completion of instanceof statements
-(link:https://issues.apache.org/jira/browse/GROOVY-7200[GROOVY-7200])
-* completion of static members only displayed in a static context
-(link:https://issues.apache.org/jira/browse/GROOVY-6622[GROOVY-6622])
-* completion candidates in color
-(link:https://issues.apache.org/jira/browse/GROOVY-6563[GROOVY-6563])
-* with :set interpreterMode true, you can let Groovysh to let you see
-and use locally-defined variables after further line executions
-(link:https://issues.apache.org/jira/browse/GROOVY-6623[GROOVY-6623])
-* the :load command supports file names containing spaces
-(link:https://issues.apache.org/jira/browse/GROOVY-6942[GROOVY-6942])
-* make arguments and flags consistent with the groovy command and allow
-the launch of a script on startup passed as argument and continue
-execution of Groovysh
-(link:https://issues.apache.org/jira/browse/GROOVY-6754[GROOVY-6754])
-* make it easier to subclass Groovysh for reuse as an embedded shell
-(link:https://issues.apache.org/jira/browse/GROOVY-6752[GROOVY-6752])
-
-[[Groovy2.4releasenotes-Miscellaneous]]
-== Miscellaneous
-
-* Allow Ant targets declaration by AntBuilder without immediate
-execution (link:https://issues.apache.org/jira/browse/GROOVY-2900[GROOVY-2900])
-* Make `NamespaceBuilder` automatically detect namespace declarations
-(link:https://issues.apache.org/jira/browse/GROOVY-6890[GROOVY-6890])
-* Implement and register type checking extensions as subclasses of
-`TypeCheckingExtension`
-(link:https://issues.apache.org/jira/browse/GROOVY-6739[GROOVY-6739])
-* `ConfigObject` overrides `toString()` and offers a `prettyPrint()` method
-(link:https://issues.apache.org/jira/browse/GROOVY-7183[GROOVY-7183])
-* Improved type checking for certain GDK methods
-(link:https://issues.apache.org/jira/browse/GROOVY-6966[GROOVY-6966])
-* Grape is using JCenter through HTTP first for resolving dependencies,
-and now HTTPS is used for better security
-(link:https://issues.apache.org/jira/browse/GROOVY-7152[GROOVY-7152])
-* Parameters of `@DelegatesTo` and `@ClosureParams` are better aligned
-(link:https://issues.apache.org/jira/browse/GROOVY-6956[GROOVY-6956])
-* Multiple labels are supported on the same statement
-(link:https://issues.apache.org/jira/browse/GROOVY-3298[GROOVY-3298])
-
-[[Groovy2.4releasenotes-Breakingchanges]]
-== Breaking changes
-
-A few issues fixed might also be considered breaking changes in some
-situations:
-
-* Malformed class names for closures in inner classes
-(link:https://issues.apache.org/jira/browse/GROOVY-5351[GROOVY-5351])
-* Avoid creation of MOP methods in static compilation
-(link:https://issues.apache.org/jira/browse/GROOVY-6990[GROOVY-6990])
-* Reduce memory consumption for respondsTo()
-(link:https://issues.apache.org/jira/browse/GROOVY-7178[GROOVY-7178])
-* Making Groovysh more easily extendable and embeddable
-(link:https://issues.apache.org/jira/browse/GROOVY-6752[GROOVY-6752])
-
-[[Groovy2.4releasenotes-Moreinformation]]
-== More information
-
-You can browse all the link:../changelogs/changelog-2.4.0.html[tickets closed for Groovy 2.4 in JIRA].
http://git-wip-us.apache.org/repos/asf/groovy-user-site/blob/de805f31/site/src/site/releasenotes/groovy-2.5.adoc
----------------------------------------------------------------------
diff --git a/site/src/site/releasenotes/groovy-2.5.adoc b/site/src/site/releasenotes/groovy-2.5.adoc
deleted file mode 100644
index 7fa4062..0000000
--- a/site/src/site/releasenotes/groovy-2.5.adoc
+++ /dev/null
@@ -1,112 +0,0 @@
-(Material on this page is still under development!)
-
-[[Groovy2.5releasenotes-Macros]]
-== Macro support
-With Groovy 2.5, you can write macros in Groovy!
-
-Details: TBD
-
-[[Groovy2.5releasenotes-NewAstTransforms]]
-== New AST Transformations
-
-* `@MapConstructor` adds a `Map`-based constructor to a class. This allows a usage
-style similar to Groovy's named parameters but doesn't use the no-arg constructor
-and then call setters. This may be useful if you have final properties or wish the
- class file to have the `Map` constructor for integration purposes
-(link:https://issues.apache.org/jira/browse/GROOVY-7353[GROOVY-7353]).
-* `@AutoImplement` allows you to provide dummy implementations of any abstract
-methods that might be inherited from super classes or interfaces
-(link:https://issues.apache.org/jira/browse/GROOVY-7860[GROOVY-7860]).
-
-[[Groovy2.5releasenotes-AstTransformImprovements]]
-== AST Transformation improvements
-
-* `@Canonical` becomes a meta-annotation allowing more flexible usage of the annotation attributes
-from its constituent annotations
-(link:https://issues.apache.org/jira/browse/GROOVY-6319[GROOVY-6319]).
-* `@Immutable` now supports Java's `Optional` container class
-(link:https://issues.apache.org/jira/browse/GROOVY-7600[GROOVY-7600])
-and handles inheritance hierarchies
-(link:https://issues.apache.org/jira/browse/GROOVY-7162[GROOVY-7162]).
-* `@Delegate` can now be used on getters
-(link:https://issues.apache.org/jira/browse/GROOVY-7769[GROOVY-7769]).
-* `@TupleConstructor` now supports `pre` and `post` closure conditions to match the functionality provided by `@MapConstructor`
-(link:https://issues.apache.org/jira/browse/GROOVY-7769[GROOVY-7769]).
-* `@TupleConstructor` and `@Builder` should be able to use defined setters rather than the field directly
-(link:https://issues.apache.org/jira/browse/GROOVY-7087[GROOVY-7087]).
-* Most annotations check property and field names provided to annotation attributes
-(link:https://issues.apache.org/jira/browse/GROOVY-7087[GROOVY-7087]).
-
-[[Groovy2.5releasenotes-Toolimprovements]]
-== Tool improvements
-
-Some improvements were made to Groovysh shell and the Groovy Console:
-
-* `groovysh` should offer easier access to grapes
-(link:https://issues.apache.org/jira/browse/GROOVY-6514[GROOVY-6514]).
-* `groovyconsole` now provides an ASMifier tab within the AstBrowser
-(link:https://issues.apache.org/jira/browse/GROOVY-8091[GROOVY-8091]).
-
-[[Groovy2.5releasenotes-OtherImprovements]]
-== Other improvements
-
-* Groovy's CliBuilder now supports annotation style definitions
-(link:https://issues.apache.org/jira/browse/GROOVY-7825[GROOVY-7825]).
-* Alternative to `with` called `tap` that has an implicit `return delegate`
-(link:https://issues.apache.org/jira/browse/GROOVY-3976[GROOVY-3976]).
-* Various JSON customization options are now supported
-(link:https://issues.apache.org/jira/browse/GROOVY-3976[GROOVY-6975] and
-link:https://issues.apache.org/jira/browse/GROOVY-3976[GROOVY-6854]).
-* Method parameter names are now accessible at runtime
-(link:https://issues.apache.org/jira/browse/GROOVY-7423[GROOVY-7423]).
-
-[[Groovy2.5releasenotes-Breakingchanges]]
-== Breaking changes
-
-A few issues fixed might also be considered breaking changes in some
-situations:
-
-* @TupleConstructor could use the order of properties listed in 'includes' when that option is used
-(link:https://issues.apache.org/jira/browse/GROOVY-8016[GROOVY-8016])
-* @ToString could output properties in a predefined order when 'includes' is used
-(link:https://issues.apache.org/jira/browse/GROOVY-8014[GROOVY-8014])
-* AstNodeToScriptAdapter should output source using the recommended modifier order
-(link:https://issues.apache.org/jira/browse/GROOVY-7967[GROOVY-7967])
-* ObjectRange iterator returns null instead of NoSuchElementException
-(link:https://issues.apache.org/jira/browse/GROOVY-7961[GROOVY-7961])
-* IntRange iterator returns null instead of NoSuchElementException
-(link:https://issues.apache.org/jira/browse/GROOVY-7960[GROOVY-7960])
-(link:https://issues.apache.org/jira/browse/GROOVY-7937[GROOVY-7937])
-* o.c.g.r.t.DefaultTypeTransformation does not apply the right toString on primitive arrays when transforming to String
-(link:https://issues.apache.org/jira/browse/GROOVY-7853[GROOVY-7853])
-* Remove synchronized methods of groovy.sql.Sql and document it as not thread-safe
-(link:https://issues.apache.org/jira/browse/GROOVY-7673[GROOVY-7673])
-* InvokerHelper formatting methods have inconsistent API
-(link:https://issues.apache.org/jira/browse/GROOVY-7563[GROOVY-7563])
-* Fix up transforms (apart from TupleConstructor) which are affected by empty includes default
-(link:https://issues.apache.org/jira/browse/GROOVY-7529[GROOVY-7529])
-* TupleConstructor with empty includes includes all
-(link:https://issues.apache.org/jira/browse/GROOVY-7523[GROOVY-7523])
-* TupleConstructor overwrites empty default constructors
-(link:https://issues.apache.org/jira/browse/GROOVY-7522[GROOVY-7522])
-* ResourceGroovyMethods/NioGroovyMethods BOM behavior is inconsistent
-(link:https://issues.apache.org/jira/browse/GROOVY-7465[GROOVY-7465])
-* API inconsistency between takeWhile, dropWhile and collectReplacements for CharSequences
-(link:https://issues.apache.org/jira/browse/GROOVY-7433[GROOVY-7433])
-* @ToString could support non-field properties
-(link:https://issues.apache.org/jira/browse/GROOVY-7394[GROOVY-7394])
-* same linkedlist code different behavior between groovy and java
-(link:https://issues.apache.org/jira/browse/GROOVY-6396[GROOVY-6396])
-* CLONE - same linkedlist code different behavior between groovy and java (fix priority of DGM methods vs actual methods on an object)
-* Accessing private methods from public ones using categories and inheritance causes MissingMethodException
-(link:https://issues.apache.org/jira/browse/GROOVY-6263[GROOVY-6263])
-
-[[Groovy2.5releasenotes-JDKrequirements]]
-== JDK requirements changes
-
-Groovy 2.5 requires JDK7+ to build and JDK7 is the minimum version of the JRE that we support.
-
-[[Groovy2.5releasenotes-Moreinformation]]
-== More information
-
-You can browse all the link:../changelogs/changelog-2.5.0.html[tickets closed for Groovy 2.5 in JIRA].
http://git-wip-us.apache.org/repos/asf/groovy-user-site/blob/de805f31/site/src/site/sitemap.groovy
----------------------------------------------------------------------
diff --git a/site/src/site/sitemap.groovy b/site/src/site/sitemap.groovy
deleted file mode 100644
index 107cba0..0000000
--- a/site/src/site/sitemap.groovy
+++ /dev/null
@@ -1,473 +0,0 @@
-menu {
- group('Groovy') {
- item 'Learn', 'learn.html'
- item 'Documentation', 'documentation.html'
- item 'Download', 'download.html'
- item 'Community', 'community.html'
- item 'Ecosystem', 'ecosystem.html'
- }
-
- group('About') {
- item 'Contributing', 'contribute.html'
- item 'Source code', 'https://github.com/apache/groovy'
- item 'Build status', 'buildstatus.html'
- item 'Security', 'security.html'
- item 'Books', 'learn.html#books'
- item 'Thanks', 'thanks.html'
- item 'Sponsorship', 'http://www.apache.org/foundation/sponsorship.html'
- item 'FAQ', 'faq.html'
- item 'Search', 'search.html'
- }
-
- group('Socialize') {
- item 'Discuss on the mailing-list', 'mailing-lists.html', 'fa-envelope'
- item 'Groovy newsletter', 'groovy-weekly.html', 'fa-envelope-o'
- item 'Groovy on Twitter', 'https://twitter.com/ApacheGroovy', 'fa-twitter'
- item 'Events and conferences', 'events.html', 'fa-calendar'
- item 'Source code on GitHub', 'https://github.com/apache/groovy', 'fa-github'
- item 'Report issues in Jira', 'contribute.html#reporting-issues', 'fa-bug'
- item 'Google+ Groovy Page', 'https://google.com/+groovy', 'fa-google-plus'
- item 'Google+ Groovy Community', 'http://bit.ly/g-community', 'fa-google-plus'
- item 'Stack Overflow questions', 'http://stackoverflow.com/questions/tagged/groovy', 'fa-stack-overflow'
- item 'Slack Community', 'http://groovycommunity.com/', 'fa-slack'
- }
-}
-
-pages {
- page 'index', 'index', [allEvents: allEvents]
- page 'search', 'search', [category: 'Search']
- page 'ecosystem', 'ecosystem', [category: 'Ecosystem', ecosys: ecosystem]
- page 'learn', 'learn', [category: 'Learn', docSections: documentationSections, allBooks: library, videos: videos, courses: courses]
- page 'documentation', 'documentation', [category: 'Documentation', docSections: documentationSections, allDocVersions: allDocVersions]
- page 'download', 'download', [category: 'Download', distributions: distributions]
- page 'versioning', 'versioning', [category: 'Download']
- page 'indy', 'indy', [category: 'Download']
- page 'security', 'security', [category: 'Learn']
- page 'community', 'community', [category: 'Community']
- page 'usergroups', 'usergroups', [category: 'Community', userGroups: usergroups]
- page 'groovy-weekly', 'groovy-weekly', [category: 'Community']
- page 'mailing-lists', 'mailing-lists', [category: 'Community']
- page 'contribute', 'contribute', [category: 'Community']
- page 'thanks', 'thanks', [category: 'Community']
- page 'buildstatus', 'buildstatus', [category: 'Community']
- page 'faq', 'faq', [category: 'Documentation', docSections: documentationSections]
- page 'events', 'events', [category: 'Community', allEvents: allEvents]
- page 'api', 'api', [category: 'Learn', iframeTarget: "${DOCS_BASEURL}/html/gapi"]
- page 'gdk', 'gdk', [category: 'Learn', iframeTarget: "${DOCS_BASEURL}/html/groovy-jdk"]
- page 'singlepagedocumentation', 'single-page-documentation', [category: 'Learn', iframeTarget: "${DOCS_BASEURL}/html/documentation/"]
- page 'changelogs', 'changelogs', [:]
- page '404','404', [:]
-}
-
-documentation {
- groovyDocumentationVersions([
- '1.7.0', '1.7.1', '1.7.2', '1.7.3', '1.7.4', '1.7.5', '1.7.6', '1.7.7', '1.7.8', '1.7.9', '1.7.10', '1.7.11',
- '1.8.0', '1.8.1', '1.8.2', '1.8.3', '1.8.4', '1.8.5', '1.8.6', '1.8.7', '1.8.8', '1.8.9',
- '2.0.0', '2.0.1', '2.0.2', '2.0.3', '2.0.4', '2.0.5', '2.0.6', '2.0.7', '2.0.8',
- '2.1.0', '2.1.1', '2.1.2', '2.1.3', '2.1.4', '2.1.5', '2.1.6', '2.1.7', '2.1.8', '2.1.9',
- '2.2.0', '2.2.1', '2.2.2',
- '2.3.0', '2.3.1', '2.3.2', '2.3.3', '2.3.4', '2.3.5', '2.3.6', '2.3.7', '2.3.8', '2.3.9', '2.3.10', '2.3.11',
- '2.4.0', '2.4.1', '2.4.2', '2.4.3', '2.4.4', '2.4.5', '2.4.6', '2.4.7', '2.4.8', '2.4.9', '2.4.10',
- '2.5.0-alpha-1'
- ])
-
- section('Getting started','fa-graduation-cap') {
- // NAME TARGET HTML DOCPAGE HTML GENERATE
- item 'Download Groovy', 'download', 'download', false
- item 'Install Groovy', 'install', 'core-getting-started'
- item 'Differences with Java', 'differences', 'core-differences-java'
- item 'The Groovy Development Kit', 'groovy-dev-kit', 'core-gdk'
- item 'Runtime and compile-time metaprogramming', 'metaprogramming', 'core-metaprogramming'
- item 'The Grape dependency manager', 'grape', 'grape'
- item 'Testing guide', 'testing', 'core-testing-guide'
- item 'Domain-Specific Languages', 'dsls', 'core-domain-specific-languages'
- item 'Integrating Groovy into applications', 'integrating', 'guide-integrating'
- item 'Security', 'security', 'security'
- item 'Design patterns in Groovy', 'design-patterns', 'design-pattern-in-groovy'
- item 'Style guide', 'style-guide', 'style-guide'
- }
-
- section ('Language Specification', 'fa-graduation-cap') {
- item 'Syntax', 'syntax', 'core-syntax'
- item 'Operators', 'operators', 'core-operators'
- item 'Program structure', 'structure', 'core-program-structure'
- item 'Object orientation', 'objectorientation', 'core-object-orientation'
- item 'Closures', 'closures', 'core-closures'
- item 'Semantics', 'semantics', 'core-semantics'
- }
-
- section ('Tools','fa-gears') {
- item 'groovyc \u2014 the Groovy compiler', 'groovyc', 'tools-groovyc'
- item 'groovysh \u2014 the Groovy command -like shell', 'groovysh', 'groovysh'
- item 'groovyConsole \u2014 the Groovy Swing console', 'groovyconsole', 'groovy-console'
- item 'IDE integration', 'ides', 'tools-ide'
- }
-
- section('Groovy module guides', 'fa-cubes') {
- item 'Parsing and producing JSON', 'json', 'json-userguide'
- item 'Working with a relational database', 'databases', 'sql-userguide'
- item 'Processing XML', 'processing-xml', 'xml-userguide'
- item 'Scripting Ant tasks', 'scripting-ant', 'ant-builder'
- item 'Template engines', 'templating', 'template-engines'
- item 'Creating Swing UIs', 'swing', 'swing-builder'
- item 'Servlet support', 'servlet', 'servlet-userguide'
- item 'Working with JMX', 'jmx', 'jmx'
- }
-
- section ('API documentation', 'fa-code') {
- item 'GroovyDoc documentation of the Groovy APIs', 'api', 'api'
- item 'The Groovy Development Kit enhancements', 'gdk', 'gdk'
- }
-}
-
-downloads {
- distribution('Groovy 2.5') {
- description {
- yield 'Groovy 2.5 is the upcoming '
- a(href: 'versioning.html', 'version')
- yield ' of Groovy. Pre-release versions are available:'
- }
- version('2.5.0-alpha-1') {
- stable false
- }
- }
- distribution('Groovy 2.4') {
- description {
- yield 'Groovy 2.4 is the latest stable '
- a(href: 'versioning.html', 'version')
- yield ' of Groovy.'
- yieldUnescaped ''' Important: Releases before 2.4.4 weren't done under the Apache Software Foundation and are provided as a convenience, without any warranty.'''
- }
- version('2.4.10') {
- stable true
- windowsInstaller 'https://dl.bintray.com/groovy/Distributions/groovy-2.4.10-installer.exe'
- }
- }
-}
-
-ecosystem {
- project('Grails') {
- description 'Grails is an Open Source, full stack, web application framework for the JVM. It takes advantage of the Groovy programming language and convention over configuration to provide a productive and stream-lined development experience.'
- url 'http://grails.org/'
- logo 'img/ecosystem/grails.png'
- }
-
- project('Gradle') {
- description 'Gradle is build automation evolved. Gradle can automate the building, testing, publishing, deployment and more of software packages or other types of projects such as generated static websites, generated documentation or indeed anything else.'
- url 'http://gradle.org'
- logo 'img/ecosystem/gradle.png'
- }
-
- project('Spock') {
- description 'Spock is a testing and specification framework for Java and Groovy applications. What makes it stand out from the crowd is its beautiful and highly expressive specification language. Thanks to its JUnit runner, Spock is compatible with most IDEs, build tools, and continuous integration servers.'
- url 'http://spockframework.org/'
- logo ''
- }
-
- project('GPars') {
- description 'The GPars framework offers Java developers intuitive and safe ways to handle Java or Groovy tasks concurrently. Leveraging the enormous flexibility of the Groovy programming language and building on proven Java technologies, we aim to make concurrent programming for multi-core hardware intuitive, robust and enjoyable.'
- url 'http://www.gpars.org/'
- logo 'img/ecosystem/gpars.png'
- }
-
- project('Ratpack') {
- description 'Ratpack is a simple, capable, toolkit for creating high performance web applications.'
- url 'http://www.ratpack.io/'
- logo 'img/ecosystem/ratpack.png'
- }
-
- project('Griffon') {
- description 'Griffon is an application framework for developing desktop applications in the JVM, with Groovy being the primary language of choice. Inspired by Grails, Griffon follows the Convention over Configuration paradigm, paired with an intuitive MVC architecture and a command line interface.'
- url 'http://griffon-framework.org/'
- logo 'img/ecosystem/griffon.png'
- }
-
- project('Geb') {
- description 'Geb is a powerful browser functional testing framework that lets you quickly and easily write functional tests in Groovy. It brings together the power of WebDriver, the elegance of jQuery content selection, the robustness of Page Object modelling and the expressiveness of the Groovy language.'
- url 'http://www.gebish.org/'
- logo 'img/ecosystem/geb.png'
- }
-
- project('SDKMAN!') {
- description 'SDKMAN! is a tool for managing parallel versions of multiple Software Development Kits on most Unix based systems. It provides a convenient command line interface for installing, switching, removing and listing Candidates.'
- url 'http://sdkman.io/'
- logo 'img/ecosystem/sdkman.png'
- }
-}
-
-allEvents {
- // Note that the event image should be 257x180 to look nice
- event('Greach 2017') {
- location 'Madrid, Spain'
- date 'March 31 - April 1, 2017'
- url 'http://greachconf.com/'
- logo 'img/confs/greach2017.png'
- description '''
- <p>
- Greach, the Spanish gathering of enthusiasts of Groovy, Grails, Griffon, Gradle, Spock, Vert.x, Gaelyk,
- and many more. With inspirational talks from the makers and users of these projects, hands-on workshops with the rock stars,
- join the 150+ attendees, designers, students, designers, the best professionals together in a great atmosphere.
- </p>
- '''
- }
- event('GR8Conf EU 2017') {
- location 'Copenhagen, Denmark'
- date 'May 31 - June 2, 2017'
- url 'http://gr8conf.eu/'
- logo 'img/confs/gr8confeu.png'
- description '''
- <p>
- Groovy, Grails and the related technologies have seen astounding growth in interest and adoption the past
- few years, and with good reason. To spread the word even more we have created GR8Conf.
- </p>
- <p>
- The 2017 Edition of GR8Conf Europe will feature a DevOps day. Focus will be on technologies to support your
- everyday DevOps needs.
- </p>
- <p>
- GR8Conf is an independent, affordable series of conferences.
- It's dedicated to the technologies in the Groovy ecosystem.
- </p>
- '''
- }
- event('GR8Conf US 2017') {
- location 'Minneapolis, MN, United States of America'
- date 'July 26 - 28, 2017'
- url 'http://gr8conf.us/'
- logo 'img/confs/gr8confus.png'
- description '''
- <p>
- Groovy, Grails and the related technologies have seen astounding growth in interest and adoption the past
- few years, and with good reason. To spread the word even more we have created GR8Conf.
- </p>
- <p>
- GR8Conf is an independent, affordable series of conferences.
- It's dedicated to the technologies in the Groovy ecosystem.
- </p>
- '''
- }
- event('GR8Conf India 2018') {
- location 'New Delhi, India'
- date 'January, 2018'
- url 'http://gr8conf.in/'
- logo 'img/confs/gr8confin.png'
- description '''
- <p>
- Groovy, Grails and the related technologies have seen astounding growth in interest and adoption the past
- few years, and with good reason. To spread the word even more we have created GR8Conf.
- </p>
- <p>
- GR8Conf is an independent, affordable series of conferences.
- It's dedicated to the technologies in the Groovy ecosystem.
- </p>
- '''
- }
-
-
-}
-
-books {
- book('Groovy in Action, Second Edition') {
- authors "Dierk K�nig, Paul King, Guillaume Laforge, Hamlet D'Arcy, C�dric Champeau, Erik Pragt, and Jon Skeet"
- cover 'img/books/regina.png'
- url 'http://www.manning.com/koenig2/'
- description 'The undisputed definitive reference on the Groovy programming language, authored by core members of the development team.'
- }
-
- book('Making Java Groovy') {
- authors 'Ken Kousen'
- cover 'img/books/Kousen-MJG.png'
- url 'http://www.manning.com/kousen/'
- description 'Make Java development easier by adding Groovy. Each chapter focuses on a task Java developers do, like building, testing, or working with databases or restful web services, and shows ways Groovy can help.'
- }
-
- book('Programming Groovy 2') {
- authors 'Venkat Subramaniam'
- cover 'img/books/vslg2.jpg'
- url 'http://pragprog.com/book/vslg2/programming-groovy-2'
- description 'Dynamic productivity for the Java developer'
- }
-
- book('Groovy 2 Cookbook') {
- authors 'Andrey Adamovitch, Luciano Fiandeso'
- cover 'img/books/g2cook.jpg'
- url 'http://www.packtpub.com/groovy-2-cookbook/book'
- description 'Over 90 recipes that provide solutions to everyday programming challenges using the powerful features of Groovy 2'
- }
-
- book('Groovy for Domain-Specific Languages - Second Edition') {
- authors 'Fergal Dearle'
- cover 'img/books/gdsl.jpg'
- url 'https://www.packtpub.com/application-development/groovy-domain-specific-languages-second-edition'
- description 'Extend and enhance your Java applications with domain-specific scripting in Groovy'
- }
-
- book('Groovy Goodness Notebook') {
- authors 'Hubert A. Klein Ikkink'
- cover 'img/books/ggood.jpg'
- url 'https://leanpub.com/groovy-goodness-notebook'
- description 'Experience the Groovy programming language through code snippets. Learn more about (hidden) Groovy features with code snippets and short articles. The articles and code will get you started quickly and will give more insight in Groovy.'
- }
-
- book("Grails 3: A Practical Guide to Application Development") {
- authors "Eric Helgeson"
- cover 'img/books/pratical-grails-3-book-cover.png'
- url 'https://www.grails3book.com/'
- description "The first book dedicated to Grails 3. You will learn the concepts behind building Grails applications. Real, up-to-date code examples are provided so you can easily follow along."
- }
-
- book('Falando de Grails') {
- authors 'Henrique Lobo Weissmann'
- cover 'img/books/weissmann_groovy_grails.png'
- url 'http://www.casadocodigo.com.br/products/livro-grails'
- description 'For Groovy and Grails developers, authored by the founder of Grails Brasil based on his experiences as a Groovy and Grails consultant.'
- }
-
-}
-
-usergroups {
- // Europe
- userGroup('Aarhus Groovy & Grails Meetup') {
- location 'Europe/Denmark'
- url 'https://www.linkedin.com/grps/Groovy-Grails-Meetup-Aarhus-3702945/'
- }
- userGroup('Paris Groovy Grails User Group') {
- location 'Europe/France'
- }
- userGroup('Berlin Groovy User Group') {
- location 'Europe/Germany'
- url 'http://www.meetup.com/de/Berlin-Groovy-User-Group/'
- }
- userGroup('Groovy & Grails Israel User Group') {
- location 'Europe/Israel'
- url 'http://www.meetup.com/Groovy-Grails-Israel-Meetup-Group/'
- }
- userGroup('Warsaw Groovy User Group') {
- location 'Europe/Poland'
- url 'http://www.meetup.com/Warsaw-Groovy-User-Group/'
- }
- userGroup('Madrid Groovy User Group') {
- location 'Europe/Spain'
- url 'http://www.meetup.com/madrid-gug/'
- }
- userGroup('Dutch Groovy and Grails User Group (NLGUG)') {
- location 'Europe/The Netherlands'
- url 'http://www.meetup.com/nl-gug/'
- }
-
- // North-America
- userGroup('Austin Groovy and Grails User Group (TX)') {
- location 'North-America/United States'
- url 'http://www.meetup.com/Austin-Groovy-and-Grails-Users/'
- }
- userGroup('Boston Groovy, Grails, Spring Meetup (B2GS)') {
- location 'North-America/United States'
- url 'https://www.meetup.com/Grails-Boston/'
- }
- userGroup('Coder Consortium of Sacramento') {
- location 'North-America/United States'
- url 'http://coderconsortium.com/'
- }
- userGroup('DFW Groovy & Grails User Group') {
- location 'North-America/United States'
- url 'http://dfw2gug.org'
- }
- userGroup('Groovy Users of Minnesota') {
- location 'North-America/United States'
- url 'http://groovy.mn'
- }
- userGroup('NYC Groovy / Grails Meetup') {
- location 'North-America/United States'
- url 'http://www.meetup.com/grails/'
- }
- userGroup('Pittsburgh Groovy Programming') {
- location 'North-America/United States'
- url 'http://www.meetup.com/Pittsburgh-Groovy-Programming/'
- }
-
- // South-America
- userGroup('Grails Brasil - Groovy and Grails users group of Brazil') {
- location 'South-America/Brazil'
- url 'http://www.grailsbrasil.com.br'
- }
- userGroup('Brazil Groovy and Grails Meetup') {
- location 'South-America/Brazil'
- url 'http://www.meetup.com/groovybr'
- }
-
- // Asia
- userGroup('Bangalore Groovy Grails Meetup') {
- location 'Asia/India'
- url 'http://www.meetup.com/Bangalore-Groovy-Grails-Meetup/'
- }
- userGroup('Japan Grails/Groovy User Group') {
- location 'Asia/Japan'
- url 'http://www.jggug.org/'
- }
-
- // Oceania?
- /* userGroup('') { location 'Oceania/Australia' } */
-}
-
-videos {
- video('The Groovy ecosystem revisited') {
- speaker 'Andr�s Almiray'
- summary '''
- <p>Groovy is a well established player in the JVM since a few years ago.
- It's increased popularity across the years has spawned several projects that conform the Groovy Ecosystem.
- You've probably heard of Grails, Gradle, Griffon and Spock.
- But what about the rest of projects that are just waiting around the corner to be discovered and make your life easier?
- This talk presents them tools and libraries that use Groovy as the main driving force to get the job done.</p>
- '''
- pictureUrl 'groovy-ecosystem-revisited.png'
- videoUrl 'https://www.youtube.com/watch?v=2NGeaIwmnC8&list=PLwxhnQ2Qv3xuE4JEKBpyE2AbbM_7G0EN1&index=5'
- slidesUrl 'http://fr.slideshare.net/aalmiray/gr8conf-groovy-ecosystem'
- }
-
- video('Metaprogramming with the Groovy runtime') {
- speaker 'Jeff Brown'
- summary '''
- <p>The dynamic runtime nature of Groovy is one of the things that sets it apart from standard Java and makes it a fantastic language for building dynamic applications for the Java Platform.
- The metaprogramming capabilities offered by the language provide everything that an application development team needs to build systems that are far more capable than their all Java counterparts.
- This Part 1 of 2 will cover the runtime metaprogramming capabilities of Groovy. The session will dive deep into Groovy's Meta Object Protocol (MOP) which implements the incredibly dynamic runtime dispatch mechanism.
- The session will include a lot of live code demonstrating really powerful runtime features of the language.
- This session is focused specifically on Groovy's runtime metaprogramming capabilities.
- Part 2 of 2 will cover Groovy's compile time metaprogramming capabilities</p>
- '''
- pictureUrl 'metaprogramming-part-1.png'
- videoUrl 'https://www.youtube.com/watch?v=1xvg8Wcj-hg&list=PLwxhnQ2Qv3xuE4JEKBpyE2AbbM_7G0EN1&index=9'
- }
-
- video('Groovy Puzzlers') {
- speaker 'Noam Tenne'
- summary '''
- <p>Remember the epic Java Puzzlers? Here's the Groovy version, and we have some neat ones!
- Even though we are totally a Grails shop here at JFrog, some of these had us scratching our heads for days trying to figure them out.
- And there is more!
- Contributions from the truly Groovy senseis, including Guillaume Laforge, Andr�s Almiray, Tim Yates, Ken Kousen
- make this talk an unforgettable journey to Groovy.
- In this talk, you'll have the expected dose of fun and enlightenment hearing about our mistakes and failures, great and small,
- in hard core Groovy/Grails development.</p>
- '''
- pictureUrl 'groovy-puzzlers.png'
- videoUrl 'https://www.youtube.com/watch?v=GfIhxi7L6R0&list=PLwxhnQ2Qv3xuE4JEKBpyE2AbbM_7G0EN1&index=17'
- }
-}
-
-courses {
- course('The Complete Apache Groovy Developer Course') {
- instructor 'Dan Vega'
- url 'https://www.udemy.com/apache-groovy/?couponCode=LEARN_GROOVY'
- description '''
- <p>I am going to teach you everything you need to know to start using The Groovy Programming language. This course is really designed
- for 2 different types of people and I think both will benefit from it. If you\u2019re a beginner programmer with a some experience in
- another language like Python or Ruby this course is for you. Dynamic languages are generally thought of as easier for total beginners
- to learn because they\u2019re flexible and fun. If you\u2019re an existing Java Developer (Beginner or Experienced) this course is also for you.</p>
-
- <p>This course is packed with almost 14 hours of content. We are going to start off with getting your development environment up and running
- and then go through the very basics of the language. From there we are going to build on that in each section cover topics like closures, meta-programming,
- builders and so much more. I feel like this is one of the most complete courses around and I am excited for you to join me on this adventure.</p>
- '''
- cover 'groovy-course-cover.png'
- }
-}
http://git-wip-us.apache.org/repos/asf/groovy-user-site/blob/de805f31/site/src/site/wiki/groovy-release.adoc
----------------------------------------------------------------------
diff --git a/site/src/site/wiki/groovy-release.adoc b/site/src/site/wiki/groovy-release.adoc
deleted file mode 100644
index 63820de..0000000
--- a/site/src/site/wiki/groovy-release.adoc
+++ /dev/null
@@ -1,132 +0,0 @@
-= Adapting the release process for Apache
-C�dric Champeau <cc...@apache.org>
-v1.0, March 27, 2015: First version
-
-:teamcity: http://ci.groovy-lang.org
-:groovy: http://groovy-lang.org
-:bintray: https://bintray.com/[Bintray]
-:gradle: http://gradle.org[Gradle]
-
-The goal of this document is to review the current release process for Groovy, and what adaptations are required to fit into the Apache model.
-
-== The Groovy Way
-
-During the last 4 years, 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].
-** 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/[GVM] 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 active branches that we maintain, which are usually released the same day.
-
-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 from the Groovy website. The Maven artifacts, on the other hand, are hosted in JCenter and Maven Central.
-
-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 https://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's been there 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 we consider is what are exactly the deliverables. If the only deliverable is the source zip, because only sources matter (see 3.6), then we could potentially rename only the source zip to include incubating. The binaries, the properties file, etc, could stay with 2.4.3 (without incubating) because it doesn't seem to be mandatory that the *version number* includes incubating, only the filenames. And if we produce binaries that are not hosted at Apache, like we do now, they can follow their own pattern. Thi
s would imply that in Groovy, the only deliverable that would be done through Apache would be the source zip, and the *filename* could include incubating. All other artifacts would *not* belong to the release checklist._
-
-* 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
-
-