RFR: 8221708 Update Eclipse project files
John Hendrikx
jhendrikx at openjdk.org
Sun Nov 6 00:24:30 UTC 2022
On Sat, 22 Oct 2022 07:49:12 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:
> See https://bugs.openjdk.org/browse/JDK-8221708
I took a look at the tests folder. There are several nested testapps in this folder. These give compile errors because they're not using the correct source root folder (they use `/src/testapp3/java` with a `module-info.java` nested in `mymod`). This is incorrect as module info needs to live in the root. Fixing the source folder to `src/testapp3/java/mymod` is not allowed in a single project as there will be multiple `module-info.java`'s at the same level.
The solution seems to be that each module-info needs to have its own Eclipse project as Eclipse project == module.
I've added the manual ones. I think not all of the manual code is correct. `DNDWebViewTest` has no `main` for example. The `swt` tests need eclipse SWT libraries that don't seem to be around.
It looks like this for me:
The error that is still visible is missing SWT libraries.
I do this with import eclipse projects, and letting it search for nesting projects. Unfortunately, it finds some project files in `bin` folders which are copied there by something I haven't discovered yet. You need to unselect those.
I've rebased this on master. For some reason I mistakenly based this on some old version of master.
I do notice the same kind of problems Andy experienced. Eclipse can give many errors when switching branches. Closing all projects and reopening them solved all the errors for me though.
I've just done the following:
1) Deleted all projects in Eclipse (without contents). Eclipse was empty after this.
2) Do a Gradle import, with all default settings. Now there are about two dozen errors all related to projects that can't be build.
3) Pressed refresh on EGit, and reverted all project files except the `tests/.project` which is not in the repository.
I now have exactly 2 errors, both related to the file `DoubleShortcutProcessingTest.java`. I suspect I missed something on the classpath for that one.
4) Also deleted the `tests/.project` and did a rebuild of all projects. No changes, still 2 errors.
Now, something is wrong I think. The test projects are not showing up as Eclipse projects. Nested projects seem to have been ignored (perhaps this is an option in Gradle import?). Package explorer only shows the standard 11 gradle projects. So:
5) I import nested Eclipse projects, carefully unselecting the top level project (jfx) and all the projects with `bin` in their name.
I now have all projects back in package explorer, and still only the same 2 errors.
6) I deleted the two errors from the problems view about `DoubleShortcutProcessingTest.java`, as it seems they were related to the main project `systemTests` instead of `systemTests-test`. Refreshing all projects, and they did not come back. Probably something that went wrong during the gradle import, and it was just a random unlucky file that Eclipse may have attempt to compile first.
Okay, so, I'm unsure why or how, but when Andy imports using the Gradle import wizard, a gradle build starts in the background. This doesn't happen on my system. The gradle build shouldn't be needed during the import.
What I'd like to know what the end game is were aiming for here. Is it the use of the Gradle import wizard, or is it the import of (nested) Eclipse projects?
For the latter, Eclipse will still see the projects as gradle projects as the project files will include the gradle nature.
Also for the latter, I think that's the only one we're going to be able to get it working perfectly without error every time.
What I'd like to see is the following:
1) Ensure we have a process that does NOT create any Eclipse project files -- they're in the repository already, they're correct, we don't want them overwritten. This may mean removing something from the build script (some kind of Eclipse helper plugin is there I suspect).
2) Prevent Eclipse project files being copied to `bin` folders. Something is doing this, and I'd like to tweak the build so this no longer happens as it causes duplicate projects to be found resulting in errors and confusion.
3) Use import as Eclipse projects, not the Gradle wizard; this is because the wizard creates the wrong files. The end situation is the same (after reverting all those files), and Gradle is still usable as the Gradle nature is present.
The process to set up JavaFX for Eclipse would then become:
1) Git clone repository
2) Do a full build
3) Open Eclipse, import Eclipse projects (do not use gradle import)
Thoughts?
I may be misunderstanding something fundamental about Gradle and Buildship. So the situation is this:
1. JavaFX provides correct project/classpath files in its repository for Eclipse
2. Buildship import creates project/classpath files based on `build.gradle` for situations where you don't have Eclipse project files; that's AFAIK what import does: analyze `build.gradle` and create suitable Eclipse project files
Why would you do 2 when you already have 1? It's impossible to make 2 deliver correct results due to how complicated the JFX project structure is, the many options Gradle offers and the limited ways this can be represented in Eclipse. In fact, we revert all those changes (literally all of them) to still end up in situation 1 -- it's literally as if 2 never happened (no other changes were made on the filesystem that could affect the Eclipse setup in any way).
Because the included project files contain the Gradle nature, all the other functionality of the Buildship plugin should still work as normal, including running a build.
So I may be missing something, but I see no need to run a Gradle import as it is an unnecessary, detrimental step that requires all changes it made to be reverted to go back to the situation you were already in before running it...
I haven't been able to reproduce the `bin` problem in any way after I manually deleted all of them. I suspect it was a local file on my end (probably a `.classpath` file in the top level folder `apps` or `test`) that was causing this.
A launch file example looks like this, and contains no local stuff (but I'm fine with excluding them):
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<launchConfiguration type="org.eclipse.jdt.launching.localJavaApplication">
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_PATHS">
<listEntry value="/ColorCube/src/colorcube/ColorCube.java"/>
</listAttribute>
<listAttribute key="org.eclipse.debug.core.MAPPED_RESOURCE_TYPES">
<listEntry value="1"/>
</listAttribute>
<booleanAttribute key="org.eclipse.jdt.launching.ATTR_ATTR_USE_ARGFILE" value="false"/>
<booleanAttribute key="org.eclipse.jdt.launching.ATTR_EXCLUDE_TEST_CODE" value="true"/>
<booleanAttribute key="org.eclipse.jdt.launching.ATTR_SHOW_CODEDETAILS_IN_EXCEPTION_MESSAGES" value="true"/>
<booleanAttribute key="org.eclipse.jdt.launching.ATTR_USE_CLASSPATH_ONLY_JAR" value="false"/>
<stringAttribute key="org.eclipse.jdt.launching.MAIN_TYPE" value="colorcube.ColorCube"/>
<stringAttribute key="org.eclipse.jdt.launching.MODULE_NAME" value="ColorCube"/>
<stringAttribute key="org.eclipse.jdt.launching.PROJECT_ATTR" value="ColorCube"/>
<stringAttribute key="org.eclipse.jdt.launching.VM_ARGUMENTS" value="-Djava.library.path="../../../modules/javafx.graphics/build/module-lib"
--add-modules=javafx.graphics"/>
</launchConfiguration>
I implemented option 2 from Nir Lisker's last comment
-------------
PR: https://git.openjdk.org/jfx/pull/930
More information about the openjfx-dev
mailing list