[
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803496#comment-17803496
]
ASF GitHub Bot commented on WICKET-7090:
----------------------------------------
papegaaij commented on code in PR #758:
URL: https://github.com/apache/wicket/pull/758#discussion_r1442721690
##########
wicket-auth-roles/pom.xml:
##########
@@ -24,7 +24,7 @@
<relativePath>../pom.xml</relativePath>
</parent>
<artifactId>wicket-auth-roles</artifactId>
- <packaging>bundle</packaging>
+ <packaging>jar</packaging>
Review Comment:
@mattrpav This change is to get correct timestamps on files (also called
entries) in the jar files. The maven-bundle-plugin does not set these
timestamps at all, causing them to revert to the jar-epoch (02-01-1980). The
maven-jar-plugin honors `project.build.outputTimestamp`. If it also gives us
reproducible builds, that's a bonus but not the reason for this change.
We do however not want to break OSGi support. However, none of the Wicket
core developers uses OSGi, so this is very hard for us to test. With this
change, the produced jars *should* still be valid OSGi bundles, but we have no
good way to verify this. It be really great of you could check this.
As far as I know OSGi, the only thing that makes a normal jar an OSGi bundle
is a set of entries in the MANIFEST.MF. These all seem unaffected by this
change (I compared before and after), so I think the change is correct. But
maybe you can point to something else that must be in place for an OSGi bundle?
> Files in release jars do not have a modification timestamp set
> --------------------------------------------------------------
>
> Key: WICKET-7090
> URL: https://issues.apache.org/jira/browse/WICKET-7090
> Project: Wicket
> Issue Type: Bug
> Components: release
> Affects Versions: 9.8.0, 9.9.0, 9.10.0, 9.11.0, 9.12.0, 9.13.0, 9.14.0,
> 9.15.0, 9.16.0
> Reporter: Emond Papegaaij
> Assignee: Emond Papegaaij
> Priority: Minor
>
> Starting with 9.8.0, the release jars are built with file entries without a
> last modification timestamp. This can cause issues if
> {{LastModifiedResourceVersion}} used for the {{{}resourceCachingStrategy{}}}.
> The browser may be using an older version of the resource, even if a newer
> version is available. This strategy is normally only used in development
> mode, but even then this can cause unexpected behavior.
> As discussed on the dev list, the best we can do is to set the last
> modification timestamp to fixed time during the release, as git doesn't track
> this. A suggestion is to use the project.build.outputTimestamp property:
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
