JavaFX Build "cannot find symbols"

[kebiro]

There is already a very similar issue which has been marked as resolved (this), but that one didn't work for me. It's also three years old and uses Maven whereas I'm building my project using Gradle.

This is the build failure, though I'm not sure if you can view it:
https://app.shippable.com/bitbucket/kebiro/gradle_shippable_test/runs/10/1/console

My YAML file looks like this:

language: java

jdk:
    # can have multiple versions if need be (e.g. below append "-openjdk8")
    - oraclejdk8

before_install:
    - apt-get update
    - apt-get install -y maven
 
before_script:
    - if [[ $SHIPPABLE_JDK_VERSION == "oraclejdk8" ]] ; then export JAVA_HOME="/usr/lib/jvm/java-8-oracle"; export PATH="$PATH:/usr/lib/jvm/java-8-oracle/bin"; export java_path="/usr/lib/jvm/java-8-oracle/jre/bin/java"; fi
    - update-alternatives --set java $java_path
    - java -version
 

script:
    - chmod +x ./gradlew
    - ./gradlew clean build
    
    
after_success:
    - mvn clean cobertura:cobertura
    - mvn test

As you can see, it's a poor attempt of trying the suggested solution from above. The one step I didn't/couldn't do was to set the build image to shippableimages/ubuntu1204_java

This is the Java version used by Shippable:

 setup_jdk
  shipctl jdk set oraclejdk8
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)

I'd appreciate any kind of help. Furthermore, I'd like to know why this isn't working in the first place? Building it in IntelliJ doesn't cause any problems.

[trriplejay]

Hi @kebiro, i think we can simplify your yml quite a bit. The issue you linked to shows our old yml syntax, and much of it is unnecessary now. I noticed that "gradle assemble" is being added to your yml as a default command. Do you actually want this? If I'm not mistaken, the ./gradlew clean build will internally run an assemble, so the first one might be redundant. I've left it out of this yml, but feel free to add it back if it's necessary. The source line replaces the before_script section from the old example. The "before_install" is not necessary as both maven and gradle are already installed. and the "after_success" shown there is just for running maven tests, so I've left that out entirely.

language: java
jdk:
  - oraclejdk8

build:
  ci:
    - source shipctl jdk set oraclejdk8
    - java -version
    - gradle --version
    - chmod +x ./gradlew
    - ./gradlew clean build

can you give this a try and let us know how it goes?

[kebiro]

Thank you very much for your response, it was quite helpful.

1. gradle --version didn't work. I changed it to gradle -v, which does work.
2. Now I get a different error below ./gradlew clean build: I put it on here so it should be easier to read.

This might be Java specific, I feel. I have no clue what's going on though.

[trriplejay]

hmm. let's try a couple more things:

1. try changing your runtime to "v6.8.4"
   • on your subscription dashboard, click the settings button (gears in the top right) and go to node pools.
   • click "edit" next to your default node pool
   • in the "runtime version" dropdown, select v6.8.4
2. once runtime version is updated, add the following command to your yml, before the gradle commands
   • sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

[kebiro]

Thank you, this has indeed worked. Could you leave it as open for another day, because I've only tried it on a dummy project thus far.

Furthermore, how did you arrive at that solution? I don't think I could have come up with that on my own.

Anyway, whether you close it or not, your help is much appreciated. Short, concise and accurate👍👍 .

[trriplejay]

sure, we can leave it open for now. let us know if you run into anything else.

After looking at your error, we googled around a bit, and eventually settled on this post: https://stackoverflow.com/questions/47921563/javax-net-ssl-sslexception-the-trustanchors-parameter-must-be-non-empty

Which seemed like it fit the symptom, and thought it would be worth a try. We found that the command failed on Shippable runtime versions > 6.8.4 possibly due to a known java path issue (that will be resolved in our next release), but found that the command ran successfully on v6.8.4. Since you didn't have any dependency on the latest shippable runtime we figured moving back would give the best chance of success. Glad to see it worked out!

[trriplejay]

closing this. @kebiro let us know if this issue comes up again.

[kebiro]

Hi,

it's fine, thank you. I haven't forgotten about this thread... it's just that I don't have control over the settings, a third party has to do that. They've had some troubles, and the holidays and all that in-between caused some delay as well.

Anyway, thank you for your help.

Edit: I just wanted to say that it works now. Again, thanks a lot.