search

groovyfx-project / groovyfx

A library for writing JavaFX 8 applications in the Groovy language.
http://groovyfx.org
Apache License 2.0
199 stars 50 forks source link

JAVAFX_HOME required incorrectly in version8 branch #31

Open swalton00 opened 8 years ago

swalton00 commented 8 years ago

If jfxrt.jar is not found int classpath, a message is issued requesting that JAVAFX_HOME be set: Please set the environment variable JAVAFX_HOME to the directory that contains rt/lib/jfxrt.jar of JavaFX version 8.0.*. That jar is found in jre/lib/ext for Java8 distributions.

On Windows, setting JAVAFX_HOME to JAVAFX_HOME=/Java/java8/jre/lib/ext appears to be the only way to get it to work (C:\ at the front doesn't work, and the \'s in middle also seem to cause problems)

Also need to correct the docs page on how to build (there is no separate JAVAFX SDK to download anymore.).

swalton00 commented 8 years ago

I tried several variations and finally ended up creating a new directory containing "rt/lib/*" with all the files contained in the "java8/jre/lib/ext" folder and set JAVAFX_HOME to that folder. I was then able to build. Created a basic POM file and mvn install'd that to my local.

The jar wasn't built correctly, the path was "man/groovy/...." when it should have been "groovyfx/....." Manually correcting the path fixed the issue.

shnplr commented 8 years ago

I have a similar problem using cygwin inside windows - the jdk8 path resolved to '/cygdrive/c/Java/jdk1.8.0_72/jre/lib/ext/jfxrt.jar' which exists from a posix viewpoint (ls) however file.exists() is false - I'm guess its assuming 'C:\cygdrive\c\Java\jdk1.8.0_72\jre\lib\ext\jfxrt.jar' which doesn't exist. Current workaround is to add: project.ext.javafxJar = jfxrt8Jar.path

russel commented 8 years ago

JavaFX is only present in the Oracle JDK8 distribution. For those using OpenJDK 8 you have to have a pointer to the jfxrt.jar so JAVAFX_HOME is useful in that context. Fortunately jfxrt.jar comes as standard with OpenJDK 9.

I think we can probably simplify everything a lot if we say JDK7/JavaFX 2 is no longer supported as of now.

msgilligan commented 8 years ago

We should definitely simplify this -- and maybe add a note that lists extra step for OpenJDK.

(I've been focused on Mac OS in my beginning JavaFX efforts, so I know those steps are not required there, but haven't been doing builds on Win or Linux yet)

russel commented 8 years ago

My comment about OpenJDK9 is now false, since the move to modularization: there is now no jfxrt.jar in the JDK9 early access releases. Given this and the lack of a JDK* JavaFX jar outside the Oracle distribution, I am not sure how there is a current alternative to manual stealing of a jfxrt.jar from somewhere, use of JDK8 and the JAVAFX_HOME environment variable for people not using a native Oracle JDK8.

Summary: the current situation is not tenable.

msgilligan commented 8 years ago

I hate to open another can of worms, but shouldn't there be a JavaFX Gradle plugin that handles this?

russel commented 8 years ago

Can I suggest we make that a separate bug report. As it happens we already have a can of worms so opening more is not a problem. In fact, I think it would make things a lot easier to have a specialist Gradle plugin, how to convince someone to write one?

msgilligan commented 8 years ago

Sure, I'll open a new issue.

russel commented 8 years ago

The gradle.properties file in master appears to indicate the default target in JDK9. However by removing all the JavaFX version checks in build.gradle, it is clear that there are huge changes to JavaFX in JDK9 compared to JDK8 that means the current GroovyFX is in need of a severe amendment.

I wonder if we should create a JDK8 maintenance branch from the tag for the 8.0.0 release that @aalmiray made.

msgilligan commented 8 years ago

Actually, why not create a JDK9 development branch and leave the main branch as JDK8 for now? That's certainly what most users of the project will be looking for at this point in time -- and it seems to me there is plenty of work to do for JDK8.

(That's certainly what I personally am looking for and the environment in which I"m going to able to make some minor contributions, I hope.)

russel commented 8 years ago

I always go the other way (as it were), master is always the research/development branch and there are maintenance branches for release software.

I have put in a pull request to remove all the JavaFX version checking in build.gradle of master.

msgilligan commented 8 years ago

To me it depends upon what the next planned production release would be. I would think that would be something for JDK8. But I'm new here and will go with whatever you and other active committers decide.

(To be more specific: I'm imaging that the master would be for release 8.1.x or something like that and there would be a long-lived feature branch for JDK 9 that would get merged in when ready, but again it's obviously your call.)

I'm also assuming that when JDK9 is working there would be a release that supports JDK8 and JDK9, or do you imagine parallel releases one for JDK/FX8 and one for JDK/FX9?

russel commented 8 years ago

@msgilligan @aalmiray already created a version8 branch, I will move it forward one changeset and you should be able to go with that.