Bug on latest Buildship version

buildship

(Ivan RF) #1

On Buildship 1.0.9.v20160211-1429, default project settings for Java Compiler (JDK) are overwritten.

In gradle.prefs I had a null value for connection_java_home and the project settings were being used. This worked fine until the latest Buildship update. Now, no matter what I set in the project, it gets overwritten.

I wrote about this here: Stop Eclipse updates on classpath and settings.


(Stefan Oehme) #2

This is a known issue and will be fixed with Buildship 1.0.10

See discussion at the end of https://bugs.eclipse.org/bugs/show_bug.cgi?id=472996


(Donát Csikós) #3

This issue has been fixed in Buildship and will be released next week. If you want to evaluate you can install the latest milestone build from the following update site: http://download.eclipse.org/buildship/updates/e45/milestones/1.0/1.0.10.v20160309-1150-m
We appreciate any feedback.


(Ivan RF) #4

I’m testing version 1.0.10. Now, when I refresh the project:

  • file gradle.prefs is removed
  • in org.eclipse.buildship.core.prefs this lines were added:

build.commands=org.eclipse.jdt.core.javabuilder connection.arguments= connection.gradle.distribution=GRADLE_DISTRIBUTION(WRAPPER) connection.gradle.user.home=null connection.java.home=null connection.jvm.arguments= connection.project.dir= natures=org.eclipse.jdt.core.javanature project.path=\:

  • in .classpath this line is modified (StandardVMType added):

<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6"/>

This last change introduced many errors: “Access restriction: … is not API (restriction on required library … rt.jar)”. I solved this by selecting the JDK, instead of using the “Execution environment”.

<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jdk1.6.0_43"/>

Is this the expected behaviour?

Update: when I refresh the project, this last change is undone. That is, Gradle changes jdk1.6.0_43 back to JavaSE-1.6.


(Ivan RF) #5

@donat @st_oehme
even using connection.java.home=C:\\Program Files\\Java\\jdk1.6.0_43 on org.eclipse.buildship.core.prefs sets the “Execution environment” JavaSE-1.6.
So, there is no way of setting an alternate JRE/JDK.

Update: using gradle.properties with
org.gradle.java.home=C:\\Program Files\\Java\\jdk1.6.0_43
is not working either.


(Stefan Oehme) #6

We are currently making use of execution environments only. If you want your special VM to be used, set it as the default VM for that execution environment.

There is also an enhancement request that will allow selecting a JVM by name. This has somewhat lower priority though, as it is not very portable. It would mean that every developer on the team would have to set up Eclipse with precisely the right VM names.

Also there is no need to tinker with the java.home setting. It was never meant to specify the JDK to use for the Eclipse project. It’s just the JDK that the Gradle build itself will run on.


(Ivan RF) #7

Changing the default VM for the Execution environment does not solve the “Access restriction” error messages from eclipse. So, using that is not exactly the same as setting the Alternate JRE.

Anyway, I changed the few references that I had to sun.* to solve that and I’m using what Gradle sets (Execution environment > JavaSE-1.6).


(Manfred Schenk) #8

Is there any reason to only support execution environments? By doing so, using gradle for creating eclipse projects using JavaFX is impossible since the execution enviroment sets some access rules prohibiting the use of the JavaFX bundled in the ext folder of the Java 8 installation. Manually switching in eclipse from execution enviroment to workspace default JRE solves this issue but it’s there again after regenerating the eclipse project from gradle.


(Donát Csikós) #9

The reason is that exposing the required information via the Tooling API takes a significant amount of time, and so far we haven’t seen a reason to prioritise this feature. The select a JVM by name feature would solve your problems, is that correct?


(Manfred Schenk) #10

Yes, I think a selection by name would be useful in my case.
(see also Setting execution environments instead of JRE prohibits use of JavaFX bundled with Java8 where I described the problem as an own topic).


(nick heniser) #11

I am having issues with the “Access restriction” error messages in eclipse as well and I can’t seem to fix them when using buildship in eclipse. Could you share how you got around this with buildship/gradle?


(Stefan Oehme) #12

With Buildship 1.0.18 and Gradle 3.0 you can set the eclipse.jdt.javaRuntimeName to a JVM whose access restrictions are more open.


(nick heniser) #13

Sorry that I am not reading between the lines here… but i still don’t understand?

What jvm would be less restrictive? I am using the latest oracle 1.8 jvm. (jre 1.8 101). I have updated to both gradle 3.0 and Buildship 1.0.18.

I have set my subprojects to use:

eclipse {
    jdt {
        javaRuntimeName = "JavaSE-1.8"
    }
}
	
sourceCompatibility = 1.8

(Stefan Oehme) #14

What you pasted is the default, sourceCompatibility = 1.8 would be enough in that case.

The problem is that in Eclipse JREs are configured to forbid access to Sun-internal APIs by default. “JavaSE-1.8” is a predefined execution environment that you cannot change in Eclipse. Instead, you’ll have to create your own JRE and give it a name. Then you can use that name in javaRuntimeName.


(nick heniser) #15

Ok, i was just hoping for a non-manual solution, but this works OK.


(Stefan Oehme) #16

You can also shut off those warnings in Eclipse’s compiler settings if you want. But they are generally valid. If you access those internal APIs, your code is not guaranteed to run on all JREs.


(nick heniser) #17

Understood, found a pretty good explanation here as well: http://stackoverflow.com/questions/22812488/using-javafx-in-jre-8

We are using javafx for an internal testing tool gui, so we are ok with it not running on all JVMs.

With the gradle ‘eclipse’ plugin we got around this with this by doing something like below, but this breaks buildship by removing the jvm somehow…

eclipse { 
    classpath {
        file {
            whenMerged { classpath ->
                classpath.entries.findAll{entry -> entry.kind == 'con'}.each{
                    def componentName = it.path
                    withXml {
                        def node = it.asNode()
                        node.appendNode('classpathentry', [kind: 'con', path: componentName]).appendNode('accessrules').appendNode('accessrule', [kind: 'accessible', pattern: 'javafx/**'])
                    }
                }
                classpath.entries -= classpath.entries.findAll{entry -> entry.kind == 'con' }
            }
        }
    }
}

(Stefan Oehme) #18

Please have a look at the Buildship 1.0.18 release notes. You can do this customization much more straightforward, without XML mangling and in a way that Buildship will understand :slight_smile:


(nick heniser) #19

Exactly what i was looking for!! Here is the slightly modified snippet from the release notes as it applies to javafx.
Really great documentation… thanks for such a great product!!:heart_eyes:

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('0', 'javafx/**'))
            }
        }
    }
}