Re: Fixing NetBeans Gradle Support for OpenJFX

[Kevin Rushforth]

For developer builds, the full version includes the time stamp. This is 
reflected in the "javafx.runtime.version" system property. For release 
builds, the time stamp is replaced with the build number. We've never 
included a time stamp anywhere else, and I don't see much need to add 
one without a good reason.


-- Kevin

On 7/24/2020 7:54 AM, Eric Bresie wrote:

Would a inclusion of timestamp within generated META-INF\MANIFEST.MF allow
some 'timestamp" without impacting the generated jar name also be worth
considering?

Eric Bresie
ebre...@gmail.com


On Thu, Jul 23, 2020 at 12:42 PM Kevin Rushforth 
wrote:


In that case, we can probably remove the time stamp from MAVEN_VERSION
altogether in a follow-up fix, since it is never used for any released
version, including early access builds. Not a high priority though once
the entire publishing task is qualified by a property.

-- Kevin


On 7/23/2020 10:26 AM, Joeri Sykora wrote:

We have never had the need to publish snapshot versions. We do however
publish early access builds quite regularly (e.g. 15-ea+6) for the
versions that are in development.

Op do 23 jul. 2020 18:44 schreef Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>:

 The proposed fix will be to disable the maven publishing tasks by
 default, and to not set the project.version at all. So this will
 decouple the maven publishing tasks, and they won't interfere with
 normal developer or production builds.

 Joeri or Johan can confirm, but if they ever do upload a bundle for
 testing, I'm pretty sure they would use a SNAPSHOT designation (set
 manually).

 -- Kevin


 On 7/23/2020 5:55 AM, Eric Bresie wrote:
 > Is there a need for some further cleanup dependency between
 builds maybe to remove duplicate jars / modules with different
 time stamps?
 >
 > Rather than time stamp in these cases should it just use a
 SNAPSHOT designation instead?
 >
 > Eric Bresie
 > ebre...@gmail.com 
 >> On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth
 mailto:kevin.rushfo...@oracle.com>>
 wrote:
 >> I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to
 track fixing
 >> the build.gradle to not include the time stamp, at least by
 default.
 >>
 >> -- Kevin
 >>
 >>
 >> On 7/20/2020 3:16 PM, Kevin Rushforth wrote:
 >>> On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote:
  On 7/20/20 1:15 PM, Kevin Rushforth wrote:
 >> 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.
 >>> Got it. We explicitly disable the jar task for each modular
 project,
 >>> since we don't need them, so we never would have noticed this.
 If I
 >>> enable them, I can see the jar files with the full version

number,

 >>> including the date string.
 >>>
 >>> I'll file a bug to fix it. I'll need to do it in such a way
 that won't
 >>> disrupt generating maven artifacts for testing (actual maven
 artifacts
 >>> for uploading won't be affected anyway), but it should be easy
 to do.
 >>>
 >>> -- Kevin
 >>>

Re: Fixing NetBeans Gradle Support for OpenJFX

[Eric Bresie]

Would a inclusion of timestamp within generated META-INF\MANIFEST.MF allow
some 'timestamp" without impacting the generated jar name also be worth
considering?

Eric Bresie
ebre...@gmail.com


On Thu, Jul 23, 2020 at 12:42 PM Kevin Rushforth 
wrote:

> In that case, we can probably remove the time stamp from MAVEN_VERSION
> altogether in a follow-up fix, since it is never used for any released
> version, including early access builds. Not a high priority though once
> the entire publishing task is qualified by a property.
>
> -- Kevin
>
>
> On 7/23/2020 10:26 AM, Joeri Sykora wrote:
> > We have never had the need to publish snapshot versions. We do however
> > publish early access builds quite regularly (e.g. 15-ea+6) for the
> > versions that are in development.
> >
> > Op do 23 jul. 2020 18:44 schreef Kevin Rushforth
> > mailto:kevin.rushfo...@oracle.com>>:
> >
> > The proposed fix will be to disable the maven publishing tasks by
> > default, and to not set the project.version at all. So this will
> > decouple the maven publishing tasks, and they won't interfere with
> > normal developer or production builds.
> >
> > Joeri or Johan can confirm, but if they ever do upload a bundle for
> > testing, I'm pretty sure they would use a SNAPSHOT designation (set
> > manually).
> >
> > -- Kevin
> >
> >
> > On 7/23/2020 5:55 AM, Eric Bresie wrote:
> > > Is there a need for some further cleanup dependency between
> > builds maybe to remove duplicate jars / modules with different
> > time stamps?
> > >
> > > Rather than time stamp in these cases should it just use a
> > SNAPSHOT designation instead?
> > >
> > > Eric Bresie
> > > ebre...@gmail.com 
> > >> On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth
> > mailto:kevin.rushfo...@oracle.com>>
> > wrote:
> > >> I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to
> > track fixing
> > >> the build.gradle to not include the time stamp, at least by
> > default.
> > >>
> > >> -- Kevin
> > >>
> > >>
> > >> On 7/20/2020 3:16 PM, Kevin Rushforth wrote:
> > >>> On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote:
> >  On 7/20/20 1:15 PM, Kevin Rushforth wrote:
> > >> 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.
> > >>> Got it. We explicitly disable the jar task for each modular
> > project,
> > >>> since we don't need them, so we never would have noticed this.
> > If I
> > >>> enable them, I can see the jar files with the full version
> number,
> > >>> including the date string.
> > >>>
> > >>> I'll file a bug to fix it. I'll need to do it in such a way
> > that won't
> > >>> disrupt generating maven artifacts for testing (actual maven
> > artifacts
> > >>> for uploading won't be affected anyway), but it should be easy
> > to do.
> > >>>
> > >>> -- Kevin
> > >>>
> >
>
>

Re: Fixing NetBeans Gradle Support for OpenJFX

[Kevin Rushforth]

The proposed fix will be to disable the maven publishing tasks by 
default, and to not set the project.version at all. So this will 
decouple the maven publishing tasks, and they won't interfere with 
normal developer or production builds.


Joeri or Johan can confirm, but if they ever do upload a bundle for 
testing, I'm pretty sure they would use a SNAPSHOT designation (set 
manually).


-- Kevin


On 7/23/2020 5:55 AM, Eric Bresie wrote:

Is there a need for some further cleanup dependency between builds maybe to 
remove duplicate jars / modules with different time stamps?

Rather than time stamp in these cases should it just use a SNAPSHOT designation 
instead?

Eric Bresie
ebre...@gmail.com

On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth 
 wrote:
I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to track fixing
the build.gradle to not include the time stamp, at least by default.

-- Kevin


On 7/20/2020 3:16 PM, Kevin Rushforth wrote:

On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote:

On 7/20/20 1:15 PM, Kevin Rushforth wrote:

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.

Got it. We explicitly disable the jar task for each modular project,
since we don't need them, so we never would have noticed this. If I
enable them, I can see the jar files with the full version number,
including the date string.

I'll file a bug to fix it. I'll need to do it in such a way that won't
disrupt generating maven artifacts for testing (actual maven artifacts
for uploading won't be affected anyway), but it should be easy to do.

-- Kevin

Re: Re: Fixing NetBeans Gradle Support for OpenJFX

[Eric Bresie]

Is there a need for some further cleanup dependency between builds maybe to 
remove duplicate jars / modules with different time stamps?

Rather than time stamp in these cases should it just use a SNAPSHOT designation 
instead?

Eric Bresie
ebre...@gmail.com
> On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth 
>  wrote:
> I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to track fixing
> the build.gradle to not include the time stamp, at least by default.
>
> -- Kevin
>
>
> On 7/20/2020 3:16 PM, Kevin Rushforth wrote:
> >
> > On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote:
> > > On 7/20/20 1:15 PM, Kevin Rushforth wrote:
> > > > > 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.
> >
> > Got it. We explicitly disable the jar task for each modular project,
> > since we don't need them, so we never would have noticed this. If I
> > enable them, I can see the jar files with the full version number,
> > including the date string.
> >
> > I'll file a bug to fix it. I'll need to do it in such a way that won't
> > disrupt generating maven artifacts for testing (actual maven artifacts
> > for uploading won't be affected anyway), but it should be easy to do.
> >
> > -- Kevin
> >
>

Re: Fixing NetBeans Gradle Support for OpenJFX

[Kevin Rushforth]

I filed https://bugs.openjdk.java.net/browse/JDK-8249777 to track fixing 
the build.gradle to not include the time stamp, at least by default.


-- Kevin


On 7/20/2020 3:16 PM, Kevin Rushforth wrote:


On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote:

On 7/20/20 1:15 PM, Kevin Rushforth wrote:

   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.


Got it. We explicitly disable the jar task for each modular project, 
since we don't need them, so we never would have noticed this. If I 
enable them, I can see the jar files with the full version number, 
including the date string.


I'll file a bug to fix it. I'll need to do it in such a way that won't 
disrupt generating maven artifacts for testing (actual maven artifacts 
for uploading won't be affected anyway), but it should be easy to do.


-- Kevin

Re: Fixing NetBeans Gradle Support for OpenJFX

[Kevin Rushforth]

On 7/20/2020 2:05 PM, Laszlo Kishalmi wrote:

On 7/20/20 1:15 PM, Kevin Rushforth wrote:

   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.


Got it. We explicitly disable the jar task for each modular project, 
since we don't need them, so we never would have noticed this. If I 
enable them, I can see the jar files with the full version number, 
including the date string.


I'll file a bug to fix it. I'll need to do it in such a way that won't 
disrupt generating maven artifacts for testing (actual maven artifacts 
for uploading won't be affected anyway), but it should be easy to do.


-- Kevin

Re: 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 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
   /build/classes/java/main/javafx.base/ instead of
   /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
   /build/classes/java/main// just inside
   /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 / 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 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= 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
   

Re: 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 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
   /build/classes/java/main/javafx.base/ instead of
   /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
   /build/classes/java/main// just inside
   /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 / 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 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= 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
   /build/classes/java/main/javafx.base/ instead of
   /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
   /build/classes/java/main// just inside
   /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 

Fixing NetBeans Gradle Support for OpenJFX

[Laszlo Kishalmi]

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 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= 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
   /build/classes/java/main/javafx.base/ instead of
   /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
   /build/classes/java/main// just inside
   /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