We are pleased to announce that version 2.0 of Buildship—our official Gradle support for Eclipse—is now available via the Eclipse Marketplace. This release adds support for composite builds, greatly reducing development turnaround time. The UI has been redesigned based on plenty of community feedback during the 1.x line. Project synchronization is now more accurate and project import requires one less step. We’ve added support for Gradle’s offline mode (thanks Rodrigue!), and last but not least, third-party integrators can take advantage of our new InvocationCustomizer extension point. Read on for details about each of these new features.
Composite build support
What is a composite build?
The composite build feature in Gradle allows you to handle several distinct Gradle builds as if they were one big multi-project build. This dramatically shortens the turnaround time when you need to work on several projects that are normally developed separately.
Let’s assume you have written a Java library lib, used by many of your applications. You find a bug which only manifests itself in the special-app. The traditional development workflow would be to change some code in lib and install a snapshot into the local repository. Then you would have to change the build script of special-app to use that new snapshot and check if the bug is actually fixed.
With composite builds, however, you can tell Gradle to treat both of these projects as one. This will let special-app depend directly on the output of the lib project.
If you develop special-app you probably have it imported in Eclipse with lib referenced as a binary dependency.
There is not much difference between working with composite builds at the command line and working with them within Eclipse. To include lib you need only add an entry to your settings.gradle file, telling Gradle from which folder the additional build should be included.
includeBuild'../lib'
Then, to apply the changes right-click on the project and select Gradle > Refresh Project. After the synchronization finishes, you should see two things: the project from the included build is imported and the binary dependency is replaced with a project dependency.
Now, you can make changes to both projects with the benefit of complete IDE support: error markers, code completion, refactoring and more. Also, if you execute Gradle tests—or any other build task—from the Gradle Tasks view, the execution considers changes from the included builds.
Limitations
When using composite builds from the IDE you should be aware of the following limitations:
Composite builds support only works if the imported project uses Gradle 3.3 or above.
Including WTP projects into a composite is not supported.
Design overhaul
We updated the Buildship user interface to align it with current Gradle branding as well as with the Eclipse design guidelines. The icons are now distinguishable by color-blind people and work well with Eclipse’s dark theme. Finally, high-definition images have been put in place for use with High-DPI displays.
Import wizard simplification
We removed JAVA_HOME, program arguments, and JVM arguments configuration from the import and new project wizards. Users can still configure these properties via the gradle.properties file.
More accurate project synchronization
In Buildship 1.x if the project being imported had Eclipse descriptors then a dialog was shown to determine if those descriptors should be updated or deleted. This behavior was error-prone and distracting for users.
To avoid showing a dialog, we improved the project synchronization algorithm the following way: If the Gradle version used by the project can provide a specific attribute (e.g. project natures), it is completely overwritten. Manual modifications are only kept if Gradle provides no information about that attribute. This allows users of older Gradle versions to work around missing information in the model, while giving users of new Gradle versions a much more consistent experience.
Offline mode support
Users can now set Buildship to work offline via the workspace preferences. Once enabled, all Gradle invocations will receive an extra --offline argument.
InvocationCustomizer extension point
The InvocationCustomizer extension point enables Eclipse plugins to contribute extra arguments to Gradle builds. This allows integrators to add init scripts or control project properties from the IDE. For a sample implementation check out the Buildship documentation.
Breaking changes
This release introduces the following breaking changes:
Minimum Java version set to 1.7
Minimum Eclipse version is set to 4.2
Project renaming is disabled for projects that are located directly under the Eclipse workspace location.
Projects migrating from Eclipse Mars directly to Eclipse Oxygen need to be reimported
JAVA_HOME can no longer be configured on import, please use gradle.properties instead
Java arguments and Gradle properties can no longer be configured on import, please use gradle.properties instead
Installation
Buildship 2.0 is available from the Eclipse Marketplace or from the eclipse.org update sites. Please note that the update site URL has changed therefore no automatic update is available for this release.
Build scans are a great way to easily share data about your build, but what if your team wants to add their own data to those build scans? They can! In addition to the extensive information automatically captured in build scans, you can attach your own custom data to provide even deeper insights into your build. This custom data can take the form of tags, links, and arbitrary custom values in a key-value format.
By adding custom data to your build scans you can make it easy to find builds of a certain type, give quick links to the applicable source code commit on GitHub, add helpful CI build information, and much more. Then, when you share the single build scan link with a teammate, they get quick and easy access to a plethora of information about your build, making it easier for them to diagnose build environment issues, fix test failures, and so on.
Now let’s go through some examples of adding custom data into your build scans (see the user manual for additional examples).
Tags
Let’s start with the simplest type of custom data: tags. Tags are a way to add simple pieces of metadata to your build scan. You can use tags to add context to your build, such as whether the build was run locally or on a CI server, whether the build had any local changes, the error type of a failing build, etc. Here is an example build scan that tags the build as having:
run on CI
come from the master branch
included local code changes (“dirty”)
For example, to attach a tag showing whether the build ran locally or on a CI server, you can add the following to its build script:
The tag is then displayed under the project name when viewing the build scan:
Links
In addition to tags, you can include links that readers of your build scan might find useful. For example, you could include a convenient link to the project source on GitHub or a link to the CI results of the Gradle build. This example build scan demonstrates what such links look like.
Let’s say your CI tool makes the build results URL available as an environment variable. You could grab that value and add it as a custom link by using the following code in your build script:
You also have the flexibility to add a link to the current revision or commit of the project’s source code. The following example links the build scan to its corresponding commit on GitHub (as long as the Git command line tools are available):
Links are displayed in the top section when viewing the build scan:
Custom values
Custom values can be used to make any information part of the build scan. In this example build scan, you can see the corresponding CI build date, CI build number and the name of the Git branch as custom values. These values are available when viewing the build scan or when searching for build scans in Gradle Enterprise. Let’s go through a couple of examples showing how you can add custom values to your build scan.
In our first example, we assume your CI tool injects build information into the build via environment variables. You could then use the following code in your build script to attach the build number and date to the build scan:
Since we are setting these custom values from inside a Gradle build script, you have the power to do things like run external commands to capture more information about the project status. For example, you could add the current Git branch of the build by running a Git command and setting a custom value with the result:
The custom values are displayed on the main page when viewing the build scan:
Command line
To give you greater flexibility in how you pass custom data to your build scan, you can also specify tags, links, and custom values on the command line. For example, you can quickly attach ad-hoc information to your build scan in order to:
help debug a specific local build failure
tag an experimental build
add CI-specific custom data without modifying your build script
You do this by specifying system properties with the appropriate names, as demonstrated by these examples:
The first adds a tag named “EXPERIMENTAL”, the second adds a link titled “buildUrl”, and the third adds a custom value called “buildNumber”.
Searching based on custom data
When using build scans on-premises with Gradle Enterprise, you can search for build scans based on custom data such as tags and custom values. For example, you can search for all builds that ran on CI against the master branch using the terms shown in this screenshot:
Live Demo
For a live demo of adding custom data with even more examples, check out this recent talk by Luke Daley and Etienne Studer at the Bay Area Gradle Users meetup. The video starts with an overview of build scans and dives into the details of adding custom data around the 22:30 mark.
Adding custom data to your build scans gives you the power and flexibility to augment your build scans with tags, links, or other data tailored to your team’s specific needs. Then you have even more information available to easily share with your teammates in a build scan—reducing the guesswork of diagnosing build failures. Happy scanning!
Getting started with a new technology can be daunting. Learning the basics by reading manuals and blog posts and searching forums can be time-consuming. And getting a whole team up to speed is a challenge all its own. That’s why for years now, we’ve offered a range of Gradle training courses to help teams fast-track the process of learning and mastering Gradle.
Our flagship Introduction to Gradle course has always been our most popular, and in October we ran an experiment with it: we gave it away for free. That’s a steep discount from the usual price of $900 per seat, but we wanted to see just how many people we could help to learn Gradle if cost were not a factor.
We’re happy to report that this first free training was an overwhelming success, and are even happier to announce that we’ll offer a second free Introduction to Gradle training on January 11th and 12th. The course will be led by Gradle veterans Gary Hale and Ben Muschko over these two consecutive, 4-hour training days.
In it, you and your colleagues will get everything you need to start creating and running your own Gradle builds with confidence. There will be plenty of hands-on labs and opportunies for Q&A with the instructors. We look forward to seeing you there!
We’d like to thank everyone that came along to our Bay Area Gradle Users meetup last week, and we’d like to thank LinkedIn once again for hosting us—it was a great event! For those who were unable to attend for reasons of distance, time or anything else, we filmed both sessions and are delighted to make the videos available to everyone.
As described in that earlier blog post, Szczepan Faber and Hans Dockter talked in detail about Gradle’s new composite build feature:
In particular, Szczepan demonstrated the potential for working with multi-repository projects in an IDE as if they were part of the same multi-project build. You’ll find that in the first 10 minutes of the video.
That talk was followed by Luke Daley and Etienne Studer presenting the advantages of using custom data in your build scans:
It’s well worth setting aside some time to watch both of these if you can.
We hope you find these videos useful and we look forward to seeing many of you at the next meetup!
For those of you who can’t make our Bay Area meetup on November 15th, we’re putting on a webinar a couple days later that will cover one of the same topics: customizing build scan data. Even better, the webinar will be delivered by one of Gradle’s best: Mark Vieira! So come join us for a half-hour of valuable learning and discover how to maximize the benefit of your build scans.
Everyone has an opportunity to engage with the Gradle team online through a variety of channels, but nothing beats meeting people face to face. If you are around the Silicon Valley area on November 15th, you can meet three of the team at the Bay Area Gradle Users meetup along with an expert user and build master from LinkedIn.
We have two great talks lined up, the first of which introduces you to an exciting new feature within Gradle—composite builds—while the second shows you how to get more out of your build scans with custom data.
Details:
Who? Hans Dockter, Szczepan Faber (LinkedIn), Luke Daley, Etienne Studer
Hans Dockter and Szczepan Faber on Composite Builds
Many of you will be familiar with Gradle’s multi-project build support which allows you set up dependencies between projects, e.g. where the output of one project—say, a JAR file—is required by another. But this only works if the projects are part of the same multi-project build.
In this talk, Hans and Szczepan will explain how Gradle’s new support for composite builds extends this behavior to projects that are otherwise independent of one another. Want to test a local fix to a library one of your projects depends on? Now you can—without having to publish a new version of that library. Composite builds also enable structuring your projects in new ways, since you no longer need to keep all projects in one repository or directory hierarchy.
Hans won’t just talk about the topic, he’ll also show you how the feature works in practice. You’ll come away with a firm understanding of the value of composite builds and how you might put them to use in your own projects.
Luke Daley and Etienne Studer on Customizing Build Scan Data
Build scans already provide deep insights into your build by reporting key metrics and data. These are incredibly useful on their own, but Gradle is designed around the understanding that no two builds are the same. That’s why build scans allow you to add custom tags, links, and values from your builds. These custom annotations can help you bring out insights that are very specific to your build and to the environment in which your build is run.
In this talk, Luke and Etienne will show examples of how you can use this feature to add extra value to your build scans. The aim is to sow the seeds of inspiration for your own builds using a feature that you might otherwise overlook.
Five months ago we announced the first pre-release of Gradle Script Kotlin, and we thought now would be a good time to review the progress we’ve made since. We have shipped eight additional pre-releases during that time, and the road to 1.0 is looking clearer every day. So let’s take a look at the ground we’ve covered so far and where we’re going from here, shall we?
v0.1.0
As you may recall, this is what our hello-world sample looked like at the time of our first release:
Oh, that annoying org.gradle.script.lang.kotlin.* import! The publicly condemned, IDE unfriendly, string-based "testCompile" dependency configuration! And of course—for those souls brave enough to have tried them—the infamous generateKtsConfig and patchIdeaConfig tasks required to get Kotlin-based build scripts working in IDEA. These were early days, no doubt, and they brought with them a few rough edges.
But despite its flaws, the programming language and IDE experience in 0.1.0 was already so good it got us hooked. As for the rough edges, we could already see ways to smooth them out, which led to the release of 0.2.0 one month later.
Seamless project imports meant that Kotlin-based builds in IDEA started working out of the box, and the days of mistyping generateKtsConfig and patchIdeaConfig were no more.
gradle.buildFinished(closureOf<BuildResult>{println("$action finished")// $action refers to BuildResult.getAction()
})
With Gradle 3.0 out the door, the #gradle channel of the public Kotlin Slack saw an increase in participation which helped us greatly in prioritizing the work that would come next.
v0.3.1
We noticed people struggling with the lack of a more type-safe and IDE-friendly way of configuring dependencies, so 0.3.1 came with a much-improved dependencies DSL:
This syntax didn’t read very well, and was a departure from the fluid, readable DSL Gradle has long been known for. But never fear—with 0.3.2 it was gone:
Gradle has been an open-source project since its inception, but as a team we haven’t always lived up to the spirit of modern open-source collaboration. For example, we haven’t made it easy for folks to stay abreast of what we’re working on, and we haven’t had a clear and simple process for users to submit feature requests or bugs against a proper issue tracker.
We’re very happy to announce that all of that is changing today. We’ve opened up GitHub Issues on the Gradle repository, and what follows are the immediate, medium-, and long-term changes we’re making to put—and keep!—the needs of the Gradle community front and center.
Effective Immediately
✔︎ You can now submit feature requests and bugs through GitHub Issues. We’ve put together a simple set of guidelines in the form of an issue template so you’ll be presented with them each time you submit a new issue. We’ll label issues that don’t follow these guidelines as not-actionable and we’ll add a comment asking for what’s missing. To keep things clean, we’ll close these issues after a week of inactivity.
✔︎ Actionable issues you submit will be prioritized alongside other Gradle improvements. Low-cost changes that benefit a large number of users are the easiest to justify, so please add a 👍 reaction to issues that matter to you. Like many other GitHub projects, we’ll use these reactions as a simple kind of voting system.
✔︎ We’ll manage issue priority and workflow using ZenHub. If you’re not already familiar, ZenHub adds a number of features to GitHub Issues through its clever browser extension. It allows us to group related issues into epics and to visualize everything via a kanban board. Installing and using ZenHub is by no means a requirement, but do check it out if you’d like to get an additional level of insight about what we’re working on.
✔︎ Issues that are well-suited for community contribution will be labeled help-wanted. Take a look—you’ll see there are already a few there.
✔︎ Pull requests will be acknowledged within a week and reviews of them will be done through GitHub’s built-in pull request reviews. Please continue to follow the contribution guidelines—in a project as large and widely-used as Gradle, it’s crucial to be rigorous and get things right.
Medium-Term Transition
Open JIRA issues will be migrated to GitHub, and no new issues will be put into JIRA after the release of Gradle 3.2. We’ll ask for examples and/or clarification on JIRA issues that are not actionable so that they can be prioritized.
To draw a clearer roadmap, we’ll add and maintain high-level feature epics and mark them with milestones representing future Gradle releases.
Our bugs forum will no longer be necessary and will be made read-only. For general usage questions and potential bugs for which no reproducible test case or build scan can be provided, please continue to use the help/discuss forum.
Long-Term Unity
Once we’ve made the changes detailed above, we’ll continue looking for ways we can open up Gradle ecosystem to even greater community contribution. We’re really excited about this, and we hope you will be too.
We’d love to hear your feedback—let us know what you think in the comments on this post or talk to us @Gradle on Twitter. Your suggestions, questions, and of course, issues are most welcome.
It’s not every day that we get to announce a feature that revolutionizes several software engineering workflows, but today is that day. Composite builds, a new feature in Gradle 3.1, enables an entirely new dimension in project organization.
Composite builds are a way to join multiple independent Gradle builds and build them together. The brevity of that statement does not fully convey all of the new possibilities, so let me show you how this will make your life as a developer a lot easier.
Joining projects
Many organizations split their code base into several independent projects, each having a dedicated repository and release cycle. Integration between the projects is managed using binary dependencies, e.g. JAR files published to a binary repository like Artifactory. This approach has many advantages, but can be inefficient when trying to rapidly develop and test changes that affect two or more of these projects at once.
Imagine for a moment that you are fixing a bug in a Java library that your application depends on. Your workflow probably looks something like the following:
Change the library
Publish the library to a local repository
Add the local repository to your application’s repositories
Change your application’s dependency to the new library version
Test your application
Repeat until the problem is fixed or you lose your mind
With composite builds, you can short-circuit this workflow by including the library’s build into your application’s build. Gradle will then automatically replace the binary dependency on the library with a project dependency—meaning that changes you make to the library become available to the application instantaneously:
The same approach works for plugins that your project depends on. You can now include a locally checked-out version of a plugin into your project’s build and get into the same kind of tight development loop between them:
The new includeBuild() API in settings.gradle even lets you write a Gradle build that dynamically includes other builds if they are available on the local file system. You could then import this composite into your IDE and do cross-repository refactoring or debugging.
Splitting Monoliths
Organizations that want to avoid the integration pains of multiple repositories tend to use a “monorepo”—a repository containing all projects, often including their dependencies and necessary tools. The upside is that all code is in one place and downstream breakages become visible immediately. But this convenience can come at the cost of productivity: a given developer will usually work only on a small part of a monorepo, but will still be forced to build all upstream projects, and that can mean a lot of waiting and wasted time. Likewise, importing large monorepo projects into an IDE often results in an unresponsive and overwhelming experience.
With composite builds, you can break your monorepo up into several independent builds within the same repository. Developers can work with the individual builds to get fast turnarounds or work with the whole composite when they want to ensure that everything still plays well together:
If you’re planning to move from a monolithic application to multiple independent ones, composite builds now offer a seamless migration strategy.
This is just the beginning
We plan to add a number of improvements to composite builds in upcoming releases:
Targeting tasks in an included build from the command line
Richer dependency substitution API with support for custom publications
Out of the box support for composite builds in IntelliJ and Eclipse
Of course, nothing is more important than feedback from real world usage. So please give composite builds a try in your own projects or have a look at the samples. Let us know about any problems, suggestions and cool things you built with it on the Gradle Forum.
A few months ago at this year’s Gradle Summit conference, we announced a new part of the Gradle platform called Gradle Cloud Services. In this post, I want to introduce you to the first of these services—the Gradle Build Scan Service—and the build scans it makes possible.
What is a build scan?
A build scan is a representation of data captured as you run your build. The Build Scan Plugin does the work of capturing the data and sending it to the Build Scan Service. The service then transforms the data into information you can use and share with others. Here’s a quick example of using a build scan to investigate a failure:
As you can see, the information that scans provide can be a big help when troubleshooting, collaborating on, or optimizing the performance of your builds. For example, with a build scan in the mix, it’s no longer necessary to copy and paste error messages or include all the details about your environment each time you want to ask a question on Stack Overflow or the Gradle Forum. Instead, just include a link to your latest build scan. It contains much, if not all, of the information the person answering your question might need to know. It’ll save you both time, and they’ll probably thank you for it.
Who’s using them?
We’re excited that a number of prominent open source projects like Hibernate and JUnit 5 have alreadyintegrated build scans into their workflow. You can take a look through sample scans from each of these projects at gradle.com/explore.
Put build scans to use for yourself
If you’re new to build scans, now is a great time to start using them. We’re continually rolling out new features, and we’ll cover each of them in subsequent posts. In the meantime, you can learn how to enable build scans for your existing projects via our getting started instructions, or get up and running with a sample project by cloning our quick start repository and following the steps in its README.
Happy scanning, and we look forward to your feedback!
