[
https://issues.apache.org/jira/browse/WICKET-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17803202#comment-17803202
]
ASF GitHub Bot commented on WICKET-7090:
----------------------------------------
papegaaij commented on code in PR #758:
URL: https://github.com/apache/wicket/pull/758#discussion_r1441863155
##########
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 the bundle plugin is activated by binding one of its goals to the
maven execution phase (in this case `manifest` in `process-classes`). This will
generate the MANIFEST.MF, which will then be used by the maven-jar-plugin. I
can see the correct MANIFEST.MF in the produced jar.
The problem with the maven-bundle-plugin is that it generates jars without
timestamps on its entries. This is valid (and considered reproducible), but
very inconvenient. There is no way to change this when using packaging
`bundle`. I think the produced jars are fine. They do contain the correct
MANIFEST.MF. However, we do not use OSGi, so I have no way of testing it.
> 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)