Buildship 1.0.21 is now available

Help/Discuss Buildship
1

Today we have released Buildship 1.0.21. The highlight of the release is the complete Eclipse Web Tools (WTP) support. In addition, we made the default behavior of run configurations more intuitive. Last but not least, this release fixes a few issues reported by the community via the Gradle Forum or via Eclipse’s Automated Error Reporting feature.

Eclipse WTP support

This feature takes the configuration from the eclipse-wtp plugin and applies it on the workspace project. The example below demonstrates a possible configuration and the files generated upon synchronization. Note, that this new feature is only enabled if the Eclipse WTP tooling is present in Eclipse.

Example build script

import org.gradle.plugins.ide.eclipse.model.WbProperty
import org.gradle.plugins.ide.eclipse.model.Facet
import org.gradle.plugins.ide.eclipse.model.Facet.FacetType

apply plugin: 'war'
apply plugin: 'eclipse-wtp'

eclipse {
    wtp {
        component {
            contextPath = 'context-path'
            deployName = 'my-app'
            sourceDirs += file('extra-source-dir')
            resource sourcePath: 'extra/resource', deployPath: 'deployment/resource'
            property name: 'propertyName', value: 'propertyValue'
            file {
                whenMerged {
                    wbModuleEntries.removeAll { it instanceof WbProperty && it.name.contains('propertyName') }
                    wbModuleEntries += new WbProperty('propertyName', 'updatedPropertyValue')
                }
            }
        }
        
        facet {
            facet name: 'jst.web', version: '2.5'
            file {
                whenMerged { w ->
                    facets.removeAll { it.name == 'jst.java' && it.type == FacetType.installed }
                    facets += new Facet(FacetType.installed, 'jst.java', '1.9')
                }
            }
        }
    }
}

Generated files

[details=org.eclipse.wst.common.component] <?xml version="1.0" encoding="UTF-8"?>








[/details]

[details=org.eclipse.wst.common.project.facet.core.xml] <?xml version="1.0" encoding="UTF-8"?>






[/details]

Automatic Gradle version selection for task execution

We introduced the Automatic Gradle distribution option in the run configuration. This ensures that the task execution uses the value specified in the corresponding project configuration, even when that value changes due to a reimport.

run_conf_automatic_distro.png1918×974 165 KB

Installation

Buildship 1.0.21 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
3

Could you please elaborate more on what “automatic” means in the Gradle Distribution tab of the Gradle Task launcher? It sounds a bit obscure to me.
You say that this will use the Gradle version that was set when the project was imported, but a re-import does not change that version. If I understand it correctly, the very first project import seems to become some special import process (on which, though, I’m not sure I have any control, after it has been completed…). Also, if this is the case, I would expect the option to be called “use the Gradle distribution used when first importing the project into the workspace” or simply the last option (“Specific Gradle version”, with the version automatically set).

I also wonder what is the actual use case for this… maybe I don’t have understood this new feature at all…

4

Hi Mauro,

If the Automatic option is used then the task execution will always use the same Gradle distribution as the project was imported with.

It was necessary to introduce this new option because of the way how Buildship uses run configurations. When you execute a task from the tasks view, Buildship checks if a run configuration exists with the same project and the same tasks. If no such run configuration is found then it creates a new one, otherwise it reuses the existing one to initiate task execution.

This is useful if you want to execute the same tasks and want to provide - for instance - additional arguments to the task execution. On the other hand, if you reimport the projects with a different Gradle distribution, then the existing run configurations used the settings from old import. Using the Automatic Gradle distribution option as the default in the run configurations eliminates this problem.

For the naming, I agree it could be phrased a bit better, although it should be a concise one. We are open for suggestions :slight_smile:

5

Hi Donat,
so you say: “if you reimport the projects with a different Gradle distribution, then the existing run configurations used the settings from old import. Using the Automatic Gradle distribution option as the default in the run configurations eliminates this problem.”. This sounds more reasonable to me, but seems to be in contrast with what you say in the post above, where you write: "This ensures that the same Gradle version is used for the task execution as the project was imported with, even if that value changes (e.g. when a project is re-imported with different settings). ", which suggests that the Gradle version that will be used to run the task will always be the same even if you re-import the project with different settings. At least I understood it in that way when I read these release notes.

Thank you,
Mauro

P.S.: anyway, I still think that “Automatic” alone is a bit cryptic. It could say “The one used at import time”, or something like that. In any case, it would be extremely useful if beside the “Automatic” radio button the UI showed what Gradle distribution this “Automatic” setting will actually choose if you clicked “Run” at that moment…

6

The automatic option uses what is currently configured on the corresponding project.

In earlier Buildship versions, the launch configurations used the Gradle verison that was set on the first import of a project, but were not updated later. This confused users, because they changed the Gradle version of the project, but the tasks still used the old one. This has been fixed by the new default automatic.

7

I have an unexpected behaviour with the new WTP support.
I have a Gradle ‘war’ project manually configured in Eclipse as a Dynamic Web Project.
Following your advises, after updating to Buildship 1.0.21 (using Gradle wrapper 3.1, by the way), I changed my project build script to add the “apply plugin: ‘eclipse-wtp’” line. I didn’t change anything else and refreshed the Gradle project. What I see is that Buildship is duplicating many entries in org.eclipse.wst.common.component file. Here are the contents of this file before this change:

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
  <wb-module deploy-name="shop-backend">
    <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/resources"/>
    <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/java"/>
    <wb-resource deploy-path="/" source-path="/src/main/webapp"/>
    <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
    <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/groovy"/>
    <property name="java-output-path" value="/shop-backend/bin"/>
    <property name="context-root" value="SHOP-BACKEND"/>
</wb-module>

And these are the file contents after the change, so after refreshing the Gradle project:

<?xml version="1.0" encoding="UTF-8"?>
<project-modules id="moduleCoreId" project-version="1.5.0">
    <wb-module deploy-name="shop-backend">
        <property name="context-root" value="shop-backend"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/resources"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/java"/>
        <wb-resource deploy-path="/" source-path="/src/main/webapp"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/groovy"/>
        <property name="java-output-path" value="/shop-backend/bin"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="src/main/resources"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="src/main/java"/>
        <wb-resource deploy-path="/WEB-INF/classes" source-path="src/main/groovy"/>
        <wb-resource deploy-path="/" source-path="src/main/webapp"/>
        <dependent-module deploy-path="/WEB-INF/lib" handle="module:/resource/shop-commons/shop-commons">
          <dependency-type>uses</dependency-type>
        </dependent-module>
    </wb-module>
</project-modules>

What I see is that:

  • the context-root row has been replaced; this is fine, if I want the old value I can tweak my build script (by default it seems to use the project name)
  • the test source folders seem not to be deployed: this is fine, but the corresponding line is not removed (I guess they won’t be deployed because I don’t see the corresponding duplicated line below, see next point)
  • the main source folders have duplicate lines: src/main/java, src/main/resources, src/main/groovy: I would have expected Buildship to do nothing here, since those liens were already present in my file (unless I’m blind and I’m missing something…)
  • also the web content folder line is duplicated (src/main/webapp)
  • the dependency on shop-commons project, which this war project depends on (and which was manually configured as a WTP Utility Project) was implicitly deployed before the change by virtue of the fact that the .classpath file of this project contains the attribute with name=“org.eclipse.jst.component.dependency” and value="/WEB-INF/lib" for the classpath entry with path=“org.eclipse.buildship.core.gradleclasspathcontainer”; after this change, I see that this dependency project is also mentioned in the .component file; I’ve not enough knowledge to determine whether this is correct and/or necessary (and not redundant); can you shred some light on this?

Another question I have in mind is this: do I need to add “apply plugin:‘eclipse-wtp’” to the shop-commons dependency project, too? I remember this was an open point… Right now, I’m not specifying this.

I also find that the org.eclipse.wst.common.project.facet.core.xml file has some oddities… These are the contents before the change:

<?xml version="1.0" encoding="UTF-8"?>
<faceted-project>
  <installed facet="wst.jsdt.web" version="1.0"/>
  <installed facet="jst.web" version="2.5"/>
  <installed facet="jst.jsf" version="2.2"/>
  <installed facet="java" version="1.7"/>
</faceted-project>

And these are the contents after the change:

<?xml version="1.0" encoding="UTF-8"?>
<faceted-project>
    <installed facet="wst.jsdt.web" version="1.0"/>
    <installed facet="jst.web" version="2.5"/>
    <installed facet="jst.jsf" version="2.2"/>
    <installed facet="java" version="1.7"/>
    <fixed facet="jst.java"/>
    <fixed facet="jst.web"/>
    <installed facet="jst.web" version="2.4"/>
    <installed facet="jst.java" version="1.7"/>
</faceted-project>

What I see here is that:

  • the “installed” element with facet=“jst.web” is duplicated; also, I see that Buildship has automatically selected version 2.4 for this facet… but since the web.xml file in my webapp uses the Servlet 2.5 namespace, I would have expected it to select the 2.5 version (whose corresponding line is still present in the file, by the way, )
  • the “installed” element with facet=“jst.java” has been added: I don’t know what it is for, if I use the WTP UI to change the projects facets and I select the Java facet 1.7, WTP adds the facet=“java” row, not the facet=“jst.java” one… but maybe I don’t know enough and Buildship is doing the right thing… can you elaborate on this?
  • two “fixed” elements have been added… I really don’t know what they are for…

Thanks in advance for any feedback.

Mauro

8

Regarding this point:

After some testings it seems like with Buildship 1.0.21 the presence of “org.eclipse.jst.component.dependency” attribute in .classpath for the Gradle container does not cause the dependency projects to be deployed along with libraries any more. In fact, after updating to Buildship 1.0.21, if I remove and re-add my shop-backend web application from/to my WTP Tomcat Server instance, I can’t see the shop-commons dependency deployed with it any more. This would justify the need to mention that project in the .component file now. Can you confirm this?

9

Another issue I see, which is also evident by the excerpt provided by Donat, is that even if you declare a jst.web facet with version, say, “2.5”, the jst.web facet version 2.4 is always added as “installed” to the org.eclipse.wst.common.project.facet.core.xml as well.

Unless otherwise advised I must downgrade to Buildship 1.0.20 by now, otherwise my component and facet files get messed up on every refresh…

10

Should I open some bug reports for the above?

Thanks in advance,
Mauro

11

What happens behind the scenes is that Buildship invokes the eclipseWtp tasks on web projects. So, if you see a problem with Buildship’s behaviour in terms of WTP integration, you should verify what files are generated if you invoke the same task from the command line.

If you find something that doesn’t seem right, please open a bug report. In fact, we’ve just started using GitHub Issues, you can make use of it.

12

Is Eclipse Bugzilla suitable for this as well? I usually use it for bugs against Eclipse projects.

What do you think about my previous posts? With some feedback I may open some more defined bug reports.

Thanks in advance,
Mauro

13

Since Buildship only invokes the eclipseWtp task on web projects, it’s much more likely that the bugs will be in the eclipse-wtp Gradle plugin. If that’s the case, I strongly suggest to use GitHub Issues. It’s super easy, especially because there’s a template in place when you try to create a new issue.

Your findings make sense on the first look, but we are no WTP experts. If you break down the problems into small chunks - possibly with sample projects - then we’ll be able to analyze them one-by-one.

14

Hi Donat,
I preferred to open some bug reports against Buildship in the Eclipse Bugzilla for now. I opened these ones:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=506627
https://bugs.eclipse.org/bugs/show_bug.cgi?id=506629
https://bugs.eclipse.org/bugs/show_bug.cgi?id=506632