On Wed, 26 Oct 2022 16:48:34 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
> One difference I see is that the official process to import the project, > according to > https://wiki.openjdk.org/display/OpenJFX/Using+an+IDE#UsinganIDE-ConfigureEclipsetousethelatestJDK > , is to use `Import as Gradle Project` rather than import as existing > project. After you clone the repository for the first time, you have to let Gradle build all sorts of artifacts, and you need to do it once. When you import as a Gradle project, it does it for you. After that you can reimport whichever way you like. You can also import for the first time as Java projects, but Eclipse will fail to build them because you still need to run the Gradle task externally. When we finish updating the Eclipse files here, I intend to rewrite that section, noting the differences between importing as Gradle and Java projects, and detailing the project structures. > regarding the project name 'rt' and the directory name 'jfx' created by git > clone - there is a historical reason why the directory name should in fact be > 'rt' and not 'jfx', @kevinrushforth could you please explain? > I know the likelihood of any changes to the git project configuration is > zero, but perhaps we need to have some explanation of the discrepancy in the > name. The project name change in Eclipse is rather superficial (as I suspected, and confirmed today) - it only changes the display names in various places, but if that name and the folder name are not the same, there's some duplication confusion attached to it where there will be 2 projects displayed. Even then, one will function correctly and the other will be a stub, so no real harm done. Even if the `rt` name is used inside the Gradle build file, it doesn't interact with the Eclipse files. Apparently, when Buildship imports fresh Gradle projects, it derives the name from the folder name (this is what I tested, I didn't check the specs, if there are any on this). So, changing the name should be safe. The reason for the current discrepancy, I gather, is that the current project file in the repo was checked in when the project was on Mercurial with a different folder name, and now that the folder name has changed in GitHub we get this "conflict". > (also, Nir, you have some .classpath modified in your screenshot) That's the /manual swt project that requires an external jar as noted in one of the comments above. > 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?). Importing through Gradle only imports projects that are configured in the root Gradle script (the modules, `systemTests`, and `apps`). To have the other projects, like tests/manual and /performance, you will need to import nested projects as Java projects. Maybe some of them should be hooked up to the root Gradle script to automate this for first-time users, but that's another issue for another time. > I think I see errors appear in step 2, so something is definitely wrong. If they are in the modules, you will need to figure out the difference between before and after this patch, because there shouldn't be any. > Looks like steps 3 and 4 are new steps. is it possible not to add these extra > steps, or have eclipse files configured such that the extra steps are not > necessary, as the case is with the current master branch? They are not needed if you don't need the non-Gradle projects. The current master branch also get errors when you import as Gradle, you need to revert its changes anyway. Also, step 4 might not be needed once John updates the PR to remove the project files from those. ------------- PR: https://git.openjdk.org/jfx/pull/930
