Timestamp in classes inside 2.14.0 jar showing 02/01/1980

[elizalde1981]

Any idea why the classes inside version 2.14 are showing 02/01/1980??

[cowtowncoder]

I don't know. It could perhaps be related to "Reproducible Builds" changes since use of constant timestamp for classes would remove one source of non-meaningful differences in jars. This was done for Jackson 2.14.
(see https://maven.apache.org/guides/mini/guide-reproducible-builds.html )

Is there a specific problem here or just general curiosity?

[cowtowncoder]

Yes, I think this is related to Reproducible Builds, but something seems wrong: only META-INF entries have expected timestamp. Classes do not...

[elizalde1981]

I don't know. It could perhaps be related to "Reproducible Builds" changes since use of constant timestamp for classes would remove one source of non-meaningful differences in jars. This was done for Jackson 2.14. (see https://maven.apache.org/guides/mini/guide-reproducible-builds.html )

Is there a specific problem here or just general curiosity?

Just general curiosity

[cowtowncoder]

@hboutemy See ^^^ -- I suspect that for purposes of RB this works, but it is awkward that class file timestamps are in distant past. Do you know what might be causing it, or, more importantly, how to fix it?

[cowtowncoder]

Looks like this might be same as

open-telemetry/opentelemetry-java-instrumentation#2517

but I don't see a resolution there...

[hboutemy]

for Jackson Databind, the project.build.outputTimestamp value that is defined in pom.xml (and perfectly updated to the release time) should be used instead: this is what is done by many Maven plugins like maven-jar-plugin, but I had a look and it seems that Felix's maven-bundle-plugin just overlooks the value. I suppose this is Bnd that does the work.
=> we'll have to open issues to have this improved

For Open Telemetry, they use Gradle for their build: in Gradle, the use of this fixed timestamp from the past is a design decision: they don't configure the timestamp par project, but just force this fixed arbitrary value

I think that both cases are related, because Bnd is built with Gradle, then I suppose (I may be wrong) the author designed his Reproducible Builds feature for Bnd output the way Gradle designed it...

[cowtowncoder]

Thank you @hboutemy -- was about to suggest it might be bundle plugin as that'd be likely difference. I hope it is resolvable, although fundamentally value chosen only needs to be stable and not necessarily useful.

We seem to be using the latest maven-bundle-plugin, 5.1.8:

https://mvnrepository.com/artifact/org.apache.felix/maven-bundle-plugin

so I guess this is the current behavior.

EDIT: This bndtools/bnd#3521 issue seems quite relevant. As well as:

https://github.com/bndtools/bnd/tree/master/maven/bnd-maven-plugin#reproducible-builds

Maybe we just need to add:

To support reproducible output, the following Bnd instructions need to be configured:

-noextraheaders: true
-snapshot: SNAPSHOT

somehow... defaults are actually set in oss-parent repo (https://github.com/FasterXML/oss-parent/)

[hboutemy]

Maybe we just need to add: ...

no, you don't need to add anything: as written to the doc you pointed to, it's done automatically by bnd-maven-plugin when outputTimestamp is defined. Notice that your build does not use bnd-maven-plugin

same is done by Maven Bundle Plugin, see apache/felix-dev@957e5c9

I suppose that creating a sample project using bnd-maven-plugin and improving bnd-maven-plugin to get the desired result looks like a good idea, because it will be easier for Bnd maintainer: once everything works as expected with bnd-maven-plugin, Felix's maven-bundle-plugin can mimic the same updates (notice: don't ask me why 2 plugins exist, I'm definitively not an OSGi expert...)

[cowtowncoder]

@hboutemy Ah. So it's "the other" OSGi bundle plug-in. That explains why configuration settings seemed different.

Unfortunately my knowledge of OSGi bundle building is very limited: the whole setup was a contribution.
So I don't think I will be able to build a PoC on my own, in a way that reproduces other aspects of current build -- another big issue being that there is no way currently to verify correctness of the resulting jar (ideally CI would check these by loading resulting bundle into OSGi container, including dependencies).

But maybe someone else with more knowledge can help.
On plus side the current behavior is still acceptable, and use of "wrong" timestamps is more of an annoyance than issue.
... unless someone finds there is an issue with some other tooling that expected sensible timestamps. We'll see.

I guess conversion from one bundle plugin (Felix) to the other (bnd-maven-plugin) is detailed here:

https://wcm-io.atlassian.net/wiki/spaces/WCMIO/pages/1267040260/How+to+switch+from+maven-bundle-plugin+to+bnd-maven-plugin

[cowtowncoder]

@hboutemy Just to make sure I understand state of things: it sounds like neither Felix maven-bundle-plugin nor biz.aQute.bnd:bnd-maven-plugin automatically handle things the way we'd want, wrt specified timestamp.
But both could perhaps be improved to do so. Is my understanding correct?

[hboutemy]

@cowtowncoder thanks for sharing the migration article: I'm learning very interesting things about these 2 plugins, I'm starting to understand the story behind

which leads to an answer on "it sounds like neither Felix maven-bundle-plugin nor biz.aQute.bnd:bnd-maven-plugin automatically handle things the way we'd want, wrt specified timestamp.
But both could perhaps be improved to do so. Is my understanding correct?"

good news: not exactly, the situation is better: the bnd-maven-plugin as used in the migration documentation will bring the updated timestamp in the jar file (because it uses bnd-maven-plugin:bnd-process goal only to generate manifests, and lets jar:jar do the jar, and jar:jar respects the configured timestamp)

Felix maven-bnd-plugin does not respect the timestamp, because it delegates the jar creation to Bnd, which seems not to respect the timestamp from what we saw in your Jackson project. And I suppose bnd-maven-plugin:jar to do exactly the same

So the quick summary is: if you migrate Jackson to bnd-maven-plugin with packaging jar instead of bundle as described in the migration documentation, you should have the expected result: jars with updated timestamp

(I learned many things these days, thanks a lot)

[cowtowncoder]

@hboutemy Ah. Interesting! So at least there is a way forward. I'll need to figure out who could help with migration; mostly wrt verifying that resulting OSGi bundle works as well or better after change -- this also would need to be done for all dozen of repos or so. But the first one would no doubt be most work and should be able to use same procedure for others.

[hboutemy]

@cowtowncoder I worked on it: in fact, we can avoid the full bnd-maven-plugin migration for now and just apply the good idea from the migration documentation: use maven-bundle-plugin only for manifest creation, but let maven-jar-plugin create the jar (which will preserve configured output timestamp)

[cowtowncoder]

Excellent, thank you @hboutemy !