Community
Participate
Working Groups
After a recent change to the help feature, so that it's "feature version" would match the version of its branding bundle, (bug 486662) it is sort of obvious its qualifier is not being set or computed correctly. In the latest I build, versioned I20160127-2000 the branding bundle (org.eclipse.help.base) was versioned as expected: 4.1.0.v20160127-2000, but the feature appears to have a qualifier based on literally the "time that feature is built" instead of "buildTimestamp". Its version was 4.1.0.v20160127-2142.
Oddly, the there are some other features with the exact same incorrect qualifier: org.eclipse.platform feature org.eclipse.sdk feature But most appear to be correct: org.eclipse.jdt feature org.eclipse.rcp feature org.eclipse.pde feature I am guessing the "buildTimestamp" is re-computed at some point when it should not be. (or, there is accidentally two variables meant to represent "buildTime").
The only pattern I see, between those that are correct and those that are wrong is that the correct ones are in the same repository, and the incorrect ones are in different repositories. (That is, the branding bundle and feature are in same repository vs. the branding bundle and feature are in different repositories. I'll have to look at the logs to see "effective pom", build order, etc. The branding bundles typically have this in their pom.xml files: <build> <plugins> <plugin> <groupId>org.eclipse.tycho</groupId> <artifactId>tycho-packaging-plugin</artifactId> <version>${tycho.version}</version> <configuration> <format>'v${buildTimestamp}'</format> </configuration> </plugin> </plugins> </build> The features do not. I suspect, at worst, we could code the features the same way? Or, perhaps force correct "build order" if the logs show a difference?
Another "hint" comes in the logs, where fuller "effective targets" and processing is logged. I compared org.eclipse.platform feature (one of the incorrect ones) with org.eclipse.pde feature (one of the correct ones. It seems in both cases, the "qualifier computation" is trying to compute the value, says that it can not, and then "falls back" to some default value. And the default value for the platform feature is incorrect. It is suspicious that the incorrect features are in the "eclipse.platform.releng" repository -- but so far, I have not seen anything that changes the "default fallback value" or similar. Platform feature: 1308589 [DEBUG] (s) format = 'v'yyyyMMdd-HHmm 1308590 [DEBUG] (f) packaging = eclipse-feature 1308591 [DEBUG] (f) project = MavenProject: org.eclipse.platform.feature:org.eclipse.platform:4.6.0-SNAPSHOT @ /opt/public/eclipse/builds/4I/gitCache/eclipse.platform.releng.aggregator/eclipse.platform.releng/features/org.eclipse.platform-feature/pom.xml 1308592 [DEBUG] (f) session = org.apache.maven.execution.MavenSession@47ca5d7c 1308593 [DEBUG] (f) timestampProvider = jgit 1308594 [DEBUG] -- end configuration -- 1308595 [DEBUG] Could not parse qualifier timestamp v201510161327 1308596 [DEBUG] Could not parse qualifier timestamp v201508180515 1308597 [INFO] The project's OSGi version is 4.6.0.v20160127-0840 PDE feature: 935636 [DEBUG] (s) format = 'v'yyyyMMdd-HHmm 935637 [DEBUG] (f) packaging = eclipse-feature 935638 [DEBUG] (f) project = MavenProject: org.eclipse.pde.feature:org.eclipse.pde:3.12.0-SNAPSHOT @ /opt/public/eclipse/builds/4I/gitCache/eclipse.platform.releng.aggregator/eclipse.pde/org.eclipse.pde-feature/pom.xml 935639 [DEBUG] (f) session = org.apache.maven.execution.MavenSession@47ca5d7c 935640 [DEBUG] (f) timestampProvider = jgit 935641 [DEBUG] -- end configuration -- 935642 [DEBUG] Could not parse qualifier timestamp v201404251740 935643 [DEBUG] Could not parse qualifier timestamp v201404251740 935644 [INFO] The project's OSGi version is 3.12.0.v20160127-0800
As another 'hint', looking at Tycho's code, part of it's "fallback" strategy is the code pasted below. It would be interesting to 'print' and/or 'set' <reactorBuildTimestampProperty> (as a "long", so must be in Date +s format?) though I am pretty sure that is not the intended workflow. private static final String REACTOR_BUILD_TIMESTAMP_PROPERTY = "reactorBuildTimestampProperty"; public Date getTimestamp(MavenSession session, MavenProject project, MojoExecution execution) { Date timestamp; String value = session.getUserProperties().getProperty(REACTOR_BUILD_TIMESTAMP_PROPERTY); if (value != null) { timestamp = new Date(Long.parseLong(value)); } else { timestamp = new Date(); session.getUserProperties().setProperty(REACTOR_BUILD_TIMESTAMP_PROPERTY, Long.toString(timestamp.getTime())); } return timestamp; }
(In reply to David Williams from comment #4) > As another 'hint', looking at Tycho's code, part of it's "fallback" strategy > is the code pasted below. > > It would be interesting to 'print' and/or 'set' > <reactorBuildTimestampProperty> > (as a "long", so must be in Date +s format?) > though I am pretty sure that is not the intended workflow. > I have discovered, in a local test build, setting that property does "fix" the problem. I've opened bug 486783 to see if Tycho team has advice on "the right" way to fix or work around the issue.
(In reply to David Williams from comment #5) > I've opened bug 486783 to see if Tycho team has advice on "the right" way to > fix or work around the issue. I have not heard from Tycho team about workarounds, so will add -DreactorBuildTimestampProperty="${TIMESTAMP}" to our build to avoid the problem. This is at the same point in mvn invocation where we set -DbuildTimestamp="${TIMESTAMP}" I have opened a reminder bug to remove workaround in the future; bug 489510.
(In reply to David Williams from comment #6) > > I have not heard from Tycho team about workarounds, so will add > -DreactorBuildTimestampProperty="${TIMESTAMP}" to our build to avoid the > problem. This was incorrect fix. It should have been -DreactorBuildTimestampProperty="${RAWDATE}" where RAWDATE=$( date +%s ) TIMESTAMP already has the 'hyphen' in it, such as 20160313-0800 which Tycho complains about being a non-numberic format.
reopening since this workaround appears to affect those that override the parent's default timestampProvider and use <timestampProvider>default</timestampProvider> See bug 489594.
Moving to RC1. I think a fix in Tycho may have fixed this issue, but would like to evaluate and monitor to make sure we no longer see.
I've not seen this issue recently. The root cause may have been the now fixed bug 480951. But, won't mark as a dup, since I do not know for sure and we have not had too many changes going in so harder to assess then. Will re-open if I see again.
