Groovy® is a powerful multi-faceted programming language for the JVM platform. It supports a spectrum of programming styles incorporating features from dynamic languages such as optional and duck typing, but also static compilation and static type checking at levels similar to or greater than Java through its extensible static type checker. It aims to greatly increase developer productivity with many powerful features but also a concise, familiar and easy to learn syntax.
It integrates smoothly with any Java class or library, and immediately delivers to your application powerful capabilities, including scripting support, Domain-Specific Language authoring, runtime and compile-time meta-programming and functional programming.
Distribution links are on the download page.
Maven, Gradle and Ivy dependency declaration snippets are available on specific files of a particular module.
You don’t need the source code to use Apache Groovy but if you wish to explore its inner workings or build it for yourself there are two ways to obtain the source files.
Apache Groovy uses Git. The official Git repository is at:
https://gitbox.apache.org/repos/asf/groovy.git
And a mirror is hosted on GitHub:
https://github.com/apache/groovy
The GitHub mirror is read-only and provides convenience to users and developers to explore the code and for the community to accept contributions via GitHub Pull Requests.
Simply git clone the repo (or the repo you forked via the GitHub website) and you will have the complete source.
Alternatively, you can download the source distribution and unpack it.
If obtaining the source from the source distribution and you intend to build from source, you also need to download and install Gradle and use it to execute one bootstrap step.
As mentioned in the previous paragraph, if you download the source distribution you need to bootstrap Gradle. This isn’t needed if you clone from the GitHub repo.
Each version of Groovy is built and tested using a specific version of Gradle.
That version is specified by the gradle_version property defined in the gradle.properties
file within the root directory. Luckily you shouldn’t need to know that version and,
after bootstrapping, you should use the gradlew command which will ensure the
correct version is always used.
The version of Gradle used for the bootstrap step has some flexibility though in general you might need to download a version similar to the version of Groovy the build is expecting.
To bootstrap Gradle, at the top directory of your unpacked source, run the command:
gradle -p bootstrap
|
Note
|
At this point, the Gradle wrapper should be set up and from now on you should use
the gradlew command instead of gradle. (On Unix-like systems, use ./gradlew).
|
To build you will need:
The build compiles with whichever JDK runs gradlew. To target a different bytecode level, or to run tests on a different JDK, see the "Building and testing against a specific JDK" section in CONTRIBUTING.md.
To build everything using Gradle, use the following command (./gradlew on Unix-like systems):
gradlew clean dist
|
Note
|
The gradlew command automatically downloads the correct Gradle version if needed, you do not need to download it first. |
This will generate a distribution similar to the zip you can download on the Groovy download page.
To build everything and launch unit tests, use:
gradlew test
If you want to launch one unit test, use this. <TestClassName> is like groovy.GroovyMethodsTest.
gradlew :test --tests <TestClassName>
To build a runnable local installation of Groovy with your changes applied, use:
gradlew :groovy-binary:installGroovy
The installation is generated under subprojects/groovy-binary/build/install. Its bin directory contains the groovy, groovysh, and groovyc launchers, so you can invoke subprojects/groovy-binary/build/install/bin/groovy <script> to run a script against the build you just produced.
To build from IntelliJ IDEA:
gradlew jar idea
Then open the generated project in IDEA.
To build from Eclipse:
gradlew jar eclipse
Then open the generated project and the generated subprojects in Eclipse. But be aware that Eclipse tends to be more limited in its ability to reproduce a Gradle build structure. The generated project files may contain a circular dependency which may or may not prevent Eclipse from using them. It depends on the Eclipse version, if this is an issue or not.
To build the documentation (Groovy Language Documentation):
gradlew asciidoc
All code samples of the documentation guide are pulled from actual test cases. To run a single documentation test case, take for example src/spec/test/semantics/PowerAssertTest.groovy
gradlew testSinglePowerAssertTest
|
Note
|
The omission of package name: class is semantics.PowerAssertTest but only PowerAssertTest is added to testSingle.
|
The build uses Gradle dependency verification, so adding or bumping a dependency requires regenerating gradle/verification-metadata.xml.
For the regeneration recipe (including the preferred --dry-run approach), see the Dependency verification section of CONTRIBUTING.md.
Builds run primarily on GitHub Actions; the workflows live under .github/workflows.
A TeamCity server, sponsored by JetBrains, also runs builds here.
Groovy core team tunes performance through YourKit Java Profiler, which is sponsored by YourKit.
As an independent initiative, community members have set up an open collective for Groovy:
This initiative is designed to complement the Apache project and the many contributions we get from our great community and supporters.
-
Thank you to our Silver Sponsors:
-
Thank you to our Bronze Sponsors:
-
Thank you to our backers (donating monthly):
-
Thank you to all our backers:
Groovy is licensed under the terms of the Apache License, Version 2.0
Apache, Apache Groovy, Groovy, and the ASF logo are registered trademarks of The Apache Software Foundation.