[
https://issues.apache.org/jira/browse/MRESOLVER-634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bas van Erp updated MRESOLVER-634:
----------------------------------
Description:
maven-metadata.xml is refetched for every dependency which uses version-ranges
if the {{resolver-status.properties}} file's "lastUpdated" property is _before_
last midnight (local time, for some reason).
It ignores all updatePolicy configs in settings.xml
I have tried diving into the code, but as I'm not a programmer, I couldn't
really wrap my head around it.
h2. Setup
* Have a {{settings.xml}} with {{<updatePolicy>never</updatePolicy>}} for
everything.
* Have a {{pom.xml}} with a dependency which uses a version-range.
* Run {{mvn validate}} to trigger the resolver and make sure all metadata and
dependencies are downloaded and the Maven cache is warmed up.
h2. Correct
* Use [https://www.epochconverter.com/] to create a millisecond timestamp for
*today* (local-time): 00:00:01
* Replace the {{xxx.xml.lastUpdated=###}} timestamp in the
{{resolver-status.properties}} file of the dependency which is referenced in
the pom.xml
* Run {{mvn validate -X}} to trigger the resolver. It should return something
like: "Skipped remote request for x:y/maven-metadata.xml, locally cached
metadata up-to-date"
* Good
h2. Wrong
* Use [https://www.epochconverter.com/] to create a millisecond timestamp for
*yesterday* (local-time): 23:59:59
* Replace the {{xxx.xml.lastUpdated=###}} timestamp in the
{{resolver-status.properties}} file of the dependency which is referenced in
the pom.xml
* Run {{mvn validate}} to trigger the resolver.
* The resolver will download the maven-metadata.xml again. Every day.
h2. Impact
We have some dependencies which use version ranges for a lot of transitive
dependencies, and I hate it for multiple reasons. But to add insult to injury,
every night the first build will refetch all these metadata files in order to
see if version resolution needs to change. ;)
I have found no way to block this, since version-ranges seem to bypass
repository updatePolicy settings.
was:
maven-metadata.xml is refetched for every dependency which uses version-ranges
if the {{resolver-status.properties}} file's "lastUpdated" property is _before_
last midnight (local time, for some reason).
It ignores all updatePolicy configs in settings.xml
I have tried diving into the code, but as I'm not a programmer, I couldn't
really wrap my head around it.
h2. Setup
* Have a {{settings.xml}} with {{<updatePolicy>never</updatePolicy>}} for
everything.
* Have a {{pom.xml}} with a dependency which uses a version-range.
* Run {{mvn validate}} to trigger the resolver and make sure all metadata and
dependencies are downloaded and the Maven cache is warmed up.
h2. Correct
* Use [https://www.epochconverter.com/] to create a millisecond timestamp for
*today* (local-time): 00:00:01
* Replace the {{xxx.xml.lastUpdated=###}} timestamp in the
{{resolver-status.properties}} file of the dependency which is referenced in
the pom.xml
* Run {{mvn validate -X}} to trigger the resolver. It should return something
like: "Skipped remote request for x:y/maven-metadata.xml, locally cached
metadata up-to-date"
* Good
h2. Wrong
* Use [https://www.epochconverter.com/] to create a millisecond timestamp for
*yesterday* (local-time): 23:59:59
* Replace the {{xxx.xml.lastUpdated=###}} timestamp in the
{{resolver-status.properties}} file of the dependency which is referenced in
the pom.xml
* The resolver will download the maven-metadata.xml again. Every day.
h2. Impact
We have some dependencies which use version ranges for a lot of transitive
dependencies, and I hate it for multiple reasons. But to add insult to injury,
every night the first build will refetch all these metadata files in order to
see if version resolution needs to change. ;)
I have found no way to block this, since version-ranges seem to bypass
repository updatePolicy settings.
> updatePolicy is ignored for version-range metadata requests
> -----------------------------------------------------------
>
> Key: MRESOLVER-634
> URL: https://issues.apache.org/jira/browse/MRESOLVER-634
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
> Environment: Maven 3.9.9, Fedora & MacOS
> Reporter: Bas van Erp
> Priority: Major
>
> maven-metadata.xml is refetched for every dependency which uses
> version-ranges if the {{resolver-status.properties}} file's "lastUpdated"
> property is _before_ last midnight (local time, for some reason).
> It ignores all updatePolicy configs in settings.xml
> I have tried diving into the code, but as I'm not a programmer, I couldn't
> really wrap my head around it.
> h2. Setup
> * Have a {{settings.xml}} with {{<updatePolicy>never</updatePolicy>}} for
> everything.
> * Have a {{pom.xml}} with a dependency which uses a version-range.
> * Run {{mvn validate}} to trigger the resolver and make sure all metadata
> and dependencies are downloaded and the Maven cache is warmed up.
> h2. Correct
> * Use [https://www.epochconverter.com/] to create a millisecond timestamp
> for *today* (local-time): 00:00:01
> * Replace the {{xxx.xml.lastUpdated=###}} timestamp in the
> {{resolver-status.properties}} file of the dependency which is referenced in
> the pom.xml
> * Run {{mvn validate -X}} to trigger the resolver. It should return
> something like: "Skipped remote request for x:y/maven-metadata.xml, locally
> cached metadata up-to-date"
> * Good
> h2. Wrong
> * Use [https://www.epochconverter.com/] to create a millisecond timestamp
> for *yesterday* (local-time): 23:59:59
> * Replace the {{xxx.xml.lastUpdated=###}} timestamp in the
> {{resolver-status.properties}} file of the dependency which is referenced in
> the pom.xml
> * Run {{mvn validate}} to trigger the resolver.
> * The resolver will download the maven-metadata.xml again. Every day.
> h2. Impact
> We have some dependencies which use version ranges for a lot of transitive
> dependencies, and I hate it for multiple reasons. But to add insult to
> injury, every night the first build will refetch all these metadata files in
> order to see if version resolution needs to change. ;)
> I have found no way to block this, since version-ranges seem to bypass
> repository updatePolicy settings.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
