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