Fixing NetBeans Gradle Support for OpenJFX

[Laszlo Kishalmi]

On 7/20/20 1:15 PM, Kevin Rushforth wrote:
> 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?
There is no semantic association. It is just the binding of the 
sub-projects together. Recent Gradle doesn't generate the jar files of 
the sub-projects if not asked for that specifically. Though if 
javafx:base project is asked of it's main output it would be a jar file 
with a second precision suffix in it's name. Also if you ask for the 
dependencies of javafx:graphics it will list a dependency on a 
javafx:base base jar with the second precision suffix in its name. The 
jar file does not have to be exist, NetBeans still would able to find 
out the dependency between the two sub-projects, but these jar names 
shall be the same. So if these two queries happen in different times the 
jar name would not match.
>
>> 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.
Thank you! I did not know that! That's something I can work on!
>
>>    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
>>
>>
>