Buildship 1.0.18 is now available

Today we have released Buildship 1.0.18. This release contains an exciting new feature that enables users to completely configure the Eclipse classpath. For the details check out the section below. This release also fixes several issues reported by the community.

Improved Java project synchronization

Gradle 3.0 provides a complete classpath configuration model. Previously missing information such as the default output location, source folder excludes-includes and classpath containers are now synchronized in Eclipse. Moreover, the classpath file manipulation done in the eclipse.classpath.file.whenMerged hook is also considered by Buildship.

The following examples demonstrate exactly what and how can you configure a Java project in Buildship:

Default output location

apply plugin: 'java'
apply plugin: 'eclipse'
eclipse {
    classpath {
        defaultOutputDir = file('target/bin')
    }
}
Configured entry in .classpath file

Custom classpath containers

apply plugin: 'java'
apply plugin: 'eclipse'

eclipse {
    classpath {
        containers 'org.eclipse.pde.core.requiredPlugins'
    }
}
Configured entry in .classpath file

Source folder exclude and include patterns

apply plugin: 'java'

sourceSets {
    test {
        java {
            exclude '**/*.groovy'
            include '**/*Test*'
        }
    }
}
Configured entry in .classpath file

Source folder output location

apply plugin: 'java'
apply plugin: 'eclipse'

eclipse {
    classpath {
        file {
            whenMerged {
                def src = entries.find { it.path == 'src/main/java' }
                src.output = "/$eclipse.project.name/classes/main-java"
            }
        }
    }
}

[details=Configured entry in .classpath file]
[/details]

Java runtime

The java runtime name configured in the build is used in Eclipse. If that’s not sufficient, the whole path can be set in the eclipse.classpath.file.whenMerged block.

apply plugin: 'java'
apply plugin: 'eclipse'

eclipse {
    jdt {
        javaRuntimeName = 'Domino'
    }
}
Configured entry in .classpath file

apply plugin: 'java'
apply plugin: 'eclipse'

eclipse {
    classpath {
      file {
            whenMerged {
                def jre = entries.find { it.path.contains 'org.eclipse.jdt.launching.JRE_CONTAINER' }
                jre.path = 'org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 8 [1.8.0_65]'
            }
        }
    }
}
Configured entry in .classpath file

Classpath attributes

Classpath attributes can be set on all classpath entries by modifying the AbstractClasspathEntry.entryAttributes map. This example demonstrates how to configure a source folder to ignore compiler warnings.

apply plugin: 'java'
apply plugin: 'eclipse'

eclipse {
    classpath {
      file {
            whenMerged {
                def source = entries.find { it.path == 'src/main/java' }
                source.entryAttributes['ignore_optional_problems'] = 'true'
            }
        }
    }
}

[details=Configured entry in .classpath file]




[/details]

Access rules

Access rules can be set on every classpath attributes by modifying the AbstractClasspathEntry.accessRules list. The access rule types are defined in the org.eclipse.jdt.core.IAccessRule class.

import org.gradle.plugins.ide.eclipse.model.AccessRule

apply plugin: 'java'
apply plugin: 'eclipse'

eclipse {
    classpath {
        file {
            whenMerged {
                def jre = entries.find { it.path.contains 'org.eclipse.jdt.launching.JRE_CONTAINER' }
                jre.accessRules.add(new AccessRule('1', 'com/**'))
                jre.accessRules.add(new AccessRule('1', 'sun/**'))
            }
        }
    }
}

[details=Configured entry in .classpath file]





[/details]

Library, source and javadoc location

The Classpath.fileReference(Object) method was added to the public API to be able to set custom source and javadoc location for a classpath entry.

import org.gradle.plugins.ide.eclipse.model.Library

apply plugin: 'java'
apply plugin: 'eclipse'

eclipse {
    classpath {
        file {
            whenMerged { 
                def lib = entries.find { it.path.contains 'my-commercial-lib.jar' }
                lib.javadocPath = fileReference(file('libs/my-commercial-lib-javadoc.jar'))
                lib.sourcePath = fileReference(file('libs/m-commercial-lib-source.jar'))
            }
        }
    }
}

[details=Configured entry in classpath container]




[/details]

Declare resources as a library

It can be beneficial to declare resource folders as a library dependencies because this way the contents won’t be copied to the project output location.

import org.gradle.plugins.ide.eclipse.model.Library

apply plugin: 'java'
apply plugin: 'eclipse'

eclipse {
    classpath {
        file {
            whenMerged {
                entries.removeAll { it.path == 'src/main/resources' }
                entries += new Library(fileReference(file('src/main/resources')))
            }
        }
    }
}

[details=Configured entry in classpath container]
[/details]

Installation

Buildship 1.0.18 is available at the Eclipse Marketplace or at the eclipse.org update sites. Users with Buildship already installed can automatically update to the latest version.

1 Like

After upgrading from Buildship 1.0.17 to 1.0.18, I noticed that performing a ‘Refresh Gradle Project’ causes all jars under ‘Project and External Dependencies’ to disappear, leading to compilation problems. In the past any compile/test dependencies declared in my build.gradle would show up there. I verified that the project classpath files under my Eclipse workspace’s .metadata/.plugins/org.eclipse.buildship.core/classpath-persistence directory have indeed been neutered. Has anybody else seen this or have suggestions on how to remedy the problem? I am on Eclipse Neon if that makes any difference.

Thanks,
Craig M.

I think I figured out what’s going on. Prior to 1.0.18, to keep the .classpath files generated by the EclipsePlugin in sync with what Buildship produces, I would explicitly remove all ‘lib’ classpath entries using the whenMerged hook. However now that 1.0.18 is playing nice with the the EclipsePlugin classpath, that bit of logic is no longer necessary.

Thanks,
Craig M.

2 Likes

The Plugin doesn’t work with the Gradle Nested projects. The sub projects don’t see the dependencies from the parent projects or the dependent projects after running the Gradle refresh. We had this working correctly before 1.18. I am not sure if I had switched to 1.17 or was it prior version to that. I will post my finding by switching back to 1.17. Gradle version we are using is 2.10

Please attach a reproducible example when reporting a bug, so we can see what is happening :slight_smile:

Code can be found here https://github.com/vinsleo/gradleplugin1.18
I have checked-in the generated .classpath and .project files
and the steps to reproduce are mentioned there

Sorry - me being new user was not allowed to upload the zip file

Thank you for the example. The problem is that AppTest is trying to load a class from a testCompile dependency of the common project. Test dependencies are not exported to downstream projects by default. Buildship accidentally exported them in earlier versions and has been fixed in 1.0.18, so it behaves exactly as Gradle on the command line.

If swagger is a runtime dependency of the common project, it should be declared as such. If not, then either app needs to add that dependency itself or it needs to declare that it’s tests reuse the test dependencies of common.

Hello,

We use a combination of 2.x gradle and Java 6 for our build process. Recently, we downloaded the updated buildship plugin 1.0.18 (which we found requires a minimum Java 7 version due to a dependent gradle tooling api 3x jar). 1.0.18 is supposed to be a bug fix patch and raising the minimum required jdk version to 7 doesn’t make sense (i.e., we do not need java 7 with our current build process and therefore would only require it for buildship… which just kicks off our builds). I would think a dependency to an updated jdk version would be better suited in a new buildship release (e.g., 2.0), rather than a patch.

We tried uninstalling the 1.0.18 plugin to switch to the previous version. The uninstallation process doesnt work smoothly either. The 3x version of the gradle tooling api jar does not uninstall and while installing 1.0.17, the 3x version remains (i.e., doesn’t get replaced with the 2.14 version). We have had to manually remove the 3x version of the gradle tooling api jar and replace it with 2.14 to bypass the Java 7 dependency.

Hi Ankita,

Could you please attach the full stacktrace of the failure?

Cheers,
Stefan

Hey Stefan,

I am working with Ankita on this… below is the stacktrace/code we are hitting the issue while kicking off a build. FYI, we are using the eclipse e37 target to download.

org.gradle.internal.jvm.UnsupportedJavaRuntimeException: Gradle Tooling API 3.0 requires Java 7 or later to run. You are currently using Java 6.
       at org.gradle.internal.jvm.UnsupportedJavaRuntimeException.assertUsingVersion(UnsupportedJavaRuntimeException.java:33)
       at org.gradle.tooling.internal.consumer.ConnectorServices.checkJavaVersion(ConnectorServices.java:66)
       at org.gradle.tooling.internal.consumer.ConnectorServices.createCancellationTokenSource(ConnectorServices.java:48)
       at org.gradle.tooling.GradleConnector.newCancellationTokenSource(GradleConnector.java:108)
       at org.eclipse.buildship.core.util.progress.ToolingApiJob.<init>(ToolingApiJob.java:57)
       at org.eclipse.buildship.core.launch.BaseLaunchRequestJob.<init>(BaseLaunchRequestJob.java:54)
       at org.eclipse.buildship.core.launch.RunGradleBuildLaunchRequestJob.<init>(RunGradleBuildLaunchRequestJob.java:45)
       at org.eclipse.buildship.core.launch.GradleRunConfigurationDelegate.launch(GradleRunConfigurationDelegate.java:44)
       at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:854)
       at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:703)
       at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlugin.java:937)
       at org.eclipse.debug.internal.ui.DebugUIPlugin$8.run(DebugUIPlugin.java:1141)
       at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

The problem code is the following:

1.0.18 - 3.0 GRADLE TOOLING API
unit id=“org.gradle.toolingapi” version=“3.0.0.v20160817124109”

public class ConnectorServices {
    ...
    private static void checkJavaVersion() {
        UnsupportedJavaRuntimeException.assertUsingVersion("Gradle Tooling API", JavaVersion.VERSION_1_7);
    }
    ...
}

1.0.17 - 2.14 GRADLE TOOLING API
unit id=“org.gradle.toolingapi” version=“2.14.0.v20160614100625”

public class ConnectorServices {
    ...
    private static void checkJavaVersion() {
        JavaVersion javaVersion = JavaVersion.current();
        if (!javaVersion.isJava6Compatible()) {
            throw UnsupportedJavaRuntimeException.usingUnsupportedVersion("Gradle Tooling API", JavaVersion.VERSION_1_6);
        }
        if (javaVersion == JavaVersion.VERSION_1_6) {
            DeprecationLogger.nagUserWith("Support for using the Gradle Tooling API with Java 6 is deprecated and will be removed in Gradle 3.0");
        }
    }
    ...
}

Thank you Denis,

we are already working on a fix for this, which will allow you to run on Java 6 again, while still keeping the Gradle 3.0 enhancements. We will release that as Buildship 1.0.19 very soon.

Cheers,
Stefan

Hi everyone! We’ve implemented the fix which lets you use Buildship on Java 6. Note that if you want to use Gradle 3.x, you will need Java 7 regardless.

We are planning to release the changes early next week. If you want to give it a go before, you can try the latest snapshots. Here are the snapshot update sites for Eclipse 3.6, 3.7, 4.2, 4.3, 4.4, 4.5 and 4.6.

We appreciate any feedback!

Hey Donat,

I tried the new snapshot release and it is working as expected although I am running into install issues (I had to manually install the newest 2.14 gradle tooling api). I have tried this on a couple different computers and am getting the same result. If I install the release version of 1.0.18, it installs 3.0 gradle tooling api. If I uninstall that version, it leaves the 3.0 gradle tooling api within the plugins folder. Now, if I install another version of buildship (that uses 2.14), it will not install 2.14 and use the existing 3.0 version (obviously resulting in the Java 7 error). I have also tried uninstalling buildship, manually removing 3.0 from the plugins folder and removing the 3.0 entry from the artifacts.xml file. If I install the snapshot version, it still installs 3.0.

I think what I need is a process to manually remove any traces of buildship from my computer. I must be missing a file reference somewhere, since it keeps trying to reinstall the 3.0 gradle tooling api. Any suggestions would be welcome…

Also, just curious. Are you planning to fix the release 1.0.18 version. If not I will just make a note in our developer documentation to skip this version.

Thanks!

Hi Denis,

there is no way of changing a released version. We will do a 1.0.19
release. We will look into the downgrading issue you described since that
will affect other Java 6 users who upgraded to 1.0.18.

Cheers,
Stefan

Hi Ankita,

I just want to let you know that we’ve released Buildship 1.0.19, which fixes the Java 6 incompatibility issue. You’ll find the announcement here: Buildship 1.0.19 is now available

Hi Denis,

Thank you for the feedback! With your help we were able to fix the 1.0.18 -> 1.0.19 update use case.
Cheers,

DonĂĄt