Fixing NetBeans Gradle Support for OpenJFX

[Kevin Rushforth]

Hi Laszlo,

Thanks for reaching out to us. Neil Smith suggested that I report this 
on netbeans-dev, which I haven't done yet, but can do today if you still 
need me to.

To answer some of your specific questions:

> 1. For some reason version calculation is built in the script adding a
>    second precision suffix to the output jar names. This breaks the
>    dependency chain in NetBeans as it evaluates sub-projects
>    individually (which could change somewhere down the road.). So
>    expressing javafx:gracphics dependency would look like:
>    javafx:graphics sources -> <javafx:base jar with a newer suffix>
>    -/-> <javafx:base jar with an older prefix> -> javafx:base sources
>
>    That could be prevented by removing line 1547: project.version =
>    MAVEN_VERSION from the build script.

Interesting. That is only used for the maven "publishing" tasks, and 
shouldn't affect the main build artifacts. I don't see the generated 
version number showing up anywhere in the build output. It would be easy 
enough to suppress this for non-production builds, but I'd want to 
understand how it is causing problems. Does gradle (and thus the 
NetBeans gradle plugin), assign some semantic meaning to the 
project.version attribute?

> 2. Unfortunately even removing the version out of the picture won't
>    help as the generated classes of javafx:base goes into
>    <javafx:base>/build/classes/java/main/javafx.base/ instead of
>    <javafx:base>/build/classes/java/main/
>    So far I couldn't figure it out how that happens.

Yes, that is expected for modules that are compiled as modules, by 
specifying "--module-source-path" to javac.

> I'm not really
>    experienced in modular java builds, just tested a simple modular app
>    with Gradle and it did not generate the classes under a folder
>    <app>/build/classes/java/main/<app module>/ just inside
>    <app>/build/classes/java/main/. So I might miss something here which
>    could make NetBeans be aware of this situation and check.

When compiling using the --module-source-path option, all classes for a 
module are placed under <outputdir>/<modulename> by javac.

>    My theory is that these classes are somehow moved during the build,
>    then the dependency is set externally by specifying
>    --module-source-path in the compiler command line arguments. As of
>    the later NetBeans is not aware of at the moment.

No, we aren't moving them.

> So in order to understand the build more, my questions would be:
>
> 1. What is the reason behind generating the version during build time
>    (with seconds precision)?

This seems unintentional, and in any case could be suppressed for 
non-release builds without too much trouble.

> 2. How the javafx base classes are ending up one folder down the path?

Because we are compiling with "--module-source-path".

> 3. Is it the --module-source-path on the java compiler which actually
>    keep the the dependencies together?

If I understand what you are asking, then yes.

-- Kevin


On 7/20/2020 12:21 PM, Laszlo Kishalmi wrote:
> Dear OpenJFX devs,
>
> As a quick introduction, I'm the main developer behind the Gradle 
> support in Apache NetBeans.
>
> Well, I must say they OpenJFX is using Gradle in a very original way. 
> In order to make NetBeans to be able to be used for OpenJFX 
> development, I need to understand some aspects on that build system 
> you have.
>
> According to my inspections, NetBeans has struggle to discover the 
> dependencies between the sub-projects in JavaFX. At first I see two 
> reason for that:
>
> 1. For some reason version calculation is built in the script adding a
>    second precision suffix to the output jar names. This breaks the
>    dependency chain in NetBeans as it evaluates sub-projects
>    individually (which could change somewhere down the road.). So
>    expressing javafx:gracphics dependency would look like:
>    javafx:graphics sources -> <javafx:base jar with a newer suffix>
>    -/-> <javafx:base jar with an older prefix> -> javafx:base sources
>
>    That could be prevented by removing line 1547: project.version =
>    MAVEN_VERSION from the build script.
>
>    It is a recommendation to handle version as an external property to
>    the standard build process and specify it with -Pversion=<whatever
>    version> on release time only.
> 2. Unfortunately even removing the version out of the picture won't
>    help as the generated classes of javafx:base goes into
>    <javafx:base>/build/classes/java/main/javafx.base/ instead of
>    <javafx:base>/build/classes/java/main/
>    So far I couldn't figure it out how that happens. I'm not really
>    experienced in modular java builds, just tested a simple modular app
>    with Gradle and it did not generate the classes under a folder
>    <app>/build/classes/java/main/<app module>/ just inside
>    <app>/build/classes/java/main/. So I might miss something here which
>    could make NetBeans be aware of this situation and check.
>    My theory is that these classes are somehow moved during the build,
>    then the dependency is set externally by specifying
>    --module-source-path in the compiler command line arguments. As of
>    the later NetBeans is not aware of at the moment.
>
> So in order to understand the build more, my questions would be:
>
> 1. What is the reason behind generating the version during build time
>    (with seconds precision)?
> 2. How the javafx base classes are ending up one folder down the path?
> 3. Is it the --module-source-path on the java compiler which actually
>    keep the the dependencies together?
>
> Thank you, in advance!
>
> -- 
>
>   Laszlo Kishalmi
>
>