Gradle improvements #44
Conversation
If we are going to use gradle to build WorldWind, we need to drop the NetBeans project folder to prevent NetBeans from thinking this is still a free-form project. Once removed, and after the Gradle plugin has been installed in NetBeans, the project will load as a Gradle project.
The wrapper.gradle file determines what version of the gradle-wrapper we want to use to build the project with. We get the wrapper by running: `gradle -b wrapper.gradle wrapper` After which we can build the project with: `./gradlew clean build`
Made some significant fixes to the build.gradle file: - To allow this project to open in NetBeans the archiveBaseName variable in the extensionsJar-task had to be changed to baseName. - When you actually try to run one of the example classes in NetBeans the resources are not picked up. So, to fix this, the sourceSets' main resource clause had to be changed to include the 'src' directory but excluding all java source files. We also modified the sourceSets' main java clause so that we only include *.java files as sources (else resources show up in the source-directory in NetBeans). - In light of the abovementioned change, the jar and extensionsJar tasks were changed. For the jar task, we no longer need to manually include the resources as this is now pulled in via the sourceSets. We just exclude the 'gov/nasa/worldwindx' folder. A similar change was done for the extensionsJar task where we now only have to exclude folders. In this case the 'com', 'config', 'images' and 'gov/nasa/worldwind' folders to be exact. - Made a small fix to the compileJava task. To get a debug-build we no longer have to specify '-PdebugBuild=true' as an argument for gradle when we build. If we want to debug the project in NetBeans, the default build should always be a debug-build. Thus we now always build a debug-build. However, to now get a release build the compileJava task was changed so that we set the options.debug property to false when a -PreleaseBuild property is specified. - Lastly, changed the group to be 'earth.worldwind' as discussed in #36.
- Modified the .gitignore file by adding the .nb-gradle folder as a new entry. This is the folder that the NetBeans Gradle plugin produce which we can safely ignore from commits. The gradle folder, the gradlew and gradlew.bat files were also added as these are produced by the gradle-wrapper task and we do not need to keep track of them in version-control. - The bin folder was removed as this is not produced as an output of one of the build-tools that we currently use. - Removed the nbproject/private entry as we no longer load this up as a traditional NetBeans free-form project.
Modified the .travis.yml file to allow for Gradle to build the project: - The first change was adding a call to instantiate the gradle-wrapper in the before_install section. - The install phase now calls the clean-task via the gradle-wrapper. - The script phase was also changed to call the build and javadoc tasks via the gradle-wrapper. - Gradle writes the javadoc to a 'build/docs' folder instead of the 'build/doc' folder that ant used. This was changed in the deploy section to reflect the gradle folder structure.
Modified the travis.yml file to make use of Java 8 when setting up the Gradle wrapper. If we do not do this, the build will fail as the system version of Gradle on Travis is not compatible with Java 11.
Modified the travis.yml file so that Gradle artifacts are cached between the different builds.
Some remaining changes to the javadocs to fix the OracleJDK11 build.
|
@wcmatthysen It looks like the build checks include Oracle and Open JDK 8 and 11. Just wondering why we wouldn't also include Oracle and Open JDK 12 since its general release tool place earlier this year. I don't know that there's a significant amount of change between 11 and 12, but it seems like it might be reasonable to include the latest Java release. Thoughts? EDIT |
|
@robmilton, I agree. We can probably add it now. In the past we tested against OpenJDK (or OracleJDK) 12 by getting it via |
|
@robmilton, the builds against the different JDKs are as a result of the Travis-config that was inherited from the upstream repository and updated by @emxsys. The travis.yml file indicates to GitHub that we want to build and test the changes in each pull-request on Travis. It is not just specific to this pull-request. Each and every pull-request kicks off a Travis build that compiles WorldWind on the different JDKs and runs the unit tests on all of them as well. |
|
@wcmatthysen, thanks for the explanation. I'm learning how all these pieces fit together. I'm hoping to get to a point soon to be able to contribute as well. I'd love to at least support efforts to get WorldWindJava working on Java 9+ (preferably the keeping it up to date with the latest Java release). |
|
Good luck world crew! Making it all work in smooth wonder with the latest!!! |
We've been using WorldWind with Java 11 for about two months now. There weren't any major problems. Probably the most work that should be down is updating routines that use deprecated methods. For the rest of our application, figuring out how to fit JAXB in took the most effort. But that library isn't used by WorldWind. We're using AdoptOpenJDK 11.03. |
Well, to use the Oracle Java builds, someone might need to come with the USD $40 for the license fee. ;-) |
Added openjdk12 as one of the JDKs that Travis should build against. This comes after the release of Java 12 in March. The openjdk-ea entry now points to Java 13 early-access builds.
|
@emxsys, @gbburkhardt, I think we can merge this. The first Travis-build failed because I erroneously pushed the |
|
@gbburkhardt, I'm excited to hear you've been running WWJ with Java 11 for a while! I'll definitely be interested in pursuing this topic with you in the near future. In addition to the changes to WW I'd be interested to hear how you're handling the runtime since it seems the JRE is no longer available as of Java 11. If you have a distributed application are you using JLink to package the necessary runtime components in your application? Or are you relying on users installing the JDK? Just interested to hear what you're doing. The other reason for this post is to ask about the gradle build. I just built WWJ-CE for the first time since the NetBeans project folder was removed and the project moved to a gradle build. When I run my application I'm getting errors stating: I had this EXACT same behavior a number of weeks back when I tried compiling WW with Java 9. A quick search on Google resulted in many hits explaining Java 9 made a change to java.nio.ByteBuffer.flip() which now returns a ByteBuffer where it used to return a Buffer. I see that build.gradle is setting sourceCompatibility and targetCompatibility to 1.8. But I don't see where the JDK is specified. How can I guarantee with the gradle build that I'm building using JDK 8 and not JDK 9+? I'm hoping that if I build using JDK 8 it will address this problem... |
|
This issue was that the platform being used by the gradle build was JDK 11. I hadn't noticed the "Platform for build scripts" section in "Gradle project". Once I unchecked the "Inherit" checkbox I was able to choose JDK 8 as the build platform. And after I built using JDK 8 the errors went away. |
|
|
Unfortunately, compiling without errors is not enough. I notice that the WorldWindow and InstallImagery example applications don't completely display correctly with Java 11. There's some work needed there. |
|
@gbburkhardt, thanks for sharing that. I am very interested in getting WWJ to a point where it is compatible with the latest Java release. However, I work for a very small company and have an very large backlog of work. So I'm trying to figure out how I can best support WWJ improvements while getting things done for work. I really appreciate all that you guys have been doing to move WWJ forward. |
Description of the Change
Made some improvements to the Gradle build script to allow the project to be opened in NetBeans via the Gradle plugin. We can now build the project in NetBeans, run the unit tests, debug it as well as run some of the examples all from NetBeans. The Travis config was also changed to build the project with Gradle.
Why Should This Be In Core?
We want to eventually migrate over to using Gradle as our primary way to build the project. These are some of the necessary changes that we need to make to get there.
Benefits
Easy setup and build of the project in NetBeans (and potentially other IDEs).
Potential Drawbacks
None at this point.
Applicable Issues
Issue #11