Fixing NetBeans Gradle Support for OpenJFX

[Joeri Sykora]

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
>:

> 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
> >> On July 20, 2020 at 5:42:30 PM CDT, Kevin Rushforth <
> 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
> >>>
>
>