Use reproducible version qualifiers

[Zlika]

Use reproducible version qualifiers when project.build.outputTimestamp property is set.
This is a follow-up of #4546.

[github-actions]

Test Results

  606 files    606 suites   4h 8m 20s ⏱️
  434 tests   425 ✅  7 💤 2 ❌
1 302 runs  1 278 ✅ 22 💤 2 ❌

For more details on these failures, see this check.

Results for commit f05034f.

♻️ This comment has been updated with latest results.

[laeubi]

This looks useful I just wondering if we probably should handle this in the default timestamp provider instead?

We would then just have the parameter defined as today but read its value here

tycho/tycho-packaging-plugin/src/main/java/org/eclipse/tycho/buildversion/DefaultBuildTimestampProvider.java

Lines 33 to 35 in af85163

	public Date getTimestamp(MavenSession session, MavenProject project, MojoExecution execution) {
	return session.getStartTime();
	}

from the mojo execution configuration.

[Zlika]

This looks useful I just wondering if we probably should handle this in the default timestamp provider instead?

We would then just have the parameter defined as today but read its value here

tycho/tycho-packaging-plugin/src/main/java/org/eclipse/tycho/buildversion/DefaultBuildTimestampProvider.java

Lines 33 to 35 in af85163

	public Date getTimestamp(MavenSession session, MavenProject project, MojoExecution execution) {
	return session.getStartTime();
	}

from the mojo execution configuration.

I think you're right. I've refactored the PR to only change the DefaultBuildTimestampProvider. What do you think of this?

[laeubi]

Testfailure is unrelated

[laeubi]

I don't know why but Github indicates you have renamed your previous tests instead of adding a new test. Is this intentional?

[Zlika]

I don't know why but Github indicates you have renamed your previous tests instead of adding a new test. Is this intentional?

I renamed the integration test class from ReproducibleArchiveTimestampTest to ReproducibleBuildTest because I will test here all the reproducibility problems that need to be fixed (other PR will be required for that). Here I added a check to assert that the build version qualifier is the one expected. Adding a new test would require to add another "test project", or to run the tests twice, so I simply added a new check to the existing check. If you think there is a better way to do please tell me.

[laeubi]

@Zlika this looks fine now, can you probably squash all commits into one?

[Zlika]

@Zlika this looks fine now, can you probably squash all commits into one?

Can't you squash the commits directly here when you merge the PR?

[laeubi]

I can do it but this often leads to "strange" commits authored by github bot, so if you don't mind, just quash, rebase and force push and I think it can be merged (and backported) right away.

[Zlika]

I can do it but this often leads to "strange" commits authored by github bot, so if you don't mind, just quash, rebase and force push and I think it can be merged (and backported) right away.

Ok, done.Thanks.

[laeubi]

Thanks again!

[eclipse-tycho-bot]

💚 All backports created successfully

Status	Branch	Result
✅	tycho-4.0.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation and see the Github Action logs for details

[Zlika]

Thanks @laeubi for the merge.
I want to propose another PR where I need to create a utility method that will be called from several plugins. I cannot find a good location for this utility method. I tried to put it in tycho-core, but this module is not used by all the plugins. Is there a good location somewhere in the code base for common code that can be used in all the plugins?

[laeubi]

We have tycho-api module or tycho-spi, if there is no dependency to any of those it can usually easily be added.