JavaFX fails to build with multiple different issues

[Ty Young]

On 12/3/18 6:52 PM, Michael Ennen wrote:
> The first one is definitely a bug and I would consider opening a PR to 
> remove
> the final modifier on https://github.com/javafxports/openjdk-jfx.


Done. <https://github.com/javafxports/openjdk-jfx/pull/313> This is the 
first time I've ever done a PR request so if there is anything wrong 
besides not signing away my left kidney with my own blood then let me 
know(/joke). I don't think it has any negative impact seeing as how the 
code requires the instance to be mutable anyway unless this really is a 
different code path from before(why would it be?) but I can't exactly 
check either way until I can compile and it's wrong either way.



>
> The second one is a gradle error - what gradle command-line invocation
> are you using?


"gradle build" though just doing "gradle" or even "gradle clean" results 
in the same fail. All tasks are borked would be my guess.


>
> On Mon, Dec 3, 2018 at 4:58 PM Ty Young <youngty1997 at gmail.com 
> <mailto:youngty1997 at gmail.com>> wrote:
>
>     So here is an odd one: JavaFX is now longer building on Arch Linux
>     even
>     on a previous source directory that did compile just fine. I'm
>     guessing
>     that something was updated and isn't compatible with JavaFX's build
>     scripts but I'm not entirely sure what exactly it is.
>
>
>     (Note: just to make sure the files didn't magically become corrupt or
>     something I redownloaded from the Github mirror. Same issue.)
>
>
>     First error is this:
>
>
>     ~/openjdk-jfx-develop/buildSrc/src/main/groovy/com/sun/javafx/gradle/NativeCompileTask.groovy:
>
>     118: The variable [files] is declared final but is reassigned
>     . At [118:21]  @ line 118, column 21.
>                             files += file;
>
>
>     which is easy enough to fix by simply removing final from line
>     105. Even
>     though this was clearly an issue(why use final on local variables?
>     I've
>     never understood why people do it...), I'm not entirely sure why it's
>     throwing an error now. Is it because Groovy is a scripting
>     language and
>     the build scripts never used to follow that logic path?
>
>
>     Next issue is this:
>
>
>      > Could not get unknown property 'moduleEmptyPublicationJarLinux'
>     for
>     task set of type org.gradle.api.internal.tasks.DefaultTaskContainer
>
>
>     which I'm not sure on how to resolve. Thinking that it may be
>     related to
>     my custom built JDK I tried swapping it out for an older one that
>     I know
>     worked before and yet it fails all the same.
>
>
>
> -- 
> Michael Ennen