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
