Fixing NetBeans Gradle Support for OpenJFX

[Kevin Rushforth]

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 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at 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
>     > Ebresie at gmail.com <mailto:Ebresie at gmail.com>
>     >> On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth
>     <kevin.rushforth at oracle.com <mailto:kevin.rushforth at 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
>     >>>
>