You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Emond Papegaaij <em...@gmail.com> on 2023/12/06 15:48:41 UTC
Incorrect modification time in jars
Hi,
With the upgrade to wicket 9.16.0 we've seen some issues with the new
'Wicket.Event.requestSubmit' method that was added to wicket-ajax-jquery.
It turns out that a cached version of the resource was used, and this seems
to be caused by an incorrect version string in the url. The filename is
rendered as 'wicket-ajax-jquery-ver-318207600000.js'. The same is true for
JQuery: 'jquery-3.7.1-ver-318207600000.js'. This seems to be caused by an
incorrect modification time in the jar. Our repository shows all files in
the wickets jars to have the timestamp 318211200000. Other resources (not
from wicket itself) do have correct timestamps.
This seems to be the case since wicket 9.8.0. Versions prior to that have
correct timestamps. Did something change to the way wicket is built between
9.7.0 and 9.8.0? I can't find anything related in the commits.
We can switch from LastModifiedResourceVersion to something else in our
applications to work around this issue, but maybe we should consider
tracking down this issue and release a 9.16.1. I'd expect we are not the
only ones using LastModifiedResourceVersion.
Best regards,
Emond
Re: Incorrect modification time in jars
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Jan 4, 2024 at 1:02 PM Emond Papegaaij <em...@gmail.com>
wrote:
> >
> > I've just opened a PR with this change (
> > https://github.com/apache/wicket/pull/758). I don't think this change
> > will be problematic, but as it only really influences the release builds,
> > it's hard to test its effect without doing an actual release.
> >
>
> It turned out that maven-bundle-plugin doesn't set these timestamps at all.
> The fix was to switch back to jar-packaging and use the maven-bundle-plugin
> to generate the manifest only. The jar is now again built by the
> maven-jar-plugin, which does respect project.build.outputTimestamp. The
> contents of the manifest.mf is equivalent (not identical, because the
> entries are sorted differently and the line length is different), so I
> think this change is ok.
>
Sounds good to me!
I hope the OSGi support isn't broken. I am not sure what else the
maven-bundle-plugin does. Hopefully some OSGi user will test it and report
back!
Thank you, Emond!
>
> Best regards,
> Emond
>
Re: Incorrect modification time in jars
Posted by Emond Papegaaij <em...@gmail.com>.
>
> I've just opened a PR with this change (
> https://github.com/apache/wicket/pull/758). I don't think this change
> will be problematic, but as it only really influences the release builds,
> it's hard to test its effect without doing an actual release.
>
It turned out that maven-bundle-plugin doesn't set these timestamps at all.
The fix was to switch back to jar-packaging and use the maven-bundle-plugin
to generate the manifest only. The jar is now again built by the
maven-jar-plugin, which does respect project.build.outputTimestamp. The
contents of the manifest.mf is equivalent (not identical, because the
entries are sorted differently and the line length is different), so I
think this change is ok.
Best regards,
Emond
Re: Incorrect modification time in jars
Posted by Emond Papegaaij <em...@gmail.com>.
Op do 7 dec 2023 om 08:58 schreef Emond Papegaaij <emond.papegaaij@gmail.com
>:
> Op do 7 dec 2023 om 02:35 schreef Maxim Solodovnik <so...@gmail.com>:
>
>> File timestamps might be set to `project.build.outputTimestamp` by Maven
>> This enables "reproducible builds"
>> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
>>
>> I believe Maven `project.build.outputTimestamp` property should be set
>> in the pom.xml by release manager during release
>> should be easy to check :) (sorry, I don't have time to check it myself
>> :(((( )
>>
>
> I think just adding the property set to the current date should be enough.
> The maven-release-plugin will take care of updating the property during the
> release as you can see here:
> https://github.com/apache/maven/commit/3fc399318edef0d5ba593723a24fff64291d6f9b#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R176
>
I've just opened a PR with this change (
https://github.com/apache/wicket/pull/758). I don't think this change will
be problematic, but as it only really influences the release builds, it's
hard to test its effect without doing an actual release.
Best regards,
Emond
Re: Incorrect modification time in jars
Posted by Emond Papegaaij <em...@gmail.com>.
Op do 7 dec 2023 om 02:35 schreef Maxim Solodovnik <so...@gmail.com>:
> File timestamps might be set to `project.build.outputTimestamp` by Maven
> This enables "reproducible builds"
> https://maven.apache.org/guides/mini/guide-reproducible-builds.html
>
> I believe Maven `project.build.outputTimestamp` property should be set
> in the pom.xml by release manager during release
> should be easy to check :) (sorry, I don't have time to check it myself
> :(((( )
>
I think just adding the property set to the current date should be enough.
The maven-release-plugin will take care of updating the property during the
release as you can see here:
https://github.com/apache/maven/commit/3fc399318edef0d5ba593723a24fff64291d6f9b#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R176
Best regards,
Emond
Re: Incorrect modification time in jars
Posted by Maxim Solodovnik <so...@gmail.com>.
File timestamps might be set to `project.build.outputTimestamp` by Maven
This enables "reproducible builds"
https://maven.apache.org/guides/mini/guide-reproducible-builds.html
I believe Maven `project.build.outputTimestamp` property should be set
in the pom.xml by release manager during release
should be easy to check :) (sorry, I don't have time to check it myself :(((( )
On Thu, 7 Dec 2023 at 04:50, Emond Papegaaij <em...@gmail.com> wrote:
>
> >
> >
> >
> > https://github.com/apache/wicket/blob/a68536eb095bb5cf59e4063b6af9436523ddc623/wicket-core/src/main/java/org/apache/wicket/settings/ResourceSettings.java#L650-L664
> > LastModifiedResourceVersion is used in DEV mode by default.
> > MessageDigestResourceVersion is for PROD.
> >
>
> Yes, I know. I don't know why we ever configured our applications to always
> use LastModifiedResourceVersion, but this was working fine for us, until
> wicket 9.8.0. Something changed that caused the timestamps to be reset at
> that time. I think we should try to find out what caused this, and fix it.
> As you said LastModifiedResourceVersion is used by default in dev mode, and
> it is currently broken. I'll create a Jira issue for this tomorrow, I
> didn't have the time for it today.
>
> For us, I've already recommended everyone to remove our custom
> configuration of this setting. The default makes much more sense, and only
> developers will be faced with a possible invalid cache entry.
>
> Best regards,
> Emond
>
> >
--
Best regards,
Maxim
Re: Incorrect modification time in jars
Posted by Emond Papegaaij <em...@gmail.com>.
>
>
>
> https://github.com/apache/wicket/blob/a68536eb095bb5cf59e4063b6af9436523ddc623/wicket-core/src/main/java/org/apache/wicket/settings/ResourceSettings.java#L650-L664
> LastModifiedResourceVersion is used in DEV mode by default.
> MessageDigestResourceVersion is for PROD.
>
Yes, I know. I don't know why we ever configured our applications to always
use LastModifiedResourceVersion, but this was working fine for us, until
wicket 9.8.0. Something changed that caused the timestamps to be reset at
that time. I think we should try to find out what caused this, and fix it.
As you said LastModifiedResourceVersion is used by default in dev mode, and
it is currently broken. I'll create a Jira issue for this tomorrow, I
didn't have the time for it today.
For us, I've already recommended everyone to remove our custom
configuration of this setting. The default makes much more sense, and only
developers will be faced with a possible invalid cache entry.
Best regards,
Emond
>
Re: Incorrect modification time in jars
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Dec 6, 2023 at 7:45 PM Emond Papegaaij <em...@gmail.com>
wrote:
> Op wo 6 dec 2023 18:22 schreef Richard Eckart de Castilho <rec@apache.org
> >:
>
> > > We can switch from LastModifiedResourceVersion to something else in our
> > > applications to work around this issue, but maybe we should consider
> > > tracking down this issue and release a 9.16.1. I'd expect we are not
> the
> > > only ones using LastModifiedResourceVersion.
> >
> > I wonder how this is supposed to work at all...
> >
> > AFAIK git does not track the last modification date - so I guess that
> date
> > would reflect whatever the modification date is on the machine of the
> > developer that does the release...?
> >
>
> I'm not sure either, but using the last modification date of a local
>
https://github.com/apache/wicket/blob/a68536eb095bb5cf59e4063b6af9436523ddc623/wicket-core/src/main/java/org/apache/wicket/settings/ResourceSettings.java#L650-L664
LastModifiedResourceVersion is used in DEV mode by default.
MessageDigestResourceVersion is for PROD.
> checkout would be better than using no timestamp at all. For this part of
> the code, it's not a big problem if the modification date is set to a later
> date than what it actually is. It might cause some cached files to be sent
> anyway when in fact the file did not change. The current situation causes
> files to not be sent when they really should be. Actually it would be fine
> if the modification date was set to the current timestamp during the
> release.
>
> Best regards,
> Emond
>
> >
>
Re: Incorrect modification time in jars
Posted by Emond Papegaaij <em...@gmail.com>.
Op wo 6 dec 2023 18:22 schreef Richard Eckart de Castilho <re...@apache.org>:
> > We can switch from LastModifiedResourceVersion to something else in our
> > applications to work around this issue, but maybe we should consider
> > tracking down this issue and release a 9.16.1. I'd expect we are not the
> > only ones using LastModifiedResourceVersion.
>
> I wonder how this is supposed to work at all...
>
> AFAIK git does not track the last modification date - so I guess that date
> would reflect whatever the modification date is on the machine of the
> developer that does the release...?
>
I'm not sure either, but using the last modification date of a local
checkout would be better than using no timestamp at all. For this part of
the code, it's not a big problem if the modification date is set to a later
date than what it actually is. It might cause some cached files to be sent
anyway when in fact the file did not change. The current situation causes
files to not be sent when they really should be. Actually it would be fine
if the modification date was set to the current timestamp during the
release.
Best regards,
Emond
>
Re: Incorrect modification time in jars
Posted by Richard Eckart de Castilho <re...@apache.org>.
Hi,
> On 6. Dec 2023, at 16:48, Emond Papegaaij <em...@gmail.com> wrote:
>
> We can switch from LastModifiedResourceVersion to something else in our
> applications to work around this issue, but maybe we should consider
> tracking down this issue and release a 9.16.1. I'd expect we are not the
> only ones using LastModifiedResourceVersion.
I wonder how this is supposed to work at all...
AFAIK git does not track the last modification date - so I guess that date
would reflect whatever the modification date is on the machine of the
developer that does the release...?
-- Richard