eclipse / buildship

The Eclipse Plug-ins for Gradle project.

Eclipse Buildship: Gradle integration for the Eclipse IDE

Buildship is a set of Eclipse Plug-ins that provide a deep integration of Gradle into the Eclipse IDE. Buildship is hosted on eclipse.org.

Requirements

Buildship can be used with Eclipse IDE 4.2.x or newer. Older versions of Eclipse the IDE might work but have not been tested explicitly. Depending on the version of Gradle that Buildship interacts with, certain features of Buildship may not be available.

Documentation

All documentation of Buildship for users and developers is hosted on GitHub.

More specifically, you can find

• User documentation (plugin installation, current functionality)
• Developer documentation (development environment setup)
• Build documentation (building Eclipse projects with Gradle)
• Outline of upcoming stories

Discussions & News

We are very interested in feedback from the Gradle and Eclipse communities. All things Buildship are discussed on the Gradle Forums.

Issue Tracking

Issues are tracked on GitHub. Add your 👍 for issues that you care about to help us prioritize them. If you want to follow our priorities and progress, install the ZenHub extension and have a look at our board.

License

Buildship is available under the Eclipse Public License, Version 1.0.

buildship's Issues

Composite task execution

Issue by oehme
Monday Apr 25, 2016 at 14:17 GMT

---

Task and test execution should happen in the composite to provide the same user experience as in Eclipse. Since dependencies are substituted in the IDE, the user will rightfully expect that they are also substituted when running a Gradle task or Gradle test.

Build Scans integration

Motivation

We want users to be aware of the value that build scans provide, Eclipse could be a great vehicle to raise that awareness.

For users who are already aware of Build scans, we want to make it easy to get a scan from a project in the IDE

Add smoke tests to release process

Issue by oehme
Thursday May 19, 2016 at 09:07 GMT

---

Motivation

There is quite a bit of complex logic involved in Building the update sites for Buildship. Anything that goes wrong there is currently not covered by automated tests, but only through manually trying out the release. It would be great to have a simple smoke test that installs the new release into a fresh Eclipse and imports a simple project - just to make sure the release is installable and has basic function.

Proposed Change

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Collect projects using Kotlin build script and evaluate Buildship on them

Issue by donat
Monday Jan 30, 2017 at 08:58 GMT

---

Remove user-defined lib entries from classpath

Issue by oehme
Friday Jan 27, 2017 at 18:30 GMT

---

Motivation

If the user ever called gradle eclipse, then there will be lib entries on the classpath. Buildship on the other hand manages all lib entries in the classpath container. We should actively remove lib entries from the existing classpath on synchronization.

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Start discussion with JetBrains how to get rid of the need for ScriptTemplateProviderEx.getTemplateClassClasspath()

Issue by donat
Tuesday Jan 31, 2017 at 10:25 GMT

---

@oehme's comment on #202

This should not even be necessary, we should talk to the JetBrains team about this. There absolutely no need to load the template class at this point. It introduces a synchronous call which may result in synchronously downloading Gradle etc. Our ScriptTemplateProvider can already tell the Kotlin plugin if it applies and what dependency resolver to use. So there is no need to load the template in order to look for the same information on some annotation.

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Full support for partial imports

Issue by oehme
Saturday Apr 30, 2016 at 13:20 GMT

---

Motivation

Users often have very large builds and only want to work on a subset of that build. Nevertheless, that subset might have dependencies on other projects. If those projects are not imported, the classpath of the dependents is incomplete. This means that users have to import much more projects than they are interested in changing.

We should substitute those project dependencies for external dependencies on the locally built jar of those projects. The jar task should be automatically invoked as part of the project synchronization.

Proposed Change

• The TAPI needs to provide information how to build a substitute for a project dependency if that project is not imported into the workspace
• Buildship replaces the project dependency in the classpath with an external dependency on the locally built jar
• The jar is built as part of the project synchronization

Kotlin script support should provide Javadoc in the corresponding view

Issue by donat
Monday Jan 30, 2017 at 09:00 GMT

---

Write up use cases for build scan integration

Write .project/.classpath only once

Issue by oehme
Thursday May 19, 2016 at 09:20 GMT

---

Motivation

File I/O is currently the biggest time sink in our project synchronization code. Reducing it to the absolute minimum would improve Buildship's performance, especially for builds with many sub-projects.

Proposed Change

Every one of our small updaters (e.g. the BuildCommandUpdater or ProjectNatureUpdater) flushes its results to disk. We should optimize that so each updater only modifies the in-memory model of the Eclipse project and then flush to disk once. The same goes for the classpath. We should pass along the classpath to modify and then only call setRawClasspath() once.

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Integrate existing Kotlin support to Buildship and let people try it out

Issue by donat
Friday Jan 13, 2017 at 10:35 GMT

---

Motivation

Proposed Change

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Support basic import of broken projects

Issue by oehme
Thursday May 19, 2016 at 09:15 GMT

---

Motivation

Sometimes the user checks out a project that has an error in the build script which prevents us from fetching its Eclipse model. Currently Buildship refuses to import such projects at all. The user then has to open a plain text editor, find the faulty buildscript and fix it.

Buildship could import just the root project as a "plain" Eclipse project. This would allow the user to fix up the build script and then retry by just right-clicking and hitting "Refresh Gradle Project" without ever leaving Eclipse.

Proposed Change

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Consume Tooling API directly from Buildship

Issue by donat
Monday Jan 09, 2017 at 15:22 GMT

---

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Use TAPI directly for task execution

Issue by oehme
Monday Jan 23, 2017 at 14:23 GMT

---

Instead of using ToolingClient and ExecuteTaskRequest use ProjectConnection and LongRunningOperation directly.

On synchronization errors, creating/opening the build scan is offered as a "fix"

Issue by oehme
Monday Jan 23, 2017 at 14:04 GMT

---

Motivation

Users often encounter errors when synchronizing their project. Most of the time these are caused by errors in the build. Publishing a build scan can help troubleshoots these situations significantly.

Proposed Change

Once #117 is implemented, register two quick fixes which behave exactly like the buttons described in #129 and #130.

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Integrate with Kotlin Eclipse bundles

Issue by etiennestuder
Saturday May 21, 2016 at 18:23 GMT

---

Motivation

Whatever the title means in detail, as Kotlin is becoming a first-class citizen build language for Gradle, we will need to provide the ability to support Kotlin build code editing in Eclipse.

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Buildship should use Kotlin build script dependency resolver from GSK

Issue by donat
Tuesday Jan 31, 2017 at 14:06 GMT

---

Currently we hack into GSK by adding a copy of KotlinBuildScript and replacing the referenced resolver with a local one. We should probably change the resolver class in GSK such that we can directly reuse it from Buildship.

Reduce CorePlugin API

Issue by oehme
Thursday May 19, 2016 at 09:27 GMT

---

Motivation

At some point in the future we want to publish an API that allows integrators to import Gradle projects. Currently our CorePlugin has references to all kinds of things that are really just internal implementation details and not useful for external consumption.

Proposed Change

We should clearly separate these APIs and reduce the CorePlugin to something we are comfortable with maintaining in the long run. This might also be a good time to give it a better name like GradleCore.

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Opening Kotlin build scripts should not block UI

Issue by donat
Monday Jan 30, 2017 at 08:58 GMT

---

Support test filtering in Buildship build

Issue by oehme
Thursday May 19, 2016 at 09:05 GMT

---

Motivation

Since the Buildship build uses a custom test runner (actually running an Eclipse application), the --tests command line option currently has no effect. If it is not possible to support it, we should at least throw an exception that tells the user so.

Proposed Change

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Project dependencies should be at the beginning of the classpath container

Issue by donat
Wednesday Feb 01, 2017 at 12:53 GMT

---

Motivation

https://discuss.gradle.org/t/eclipse-classpath-ordering-project-dependency-always-at-the-bottom-of-dependencies

Proposed Change

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Include Kotlin tools in Oomph model

Issue by donat
Tuesday Jan 31, 2017 at 14:02 GMT

---

Kotlin script support should provide Javadoc

Issue by donat
Monday Jan 30, 2017 at 08:59 GMT

---

Javadoc should be visible at

• editor hover
• Javadoc view
• content assist

User can easily find the scan link in the execution view

Issue by oehme
Monday Jan 23, 2017 at 13:49 GMT

---

Motivation

Searching for the build scan link in the console view is unintuitive, because Buildship generally presents the build in the execution view. This view is what the user is mostly focussed on. We should add a UI element that takes the user to the scan if one was created.

Proposed Change

• Add a Open Build Scan button to the execution view's toolbar
• Find the build scan link
  • either by parsing the console output
  • or by using some API
• If a scan was published, let the button open it in the system browser
• If no scan was published, disable the button
• Consider older Gradle and scan plugin versions

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

After a new Buildship release send email reminder about the items to address manually

Issue by oehme
Thursday May 19, 2016 at 09:01 GMT

---

Motivation

It's easy to forget a step in the release process, so having a friendly reminder from the Build server would be great.

Proposed Change

Send out an email with the necessary post-release steps, just like we do for Gradle Core.

The current steps are:

• Create a Forum post in the Buildship forum (tag it with 'buildship-release' and pin it for a month)
• Set all fixed issues in Bugzilla to 'closed' and link to the Forum Post

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Basic support for partial imports

Issue by oehme
Saturday Apr 30, 2016 at 13:13 GMT

---

Motivation

Currently Buildship automatically imports new subprojects when the users refreshes the build. Several users have said that they would like to be able to remove some projects from the workspace while keeping others. Even better, they would like an import wizard that allows them to select the projects to include.

If the user really wants to import new subprojects, he could either re-run the
import wizard or we could have an explicit "Import new Subprojects" action in the context menu.

As a first step we will import the subset without doing any dependency substitution. Missing projects would lead to incomplete classpaths. But for a self-contained subset of a bigger repository, this could work without any problem. Think of a monorepo with a library and 5 applications. If you only want to work on the library, that would work fine without any dependency substitution.

In a follow-up story to this work, we could then replace project dependencies with a locally build jar if that project is not imported. This will be possible using the new composite build API.

Proposed Change

• Do not import new sub-projects when just "Refreshing" the workspace
• Offer a project-selection in the import wizard where the user can choose which sub-projects to import
• The necessary infrastructure is already in place (NewProjectHandler)
• The task view and synchronization code can already deal with missing projects

Code review

• Does the change work?
  • Try out the feature, executing it like a end-user would.
  • Check corner cases and try to break it in various ways.
  • Are the error messages informative?
• Is the change sufficiently tested?
  • Are there appropriate levels of unit & integration tests?
  • Do the tests indicate what they are actually testing?
  • Are the tests in the right location?
  • Can new tests be consolidated with any existing tests?
• Is it sufficiently documented?
  • Is the user guide documentation clear and informative?
  • Do the release notes clearly convey the value of the feature?
• Is it implemented well?
  • Does it minimize surface area (particularly public)?
  • Does it follow our coding conventions?
  • Does it use appropriate data structures?
  • Does it minimize potential for invalid states?
  • Does it suitably reuse existing infrastructure?
  • Does it suitably consider concurrency?
  • Does it suitably consider failure modes?
  • Does it suitably consider performance?
  • Does it introduce new types or move existing ones? Are they located in the appropriate package? (e.g. internal classes in internal packages)

Kotlin script support should provide Javadoc in content assist

Issue by donat
Monday Jan 30, 2017 at 09:00 GMT

---

User can enable scan creation in Buildship

Issue by oehme
Monday Jan 23, 2017 at 13:24 GMT

---

Motivation

Assuming that a user is already using the build scan plugin, but doesn't use publishAlways, Buildship should make it easy to enable creation of build scans.

Implementation

• Add a Create build scan(s) option to the workspace, project and run configuration pages, similar to offline mode.
• Honor this option when synchronizing projects or running tasks

The user can then see the scan link in the console output. Making it easier to find the scan for an execution will be part of a different story.

Adding this option prominently might lead to higher usage of the public build scan service, make sure the CS is aware and can monitor the additional load.

Buildship 2.0 doesn’t allow to import projects

Motivation

https://discuss.gradle.org/t/buildship-2-0-doesnt-allow-to-import-projects/21118

Proposed Change

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Send request to include Buildship in the eclipse-jee package

Issue by donat
Thursday Oct 13, 2016 at 08:26 GMT

---

Motivation

We have now full WTP support, might as well make Buildship installed by default in the "Eclipse IDE for Java EE Developers" package.

Detect root folder automatically

Issue by oehme
Thursday May 19, 2016 at 09:12 GMT

---

Motivation

If the user selects a sub-project in the import wizard, we currently fail only after he clicks 'finish' with the error saying "project is not a root project". Obviously we could have told the user that much earlier. Even better, we could detect the root project automatically and connect to that instead.

This is closely related to partial imports (#16), where the user might not be interested in importing the full project tree. It's reasonable for the user to expect that we understand he wants to import a subset of his projects.

Proposed Change

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

KotlinBuildScriptModel query should be queried via ModelProvider

Issue by donat
Tuesday Jan 31, 2017 at 14:09 GMT

---

This way the fixed and transient request attributes would be set consistently for all model queries.

Buildship informs user how to enable build scans

Issue by oehme
Monday Jan 23, 2017 at 13:58 GMT

---

Motivation

A user might wonder what the "publish build scan" button in the execution view does if he does not yet know about build scans. Similarly he might wonder about the option in the preferences. Buildship needs to provide documentation. This can also serve as marketing for build scans.

Proposed Change

• add documention hover/link in the preferences
• when the plugin was not applied, the "publish build scan button" is active and offers the user documentation (e.g. open a dialog that can take the user to scans documentation)

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Replace OmniXXX models with normal tooling models

Issue by oehme
Monday Jan 23, 2017 at 14:28 GMT

---

Reduce number of places where each method is called so that the overhead of exception handling is not spread over the code base.

PersistentModel methods should not return null

Issue by donat
Tuesday Jan 31, 2017 at 09:34 GMT

---

Motivation

This is a follow-up issue for #196. Currently, the methods defined on PersistentModel might return null if the corresponding attribute is uninitialised or was deleted from the model. The usage of the null values make the usage of this internal API error-prone and thus needs to be changed.

Buildship should accept linked resources as classpath entries

Issue by oehme
Friday Jan 27, 2017 at 18:32 GMT

---

Motivation

Users might want to include folders or jars from linked locations on their classpath for legacy projects.

Proposed Change

If the path of a dependency is project-relative we should check the Eclipse resource tree instead of java.io.File for existence. See https://github.com/eclipse/buildship/blob/master/org.eclipse.buildship.core/src/main/java/org/eclipse/buildship/core/workspace/internal/GradleClasspathContainerUpdater.java#L99

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Fix compiler warning related to Kotlin dependencies

Issue by donat
Tuesday Jan 31, 2017 at 14:03 GMT

---

The options.compilerArgs << '-Werror had to be disabled in the build script because of the following warning:

warning: [path] bad path element "/Users/donat/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-reflect/1.1-M04/50e442efdd3eab1dcf2ddbf4b3ec5dabecf1b2b2/kotlin-runtime.jar": no such file or directory

Use TAPI directly in ModelProvider

Issue by oehme
Monday Jan 23, 2017 at 14:24 GMT

---

• use ProjectConnection/ModelBuilder directly
• use a simpler/more accurate caching theme: Invalidate all of them together when synchronizing, no cache strategy arguments
• still use the OmniXXX models (make them accessible from Buildship)

Offer Buildship Kotlin support on the same platforms where the Kotlin Eclipse plugins are available

Issue by donat
Friday Jan 27, 2017 at 14:52 GMT

---

Buildship adds Eclipse-specific information to build scans

Issue by oehme
Monday Jan 23, 2017 at 14:06 GMT

---

Motivation

When troubleshooting Eclipse-specific issues (e.g. project synchronization), it is helpful to know which Eclipse version and Buildship version the user was using.

Proposed Change

• write a script plugin that configures custom values in the build scan for
  • Eclipse version
  • Buildship version
  • List of other bundles? (beware privacy issues)
  • others TBD?
• inject that script plugin into every build

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Kotlin features should install dependencies automatically

Issue by donat
Friday Jan 27, 2017 at 12:58 GMT

---

Currently the user has to install the Kotlin Eclipse plugin before the Gradle Kotlin support. The installation should install all dependencies automatically.

Buildship documentation

Issue by donat
Monday Dec 05, 2016 at 10:51 GMT

---

Motivation

Buildship is an official eclipse.org project and got the 'mature' flag with the 1.0.3 release, which was published more than a year ago. Yet, it has no official documentation. To get some understanding how to use the tool, the users can only read the following documents:

• release announcements
• GitHub page
• project page on eclipse.org
• marketplace entry
• vogella.de tutorial

The users are confused by this state and on the forums they repeatedly ask how to learn about Buildship in general. So far we directed them to the sites above, or tried to help them directly on the forums. This takes a considerable effort to do and also has an impact on how the project is perceived.

Build scan creation is visible in execution view

Issue by oehme
Monday Jan 23, 2017 at 14:12 GMT

---

Motivation

Build scan upload might take some time depending on the size and the network, the user should see that this operation was started.

Proposed Change

• Let the build scan plugin publish a build operation with the scan link embedded.
• Buildship displays this event along the others
• Double-clicking the node opens the scan
• The context menu on the node can open the scan

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

User can publish a build scan after the fact

Issue by oehme
Monday Jan 23, 2017 at 13:56 GMT

---

Motivation

The user might have forgotten to enable the scan option or might not have anticipated the need for a scan, but now wants to publish it. The scan plugin was active during the build. We need a UI element that allows the user to publish a scan after the fact.

Proposed Change

• Add a Publish last build scan button to the execution view's toolbar
• Find out that the plugin was applied, but no scan was published
  • plugin application can be found by a custom tooling model
  • no scan can be determined by the same logic as #129
• If the plugin was applied, but the scan wasn't published, activate the button and let it run the publishLastBuildScan task
• If the scan was already published, disable the button

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

[deleted]

Remove custom error dialog

Issue by oehme
Friday Jan 13, 2017 at 10:17 GMT

---

Motivation

The custom error dialog requires us to have callbacks into the UI in the core plugin, which makes the API awkward to use (asynchronous, user dialogs instead of exceptions).

Proposed Change

Once #117 is implemented, get rid of the UI callbacks and custom dialog, use normal exception handling and synchronous interfaces instead. This will also make a potential API for integrators simpler, because they can listen for progress and handle exceptions as needed.

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Sort out the legal part of the Kotlin plugins

Issue by donat
Friday Jan 27, 2017 at 10:25 GMT

---

We should handle the legal aspect of the new Kotlin integration. This includes:

• Submitting the dependencies to the IP review (including transitives),
• Verifying that the legal files are valid in the new plugin/feature, and
• Checking how to handle files copied over from the gradle-script-kotlin library.

Use error markers to present project synchronization failures

Issue by donat
Monday Jan 02, 2017 at 15:30 GMT

---

Motivation

• Showing a dialog every time the synchronisation fails is annoying to the users
• Using error markers is in line with the Eclipse UI
• We won't need to rely on the UserNotification interface which was introduce only to invoke UI code from the core plugin

Proposed Change

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Support debugging tests

Issue by oehme
Thursday May 19, 2016 at 09:02 GMT

---

Motivation

Quite often a test surfaces a problem that the user wants to debug. Buildship should offer a "Debug as Gradle test" option, which automatically attaches a debugger to the test running inside Gradle.

Proposed Change

TBD

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.

Add documentation about build scan integration

Issue by oehme
Monday Jan 23, 2017 at 14:14 GMT

---

Motivation

Like every other feature, build scan integration should be mentioned in the Buildship documentation. This can also serve as marketing for build scans.

Code review

• Does the change work?
• Is the change sufficiently tested?
• Is the public API modification handled appropriately?
• Is it sufficiently documented?
• Is it implemented well?

See also the full checklist.