Closed iloveeclipse closed 6 months ago
iloveeclipse
commented
6 months ago @laeubi , @HannesWell : any idea why local SDK build would fail now with this error?
I always run SDK build on Friday locally that is used for internal product tests to find regressions on master. It used to work since years in (mostly) same configuration (sometimes maven or Java version need an update, but the rest is unchanged / automated).
sravanlakkimsetti
commented
6 months ago @iloveeclipse Based on my past experience I can say this is a comparator problem. Comparator has replaced newly built org.eclipse.swt with one from 4.32-I-builds repository.
Here are my observations Fully qualified version for org.eclipse.swt.gtk.linux.x86_64 is 3.126.0.v20240313-1127. But org.eclipse.swt requires version 3.126.0.v20240313-1227.
I think the root cause in the calculation of git timestamp. You are getting 20240313-1127 instead of 20240313-1227. Based on the 1 hour in time stamp difference I am guessing this may be caused by DST change at the start of this week.
As far as I remember the qualifier used to be calculated based on UTC timestamp. I may be worth investigating why the DST is being taken into account now.
The qualifier calculation is done in tycho plugin tycho-packaging:4.0.7-SNAPSHOT:build-qualifier (default-build-qualifier)
sravanlakkimsetti
commented
6 months ago More information
The commit used for calculating qualifier is https://github.com/eclipse-platform/eclipse.platform.swt/commit/9f206d8714af98b0bff29145f994484862bac378. UTC timestamp for this is 20240314-1227 The question here is why the qualifier is calculated as 20240314-1127
iloveeclipse
commented
6 months ago @sravanlakkimsetti : many thanks! I haven't noticed 1 hour version difference at all!
I think the root cause in the calculation of git timestamp. You are getting 20240313-1127 instead of 20240313-1227. Based on the 1 hour in time stamp difference I am guessing this may be caused by DST change at the start of this week.
@HannesWell, @laeubi : could you please check whether tycho or SWT should be fixed here? It sounds like SWT build or tycho (or both if it is always tycho) use unsafe ways to compute manifest version based on git timestamp, based not on UTC time as mentioned by Sravan:
As far as I remember the qualifier used to be calculated based on UTC timestamp. I may be worth investigating why the DST is being taken into account now.
See here, I was running this build in Germany where DST change not happened yet:
[INFO] --- clean:3.3.2:clean (default-clean) @ org.eclipse.swt.gtk.linux.x86_64 ---
[INFO]
[INFO] --- tycho-packaging:4.0.7-SNAPSHOT:build-qualifier (default-build-qualifier) @ org.eclipse.swt.gtk.linux.x86_64 ---
[INFO] The project's OSGi version is 3.126.0.v20240313-1127
[INFO] 
laeubi
commented
6 months ago As far as I know JGit is used here where the commit time is used I can't see we have any influence on the timezone there and it should be GMT based, at least I don't see how Tycho can influence it:
then it uses a datetimeformat: https://tycho.eclipseprojects.io/doc/latest/tycho-packaging-plugin/build-qualifier-mojo.html#format
and internally we force that to use UTC as well: https://github.com/eclipse-tycho/tycho/blob/d6366adf73b9028fb192a550e4bef2950700791a/tycho-packaging-plugin/src/main/java/org/eclipse/tycho/buildversion/BuildQualifierMojo.java#L147
iloveeclipse
commented
6 months ago OK, so that below is what tycho does?
Date date = new Date(commit.getCommitTime() * 1000L);
String formatString = ???
SimpleDateFormat format = new SimpleDateFormat(formatString);
format.setTimeZone(TimeZone.getTimeZone("UTC"));I've quickly checked org.eclipse.jgit.revwalk.RevCommit.commitTime but it seem not to be changed recently and seem not to handle with Dates in any way, just raw git data.
With that, somewhere in the chain above JGit the date was changed.
Where are Date and Format above combined?
Who prints wrong version The project's OSGi version is 3.126.0.v20240313-1127 ?
@laeubi : Can you track back from where it is coming?
laeubi
commented
6 months ago The message is printed when the mojo is executed: https://github.com/eclipse-tycho/tycho/blob/d6366adf73b9028fb192a550e4bef2950700791a/tycho-packaging-plugin/src/main/java/org/eclipse/tycho/buildversion/BuildQualifierMojo.java#L157
If you have a failing build you can run it with mvnDebug (instead of mvn), then checkout the Tycho 4.x branch and import that single project (just ignore any compile errors you probably see), then put a breakpoint on that line and connect the debugger to the maven process you should then see the raw values before passed to any formatting or alike, maybe you need to configure the debug launch to include your project in the source lookup...
iloveeclipse
commented
6 months ago Could it be, https://github.com/eclipse-tycho/tycho/blob/d6366adf73b9028fb192a550e4bef2950700791a/tycho-packaging-plugin/src/main/java/org/eclipse/tycho/buildversion/FragmentHostBuildTimestampProvider.java#L78 needs something like
format.setTimeZone(TimeZone.getTimeZone("UTC"));?
laeubi
commented
6 months ago I think its worth a try.
iloveeclipse
commented
6 months ago I think its worth a try.
Could you try to do so? I simply don't have enough time / experience to build & debug Tycho & use SDK with that debug build.
laeubi
commented
6 months ago Yes I'll take a look later on, just in case here is the simple way to build test:
mvn clean install -T1C -DskipTests-Dtycho.version=4.0.7-SNAPSHOT (or -Dtycho.version=5.0.0-SNAPSHOT)iloveeclipse
commented
6 months ago
- Build Tycho from root of repository:
mvn clean install -T1C -DskipTests- run the build with
-Dtycho.version=4.0.7-SNAPSHOT(or-Dtycho.version=5.0.0-SNAPSHOT)
Seem to work. The patch against tycho master is:
From 476dae62be001a1c311fad4b810959b3c8ec5134 Mon Sep 17 00:00:00 2001
From: Andrey Loskutov <andrey.loskutov@advantest.com>
Date: Mon, 18 Mar 2024 10:57:56 +0100
Subject: [PATCH] Set UTC timezone for format to avoid wrong version used
See https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/1911
---
.../tycho/buildversion/FragmentHostBuildTimestampProvider.java | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tycho-packaging-plugin/src/main/java/org/eclipse/tycho/buildversion/FragmentHostBuildTimestampProvider.java b/tycho-packaging-plugin/src/main/java/org/eclipse/tycho/buildversion/FragmentHostBuildTimestampProvider.java
index e83a11f10..bcb284080 100644
--- a/tycho-packaging-plugin/src/main/java/org/eclipse/tycho/buildversion/FragmentHostBuildTimestampProvider.java
+++ b/tycho-packaging-plugin/src/main/java/org/eclipse/tycho/buildversion/FragmentHostBuildTimestampProvider.java
@@ -15,6 +15,7 @@ package org.eclipse.tycho.buildversion;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.Optional;
+import java.util.TimeZone;
import org.apache.maven.execution.MavenSession;
import org.apache.maven.plugin.MojoExecution;
@@ -77,6 +78,7 @@ public class FragmentHostBuildTimestampProvider implements BuildTimestampProvide
.getString(BuildQualifierMojo.PARAMETER_FORMAT);
SimpleDateFormat format = formatString.map(SimpleDateFormat::new)
.orElseGet(() -> new SimpleDateFormat(BuildQualifierMojo.DEFAULT_DATE_FORMAT));
+ format.setTimeZone(TimeZone.getTimeZone("UTC"));
Date date = timestampFinder.findByDescriptor(descriptor, format);
if (date != null) {
return date;
--
2.36.5
@laeubi : could you please apply patch to tycho & deploy 4.0.7 snapshot, so SDK build could use it?
laeubi
commented
6 months ago It is already on the train:
iloveeclipse
commented
6 months ago Perfect, thanks. I will keep this one open till my next "regular" build is OK without patched tycho.
akurtakov
commented
6 months ago What is the status here?
iloveeclipse
commented
6 months ago Just built one without patching anything.
My local SDK build on tag
I20240314-1800fails (tried two times with maven 3.9.2 / 3.9.6). Last successful build was last Friday at tagI20240307-1800.It seems something is wrong either with SWT or with
org.eclipse.equinox.p2.testsbut I don't see why should it work on master and not on my local build (which is essentially same but just in a different environment).This seem to be the root cause:
So it seems SWT Linux fragment can't be found matching SWT version. I don't understand why, the fragment seem to be built:
Here the end of the maven log: