The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
+1
This is fine with me. If there are no objections, I can push the fix from webrev.01.
05-09-2018
Can we bump this? This issue has reached GitHub too: https://github.com/javafxports/openjdk-jfx/issues/187
05-09-2018
I didn't see any pivotal response about the Gradle files so I removed them and added Tom's suggestion above.
http://cr.openjdk.java.net/~nlisker/8209015/webrev.01/
27-08-2018
If you make:
* graphics/build/hlsl/Prism
* graphics/build/hlsl/Decora
"ignore optional compile problems" in the .classpath - it looks good. The reason to make them optional is that they only exist on windows.
I can not comment on the gradle stuff as I'm a die hard gradle denier ;-)
17-08-2018
The Buildship files are a convenience for those who want to the ability to run the Gradle commands from the IDE directly. If a user sets it up by himself, it will override all of the project settings (classpath files etc.), which will then need to be reapplied.
1. I'm not sure, my repo says it's based against http://hg.openjdk.java.net/openjfx/jfx-dev/rt.
2. It's the encoding for the source files. It solves the compilation error Tom mentioned in the first comment. I never encountered these problems myself because I use UTF-8 by default.
16-08-2018
I'm not sure what I think about the idea of checking in Buildship-specific .settings files, but as I am not a user of Eclipse, I'll defer to those who are. I would like to hear from [~tschindl] Tom Schindl as well as other Eclipse users as to whether this is an acceptable approach.
Two questions / comments on the Webrev:
1. The webrev is based against 11-dev, but should go into jfx-dev (unless you intend to request that this IDE-only change to go into the FX 11 repo).
2. You mentioned that you set 'UTF-8 encoding' for all projects. What, exactly, does this do? Presuming that it just means that if extended characters are used, the files will be written as UTF-8, then it seems fine.
Regarding the two qualified exports you asked about, I just checked and they are no longer used. They were removed as part of the refactoring of the javafx.swing module to use the new jdk.unsupported.desktop API (JDK-8195811), but the qualified exports were not removed from build.gradle or dependencies/java.desktop/module-info.java.extra. Once we bump the minimum JDK to 11 (some time after JDK 11 is released) we can remove the "oldimpl" along with all of the qualified exports.
15-08-2018
http://cr.openjdk.java.net/~nlisker/8209015/webrev.00/
Changes include:
* Setting UNIX line endings and UTF-8 encoding for all projects.
* Correcting modular dependencies in .classpath files.
* Adding the Gradle project nature all projects via the parent 'rt' project so that with Buildship the Gradle tasks can be executed from the IDE.
* Adding 'tests' and 'systemTests' projects. The latter cannot add more than 1 modular source because Eclipse does not support more than 1 module per project, so none were added.
With these changes all modules and tests compile save the note about systemTests and the unrelated javafx.controls error.
Please verify that unit testing works.
15-08-2018
Kevin, I'm comparing with build.gradle and for the swing module `qualExportsSwing` contains:
"--add-exports=java.desktop/sun.awt.image=javafx.swing",
"--add-exports=java.desktop/sun.java2d=javafx.swing",
which I don't see where they are used.
15-08-2018
Yes for UNIX line endings. Thanks.
10-08-2018
> do we have preferred line break settings as well?
Yes, Unix. I'll set that one up as well, thanks.
> swing fails with an NPE
So it's not just me. I'll try to get a reproduceable example.
If you find what's wrong with swing or fxml tell me.
10-08-2018
Ad Kevin: do we have preferred line break settings as well?
Ad Nir:
ad fxml-module: ok I'll try
ad source-folders: i can only tell you that those folders need to be there to launch local applications. The list i gave you was what is needed for windows (on OS-X and most likely linux) graphics/build/hlsl/Prism & graphics/build/hlsl/Decora are not needed - I need to test if Decora ones are needed
ad other questions:
* no swing fails with an NPE
* yes junit tests run (i only ran base & controls) - for controls you need to add the resources-folder otherwise modena.css is not found
10-08-2018
> web-module: JavaScriptBrigeTest: The reason is character encoding, we should force that to UTF-8 on a project base
I have my Eclipse default use UTF-8 so the project inherited it, but it's a good point. I changed the project-specific encoding and it's saved under a .settings folder for each project.
> fxml-module: various strange build errors
Yeah, I get these sometimes. You need to clean and rebuild the project and its dependencies. I couldn't reproduce a small example to send the Eclipse devs.
> it looks like the following source-folder mappings are missing:
What are you comparing too? Graphics contains a lot of native source folders, which should be added as source for the project?
Additional questions:
* Does Swing compile for you? It doesn't for me.
* Can you run the unit tests from Eclipse with this configuration?
10-08-2018
it looks like the following source-folder mappings are missing:
* controls/src/main/resources
* graphics/build/gensrc/jsl-prism
* graphics/build/gensrc/jsl-decora
* graphics/build/hlsl/Prism
* graphics/build/hlsl/Decora
10-08-2018
FWIW, build.gradle compiles all modules with '-encoding UTF-8'.
10-08-2018
With your changes I have 3 compile problems on Windows:
* web-module: JavaScriptBrigeTest: The reason is character encoding, we should force that to UTF-8 on a project base
* controls-module: Dialog (the one we already know)
* fxml-module: various strange build errors