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
ebresie at gmail.com


On Thu, Jul 23, 2020 at 12:42 PM Kevin Rushforth <kevin.rushforth at oracle.com>
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
> > <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
> >     >>>
> >
>
>