I’ve been trying this out since it has Gradle support built in, but I’m seeing a number of problems (master branch). Building with Linux, 11.0.2-open (OpenJDK), Gradle 4.10.2.
These are some of my observations so far:
NetBeans 11 “open” of the root project and all subprojects reports a number of problems out of the box. These could be NB Gradle support bugs, since that’s pretty new.
I’m able to do a successful* build from the command line (*it says it’s successful, I wouldn’t call it success). A “gradle run” gets me to the test demo dialog fine, so that’s good. But the very last thing before “BUILD SUCCESSFUL” is a crash from Javadoc - see #3 below.
When I do a command line build of one of the projects that fails in NetBeans (jme3-vr), I get a crash during Javadoc generation. There’s an open bug filed on Oracle’s old JDK bug site for this exception back as far as JDK 9. Interestingly, when I build with JDK 12 this crash turns into about 100 or so warnings. So I could probably fix that for 11, using those warnings as a guide.
Other subprojects report “problems” in NetBeans, but allegedly build successfully if I click Clean and Build Project. I’ll go into details later if I don’t find a simple cause.
I’m going to continue trying to work through these issues (maybe resulting in some bug reports to NetBeans if that can be determined), but if anyone has any insights or suggestions, I’m listening.
I use sdkman so it’s trivial to switch to virtually any other non-Oracle version of Java or Gradle to try those out (Windows users, you should be jealous). I’ve also tried Java 8, with similar results (at least the vr javadoc crash doesn’t happen), which leads me to believe this is more about the NB Gradle support.
I’ll try the old plugin (I assume that’s just the old one) just to see if that works, but I’m going to keep fighting this one a little longer. I’ll probably lose but maybe I’ll be able to put together a useful bug report. Unfortunately JME’s Gradle build is pretty complicated, so a “small” example to reproduce might be some work to build.
WIll update this thread with any new findings (or failures )…
I use both linux and windows for my Dev workstations. (My main office has a windows workstation, and my other one has a Linux one) Thus, I use netbeans and jme3 with the same projects on both windows and Linux.
Kind of interesting update. It looks like Apache is planning on an 11.1/patch release with Gradle fixes. I built NetBeans myself from their master branch… most of the errors were gone. Tested with OpenJDK 8 and 12.
It looks like the problem now is Android examples. (But who cares right?#pcmasterrace) Actually I tried resolving that with another version of gradle (tried 5.4.1 and 4.10.2), but no better results.
I don’t know if that’s a known issue or what, maybe something trivial is wrong on my end:
Plugin with id ‘com.android.application’ not found.
Not a problem for me, as the “solution” will be to close the subproject, but those using that stuff should probably defer upgrading.
Public service announcement: NB 11 “Gradle patch” was released, problems look resolved other than that android-examples plugin thing.
Had to go to Plugins->Updates->Check for Updates where a Groovy/Gradle 1.0.1 patch shows up. (Integrated Gradle support is built into the Groovy plugin.)
I’ve noticed there’s yet another bug which causes false positive error flags. This one is more of an annoyance, because they can be resolved with some “tinkering” or clearing the nb gradle cache, but yeah… still a little more work to do on that front. So far it seems to be more of a problem if you switch Git branches, so probably not a show stopper.
I’m keeping in touch with the NB team to help them track down, seems like they have a hypothesis for a cause, but the fix apparently isn’t easy. Will update if I discover more (if anyone still cares)…
)…
I’ve noticed there’s yet another bug which causes false positive error flags. This one is more of an annoyance, because they can be resolved with some “tinkering” or clearing the nb gradle cache, but yeah… still a little more work to do on that front. So far it seems to be more of a problem if you switch Git branches, so probably not a show stopper.