[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Fixing NetBeans Gradle Support for OpenJFX
From:       Kevin Rushforth <kevin.rushforth () oracle ! com>
Date:       2020-07-24 23:00:38
Message-ID: e1f45c6d-5357-99bb-b3d6-8cd58d606f3f () oracle ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]