[jira] [Commented] (MASSEMBLY-989) in RB mode, apply 022 umask to ignore environment group write umask
[ https://issues.apache.org/jira/browse/MASSEMBLY-989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728887#comment-17728887 ] Marat Abrarov commented on MASSEMBLY-989: - Hi [~hboutemy], It looks like the changes made within this improvement made Maven Assembly Plugin not following explicitly configured file / directory permissions when building TARs. Could you please check my [comment|https://issues.apache.org/jira/browse/MASSEMBLY-791?focusedCommentId=17726719=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17726719] in MASSEMBLY-791 for the case which fails with 3.6.0 version of Maven Assembly Plugin and for possible (quick & dirty) fix? Thank you. > in RB mode, apply 022 umask to ignore environment group write umask > --- > > Key: MASSEMBLY-989 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-989 > Project: Maven Assembly Plugin > Issue Type: Improvement >Affects Versions: 3.5.0 >Reporter: Herve Boutemy >Assignee: Herve Boutemy >Priority: Major > Fix For: 3.6.0 > > > after MASSEMBLY-941, as expected, environment umask give different output: > some use 002 (group write by default), some use 022 (group read only by > default) > applying 022 umask in reproducible mode will give the same archive for each > environment: group will be read only -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728880#comment-17728880
]
Tamas Cservenak commented on MNG-7802:
--
Ok, then just for the context: the local repo was "corrupted" in a way that
resolver was unable to find the lastUpdated timestamp in otherwise healthy
file, in these cases resolver uses timestamp = 1L (1 Jan 1970 + 1ms) to signal
this. Still, the effective update policy was "never", so even so "old" file did
not trigger metadata update, that resulted in no discovery of new versions
(reported as bug).
Reason why it did not find that last updated timestamp is most probably
following: Garret used old(er) release of maven-versions-plugin, then switched
to new(er) version of same plugin. The old(er) one uses old code and bits from
maven-compat (a la Maven2), while new version of plugin was switched over to
direct use of resolver. The maven-compat and resolver use same file but
different keys to store last updated timestamp (for me due unknown reasons, but
I guess is to keep their "update cadence" completely separated).
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728873#comment-17728873
]
Garret Wilson edited comment on MNG-7802 at 6/2/23 9:58 PM:
I'll try to stay out of this discussion because I don't have time to dig into
the deep Maven code internals right now, but I wanted to clarify [something
said
above|https://issues.apache.org/jira/browse/MNG-7802?focusedCommentId=17728840=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17728840]
to put this into context:
{quote}As discovered during lengthy MRESOLVER-363 (and related
https://github.com/mojohaus/versions/issues/959 TLDR; user had corrupted local
repo, so "last update" for he's metadata was Jan 1 1970 but Maven did not
update (showed new version), as policy for central is "never"! Only -U helps,
that not only did pull updates but "fixed" the corruption in local repo as
well){quote}
I disagree that my local repository was "corrupted". Maybe Maven Resolver
didn't understand it, but it wasn't corrupted. My
{{resolver-status.properties}} file was a completely valid properties file with
this content:
{code}
#Last modified on: Thu Sep 08 15:34:35 PDT 2022
#Thu Sep 08 15:34:35 PDT 2022
central.maven-metadata-central.xml.lastUpdated=1662676475074
{code}
The fact that Maven Resolver decided to interpret this as "Jan 1 1970" is a
decision Maven Resolver made. This file doesn't say "Jan 1 1970", it says
2022-09-08.
I was told that Maven Resolver recognizes a different property than
{{central.maven-metadata-central.xml.lastUpdated}}. Still nothing told Maven
Resolver "Jan 1 1970". Instead, Maven Resolver took it upon itself to say, "I
see that you wanted to indicate when you were updated, but I don't understand
it, so I'm never, ever going to update this file."
Additionally we have to ask where
{{central.maven-metadata-central.xml.lastUpdated}} came from in the first
place. Somebody in [Versions Maven Plugin
#959|https://github.com/mojohaus/versions/issues/959] said it might have come
from some [Maven Compatibility
Layer|https://maven.apache.org/ref/3.9.2/maven-compat/]. I haven't looked into
this to find out the details, but if Maven Resolver doesn't know how to work
with data from the Maven Compatibility Layer, then … shouldn't it? My point is
that there is no "corruption" here. Everything worked as normal based upon some
set of tools, and Maven Resolver just wasn't in the loop on what to expect with
what something else wrote.
You and I as humans can look at the file above and figure out what was
intended. There is zero ambiguity in the file about what the last updated
timestamp should be. The file is 100% machine processable. Shouldn't there be
some way to improve Maven Resolver to figure that out as well?
I realize this ticket deals with complicated policy beyond this particular
issue, so I'll go back into lurk mode for this ticket and let all of you
discuss it. I just wanted to clarify that part. Have a wonderful weekend.
was (Author: garretwilson):
I'll try to stay out of this discussion because I don't have time to dig into
the deep Maven code internals right now, but I wanted to clarify [something
said
above|https://issues.apache.org/jira/browse/MNG-7802?focusedCommentId=17728840=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17728840]
to put this into context:
{quote}As discovered during lengthy MRESOLVER-363 (and related
https://github.com/mojohaus/versions/issues/959 TLDR; user had corrupted local
repo, so "last update" for he's metadata was Jan 1 1970 but Maven did not
update (showed new version), as policy for central is "never"! Only -U helps,
that not only did pull updates but "fixed" the corruption in local repo as
well){quote}
I disagree that my local repository was "corrupted". Maybe Maven Resolver
didn't understand it, but it wasn't corrupted. My
{{resolver-status.properties}} file was a completely valid properties file with
this content:
{code}
#Last modified on: Thu Sep 08 15:34:35 PDT 2022
#Thu Sep 08 15:34:35 PDT 2022
central.maven-metadata-central.xml.lastUpdated=1662676475074
{code}
The fact that Maven Resolver decided to interpret this as "Jan 1 1970" is a
decision Maven Resolver made. This file doesn't say "Jan 1 1970", it says
2022-09-08.
I was told that Maven Resolver recognizes a different property than
{{central.maven-metadata-central.xml.lastUpdated}}. Still nothing told Maven
Resolver "Jan 1 1970". Instead, Maven Resolver took it upon itself to say, "I
see that you wanted to indicate when you were updated, but I don't understand
it, so I'm never, ever going to update this file."
Additionally we have to ask where
{{central.maven-metadata-central.xml.lastUpdated}} came from in the first
place. Somebody in [Versions Maven Plugin
#959|https://github.com/mojohaus/versions/issues/959]
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728873#comment-17728873
]
Garret Wilson commented on MNG-7802:
I'll try to stay out of this discussion because I don't have time to dig into
the deep Maven code internals right now, but I wanted to clarify [something
said
above|https://issues.apache.org/jira/browse/MNG-7802?focusedCommentId=17728840=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17728840]
to put this into context:
{quote}As discovered during lengthy MRESOLVER-363 (and related
https://github.com/mojohaus/versions/issues/959 TLDR; user had corrupted local
repo, so "last update" for he's metadata was Jan 1 1970 but Maven did not
update (showed new version), as policy for central is "never"! Only -U helps,
that not only did pull updates but "fixed" the corruption in local repo as
well){quote}
I disagree that my local repository was "corrupted". Maybe Maven Resolver
didn't understand it, but it wasn't corrupted. My
{{resolver-status.properties}} file was a completely valid properties file with
this content:
{code}
#Last modified on: Thu Sep 08 15:34:35 PDT 2022
#Thu Sep 08 15:34:35 PDT 2022
central.maven-metadata-central.xml.lastUpdated=1662676475074
{code}
The fact that Maven Resolver decided to interpret this as "Jan 1 1970" is a
decision Maven Resolver made. This file doesn't say "Jan 1 1970", it says
2022-09-08.
I was told that Maven Resolver recognizes a different property than
{{central.maven-metadata-central.xml.lastUpdated}}. Still nothing told Maven
Resolver "Jan 1 1970". Instead, Maven Resolver took it upon itself to say, "I
see that you wanted to indicate when you were updated, but I don't understand
it, so I'm never, ever going to update this file."
Additionally we have to ask where
{{central.maven-metadata-central.xml.lastUpdated}} came from in the first
place. Somebody in [Versions Maven Plugin
#959|https://github.com/mojohaus/versions/issues/959] said it might have come
from some [Maven Compatibility
Layer|https://maven.apache.org/ref/3.9.2/maven-compat/]. I haven't looked into
this to find out the details, but if Maven Resolver doesn't know how to work
with data from the Maven Compatibility Layer, then … shouldn't it? My point is
that there is no "corruption" here. Everything worked as normal based upon some
set of tools, and Maven Resolver just wasn't in the loop on what to expect with
what something else wrote.
You and I as humans can look at the file above and figure out what was
intended. There is zero ambiguity in the file about what the last updated
timestamp should be. The file is 100% machine processable. Shouldn't there be
some way to improve Maven Resolver to figure that out as well?
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak edited comment on MNG-7803 at 6/2/23 8:32 PM:
--
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => set session level policy "always" (as today)
* -nu "never update" => set session level policy "never" (as today)
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above, so point is this sets session level
policy
BUT:
* and add a resolver config and code change (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like -fu in maven 4 would result in same
behavior as -U is in Maven3 today. Also, setting "daily" policy would affect
only metadata, no artifact check would happen.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
was (Author: cstamas):
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => set session level policy "always" (as today)
* -nu "never update" => set session level policy "never" (as today)
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above, so point is this sets session level
policy
BUT:
* and add a resolver config and code change (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like -fu in maven 4 would result in same
behavior as -U is in Maven3 today. Also, setting "daily" policy would affect
only metadata, no artifact check would happen.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak edited comment on MNG-7803 at 6/2/23 8:32 PM:
--
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => set session level policy "always" (as today)
* -nu "never update" => set session level policy "never" (as today)
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above, so point is this sets session level
policy
BUT:
* and add a resolver config and code change (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like -fu in maven 4 would result in same
behavior as -U is in Maven3 today. Also, setting "daily" policy would affect
only metadata, no artifact check would happen.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery. Kinda a "weaker" -U.
was (Author: cstamas):
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => set session level policy "always" (as today)
* -nu "never update" => set session level policy "never" (as today)
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above, so point is this sets session level
policy
BUT:
* and add a resolver config and code change (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like -fu in maven 4 would result in same
behavior as -U is in Maven3 today. Also, setting "daily" policy would affect
only metadata, no artifact check would happen.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak edited comment on MNG-7803 at 6/2/23 8:32 PM:
--
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => set session level policy "always" (as today)
* -nu "never update" => set session level policy "never" (as today)
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above, so point is this sets session level
policy
BUT:
* and add a resolver config and code change (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like -fu in maven 4 would result in same
behavior as -U is in Maven3 today. Also, setting "daily" policy would affect
only metadata, no artifact check would happen.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
was (Author: cstamas):
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => set session level policy "always" (as today)
* -nu "never update" => set session level policy "never" (as today)
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above, so point is this sets session level
policy
BUT:
* and add a resolver config and code change (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like -fu in maven 4 would result in same
behavior as -U is in Maven3 today.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak edited comment on MNG-7803 at 6/2/23 8:31 PM:
--
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => set session level policy "always" (as today)
* -nu "never update" => set session level policy "never" (as today)
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above, so point is this sets session level
policy
BUT:
* and add a resolver config and code change (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like -fu in maven 4 would result in same
behavior as -U is in Maven3 today.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
was (Author: cstamas):
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => so set session level policy "always"
* -nu "never update" => set session level policy "never"
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above, so point is this sets session level
policy
* and add a resolver config and code change (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like -fu in maven 4 would result in same
behavior as -U is in Maven3 today.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728840#comment-17728840
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 8:27 PM:
--
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF non-null, session overrides everything, IF null,
remoteRepository policy is applied.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is CORRECT:
* -U present? set session to ALWAYS
* -nsu present? set session to NEVER
* otherwise leave it null (leave to remote repository policy to decide)
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
... {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central and release repositories
mostly:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps, that not only did pull updates but "fixed" the
corruption in local repo as well)
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
* user added repositories MAY or MAY NOT have set policies (users usually set
them on snapshot repositories), so similar applies
* ultimately: since Maven 3 (timestamped snapshots supported only) I kinda
feel that "update policy" should be applied to metadata ONLY, as if you think
about, all the artifacts (release or snapshot) are de facto immutable (in
maven2 world, when remote repositories allowed foo-1.0-SNAPSHOT.jar, those were
NOT immutable, and had to be updated using usual means, ie. conditional GETs)
was (Author: cstamas):
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF non-null, session overrides everything, IF null,
remoteRepository policy is applied.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is CORRECT:
* -U present? set session to ALWAYS
* -nsu present? set session to NEVER
* otherwise leave it to remote repositories (their policies) to decide
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
... {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central and release repositories
mostly:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this
[jira] [Comment Edited] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak edited comment on MNG-7803 at 6/2/23 8:25 PM:
--
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => so set session level policy "always"
* -nu "never update" => set session level policy "never"
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above, so point is this sets session level
policy
* and add a resolver config and code change (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like -fu in maven 4 would result in same
behavior as -U is in Maven3 today.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
was (Author: cstamas):
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => so set session level policy "always"
* -nu "never update" => set session level policy "never"
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above, so point is this sets session level
policy
* and add a resolver config and code change (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like \{{-fu }}in maven 4 would result as -U is
in Maven3 today.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak edited comment on MNG-7803 at 6/2/23 8:23 PM:
--
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => so set session level policy "always"
* -nu "never update" => set session level policy "never"
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above, so point is this sets session level
policy
* and add a resolver config and code change (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like \{{-fu }}in maven 4 would result as -U is
in Maven3 today.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
was (Author: cstamas):
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like {{-fu }}in maven 4 would result as -U is in
Maven3 today.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak edited comment on MNG-7803 at 6/2/23 8:21 PM:
--
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like {{-au
-Daether.updateCheckManager.applyPolicy=all}} in maven 4 would result as -U is
in Maven3 today.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
was (Author: cstamas):
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
This would mean, that CLI line like {{-au
-Daether.updateCheckManager.applyPolicy=all}} in maven 4 would result as -U is
in Maven3 today.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak edited comment on MNG-7803 at 6/2/23 8:21 PM:
--
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like {{-fu }}in maven 4 would result as -U is in
Maven3 today.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
was (Author: cstamas):
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
* maybe add -fu as well that would be equivalent of CLI -au
-Daether.updateCheckManager.applyPolicy=all ? (like force update, for
"remembered" transport failures)
This would mean, that CLI line like {{-au
-Daether.updateCheckManager.applyPolicy=all}} in maven 4 would result as -U is
in Maven3 today.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-369) Expose configuration for update check manager where to apply policy
[
https://issues.apache.org/jira/browse/MRESOLVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-369:
--
Description:
Currently, DefaultUpdateCheckManager ALWAYS applies policy to both, artifacts
and metadata. This causes problems when we want to "discover new versions" (or
similar use case, that relies on fresh metadata), but metadata is never updated
due remote repository update policy of "never", so only -U make it work as
expected. -U OTOH is like shooting with cannon onto bird, as it updates many
many more as well, not only the one metadata we are interested in.
Moreover, since Maven3 artifacts are immutable.
So, add a config like {{aether.updateCheckManager.applyUpdatePolicy}} that
accepts values "all" (like today) and "metadata" (does not applies policy to
artifacts, if artifact present, no update needed).
was:
Currently, DefaultUpdateCheckManager ALWAYS applies policy to both, artifacts
and metadata. This causes problems when we want to "discover new versions" (or
similar use case, that relies on fresh metadata), but metadata is never updated
due remote repository update policy of "never", so only -U make it work as
expected. -U OTOH is like shooting with cannon onto bird, as it updates many
many more as well, not only the one metadata we are interested in.
Moreover, since Maven3 artifacts are immutable.
So, add a config like {{aether.updateCheckManager.applyUpdatePolicy}} that
accepts values "all" (like today) and "metadata" (does not applies policy to
artifacts, if present, no update needed).
> Expose configuration for update check manager where to apply policy
> ---
>
> Key: MRESOLVER-369
> URL: https://issues.apache.org/jira/browse/MRESOLVER-369
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> Currently, DefaultUpdateCheckManager ALWAYS applies policy to both, artifacts
> and metadata. This causes problems when we want to "discover new versions"
> (or similar use case, that relies on fresh metadata), but metadata is never
> updated due remote repository update policy of "never", so only -U make it
> work as expected. -U OTOH is like shooting with cannon onto bird, as it
> updates many many more as well, not only the one metadata we are interested
> in.
> Moreover, since Maven3 artifacts are immutable.
> So, add a config like {{aether.updateCheckManager.applyUpdatePolicy}} that
> accepts values "all" (like today) and "metadata" (does not applies policy to
> artifacts, if artifact present, no update needed).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-369) Expose configuration for update check manager where to apply policy
[
https://issues.apache.org/jira/browse/MRESOLVER-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-369:
--
Description:
Currently, DefaultUpdateCheckManager ALWAYS applies policy to both, artifacts
and metadata. This causes problems when we want to "discover new versions" (or
similar use case, that relies on fresh metadata), but metadata is never updated
due remote repository update policy of "never", so only -U make it work as
expected. -U OTOH is like shooting with cannon onto bird, as it updates many
many more as well, not only the one metadata we are interested in.
Moreover, since Maven3 artifacts are immutable.
So, add a config like {{aether.updateCheckManager.applyUpdatePolicy}} that
accepts values "all" (like today) and "metadata" (does not applies policy to
artifacts, if present, no update needed).
was:
Currently, DefaultUpdateCheckManager ALWAYS applies policy to both, artifacts
and metadata. This causes problems when we want to "discover new versions" (or
similar use case, that relies on fresh metadata), but metadata is never updated
due remote repository update policy of "never", so only -U make it work as
expected. -U OTOH is like shooting with cannon onto bird, as it updates many
many more as well, not only the one metadata we are interested in.
Moreover, since Maven3 artifacts are immutable.
So, add a config like {{aether.updateCheckManager.applyUpdatePolicy}} that
accepts values "all" (like today) and "metadata" (does not applies policy to
artifacts, if present, all is cool).
> Expose configuration for update check manager where to apply policy
> ---
>
> Key: MRESOLVER-369
> URL: https://issues.apache.org/jira/browse/MRESOLVER-369
> Project: Maven Resolver
> Issue Type: New Feature
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
>
> Currently, DefaultUpdateCheckManager ALWAYS applies policy to both, artifacts
> and metadata. This causes problems when we want to "discover new versions"
> (or similar use case, that relies on fresh metadata), but metadata is never
> updated due remote repository update policy of "never", so only -U make it
> work as expected. -U OTOH is like shooting with cannon onto bird, as it
> updates many many more as well, not only the one metadata we are interested
> in.
> Moreover, since Maven3 artifacts are immutable.
> So, add a config like {{aether.updateCheckManager.applyUpdatePolicy}} that
> accepts values "all" (like today) and "metadata" (does not applies policy to
> artifacts, if present, no update needed).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-369) Expose configuration for update check manager where to apply policy
Tamas Cservenak created MRESOLVER-369:
-
Summary: Expose configuration for update check manager where to
apply policy
Key: MRESOLVER-369
URL: https://issues.apache.org/jira/browse/MRESOLVER-369
Project: Maven Resolver
Issue Type: New Feature
Components: Resolver
Reporter: Tamas Cservenak
Currently, DefaultUpdateCheckManager ALWAYS applies policy to both, artifacts
and metadata. This causes problems when we want to "discover new versions" (or
similar use case, that relies on fresh metadata), but metadata is never updated
due remote repository update policy of "never", so only -U make it work as
expected. -U OTOH is like shooting with cannon onto bird, as it updates many
many more as well, not only the one metadata we are interested in.
Moreover, since Maven3 artifacts are immutable.
So, add a config like {{aether.updateCheckManager.applyUpdatePolicy}} that
accepts values "all" (like today) and "metadata" (does not applies policy to
artifacts, if present, all is cool).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak edited comment on MNG-7803 at 6/2/23 8:12 PM:
--
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
This would mean, that CLI line like {{-au
-Daether.updateCheckManager.applyPolicy=all}} in maven 4 would result as -U is
in Maven3 today.
Without resolver config, only {{-au}} would achieve exactly what we want, as
resolver would default to "metadata" only, so "always update metadata" that is
what we really want with version discovery.
was (Author: cstamas):
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
This would mean, that CLI line like {{-au
-Daether.updateCheckManager.applyPolicy=all}} in maven 4 would result as -U is
in Maven3 today.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak edited comment on MNG-7803 at 6/2/23 8:11 PM:
--
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* alternative, maybe simpler {{-u}} that may accept policy "always", "never"
so make {{-u=always}} same as -au above
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
This would mean, that CLI line like {{-au
-Daether.updateCheckManager.applyPolicy=all}} in maven 4 would result as -U is
in Maven3 today.
was (Author: cstamas):
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
This would mean, that CLI line like {{-au
-Daether.updateCheckManager.applyPolicy=all}} in maven 4 would result as -U is
in Maven3 today.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak edited comment on MNG-7803 at 6/2/23 8:09 PM:
--
I'd deprecate the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
This would mean, that CLI line like {{-au
-Daether.updateCheckManager.applyPolicy=all}} in maven 4 would result as -U is
in Maven3 today.
was (Author: cstamas):
I'd deprecated the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
This would mean, that CLI line like {{-au
-Daether.updateCheckManager.applyPolicy=all}} in maven 4 would result as -U is
in Maven3 today.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak edited comment on MNG-7803 at 6/2/23 8:07 PM:
--
I'd deprecated the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Text for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
This would mean, that CLI line like {{-au
-Daether.updateCheckManager.applyPolicy=all}} in maven 4 would result as -U is
in Maven3 today.
was (Author: cstamas):
I'd deprecated the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Thext for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
This would mean, that CLI line like {{-au
-Daether.updateCheckManager.applyPolicy=all}} in maven 4 would result as -U is
in Maven3 today.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728860#comment-17728860
]
Tamas Cservenak commented on MNG-7803:
--
I'd deprecated the existing ones (emit warning and all that).
{noformat}
-nsu,--no-snapshot-updates Suppress SNAPSHOT updates
-U,--update-snapshots Forces a check for missing
releases and updated snapshots on
remote repositories {noformat}
Thext for -nsu is totally off (should be "Supress ANY updates"), while -U is
kinda conflicting with {{updatesnapshots}} as "forces check for missing
releases"?
Instead, introduce:
* -au "always update" => behave as -U today (in maven, so set session level
policy "always")
* -nu "never update" => behave as -nsu today (in maven, so set session level
policy "never")
* and add a resolver config (new, for example
{{{}aether.updateCheckManager.applyPolicy{}}}) that controls whether is update
policy applied to "all" (artifact and metadata, as today) or "metadata" only
(default to "metadata")
This would mean, that CLI line like {{-au
-Daether.updateCheckManager.applyPolicy=all}} in maven 4 would result as -U is
in Maven3 today.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728846#comment-17728846
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:52 PM:
--
Explanation of artifact immutability: since Maven3 there should be no artifact
(POM, JAR, ZIP, ...), addressable by GAV, that once downloaded, can change
afterwards on remote repository.
* in release repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files effectively never change and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Consequence related to reproducible builds: due this, if build contains no
snapshot version, the artifacts used (any artifact, so plugins, parent POMs,
dependencies, etc) in build are ALWAYS same. This obviously does not stand for
build containing snapshot versions, as the {{-SNAPSHOT}} version in POM may
resolve to different timestamped artifacts, hence, without POM change the used
artifacts MAY change, hence "moving target".
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE artifact files as well (but this effectively never happens).
This is basically part of legacy from Maven2 and transition, where
non-timestamped snapshots had to be supported by Maven3. We need to decide
should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
was (Author: cstamas):
Explanation of artifact immutability: since Maven3 there should be no artifact
(POM, JAR, ZIP, ...), addressable by GAV, that once downloaded, can change
afterwards on remote repository.
* in release repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files effectively never change and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE artifact files as well (but this effectively never happens).
This is basically part of legacy from Maven2 and transition, where
non-timestamped snapshots had to be supported by Maven3. We need to decide
should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728846#comment-17728846
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:48 PM:
--
Explanation of artifact immutability: since Maven3 there should be no artifact
(POM, JAR, ZIP, ...), addressable by GAV, that once downloaded, can change
afterwards on remote repository.
* in release repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files effectively never change and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE artifact files as well (but this effectively never happens).
This is basically part of legacy from Maven2 and transition, where
non-timestamped snapshots had to be supported by Maven3. We need to decide
should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
was (Author: cstamas):
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in release repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files effectively never change and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE artifact files as well (but this effectively never happens).
This is basically part of legacy from Maven2 and transition, where
non-timestamped snapshots had to be supported by Maven3. We need to decide
should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728846#comment-17728846
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:43 PM:
--
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in release repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files effectively never change and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE artifact files as well (but this effectively never happens).
This is basically part of legacy from Maven2 and transition, where
non-timestamped snapshots had to be supported by Maven3. We need to decide
should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
was (Author: cstamas):
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in release repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files effectively never change and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE immutable files as well. This is basically part of legacy from
Maven2 and transition, where non-timestamped snapshots had to be supported by
Maven3. We need to decide should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728846#comment-17728846
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:42 PM:
--
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in release repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files effectively never change and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE immutable files as well. This is basically part of legacy from
Maven2 and transition, where non-timestamped snapshots had to be supported by
Maven3. We need to decide should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
was (Author: cstamas):
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in release repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files never and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE immutable files as well. This is basically part of legacy from
Maven2 and transition, where non-timestamped snapshots had to be supported by
Maven3. We need to decide should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728846#comment-17728846
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:41 PM:
--
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in release repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files never and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE immutable files as well. This is basically part of legacy from
Maven2 and transition, where non-timestamped snapshots had to be supported by
Maven3. We need to decide should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
was (Author: cstamas):
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in releases repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files never and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE immutable files as well. This is basically part of legacy from
Maven2 and transition, where non-timestamped snapshots had to be supported by
Maven3. We need to decide should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728840#comment-17728840
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:39 PM:
--
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF non-null, session overrides everything, IF null,
remoteRepository policy is applied.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is CORRECT:
* -U present? set session to ALWAYS
* -nsu present? set session to NEVER
* otherwise leave it to remote repositories (their policies) to decide
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
... {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central and release repositories
mostly:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps, that not only did pull updates but "fixed" the
corruption in local repo as well)
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
* user added repositories MAY or MAY NOT have set policies (users usually set
them on snapshot repositories), so similar applies
* ultimately: since Maven 3 (timestamped snapshots supported only) I kinda
feel that "update policy" should be applied to metadata ONLY, as if you think
about, all the artifacts (release or snapshot) are de facto immutable (in
maven2 world, when remote repositories allowed foo-1.0-SNAPSHOT.jar, those were
NOT immutable, and had to be updated using usual means, ie. conditional GETs)
was (Author: cstamas):
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF non-null, session overrides everything, IF null,
remoteRepository policy is applied.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is CORRECT:
* -U present? set session to ALWAYS
* -nsu present? set session to NEVER
* otherwise leave it to remote repositories (their policies) to decide
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
... {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728840#comment-17728840
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:38 PM:
--
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF non-null, session overrides everything, IF null,
remoteRepository policy is applied.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is CORRECT:
* -U present? set session to ALWAYS
* -nsu present? set session to NEVER
* otherwise leave it to remote repositories (their policies) to decide
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
... {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps, that not only did pull updates but "fixed" the
corruption in local repo as well)
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
* user added repositories MAY or MAY NOT have set policies (users usually set
them on snapshot repositories), so similar applies
* ultimately: since Maven 3 (timestamped snapshots supported only) I kinda
feel that "update policy" should be applied to metadata ONLY, as if you think
about, all the artifacts (release or snapshot) are de facto immutable (in
maven2 world, when remote repositories allowed foo-1.0-SNAPSHOT.jar, those were
NOT immutable, and had to be updated using usual means, ie. conditional GETs)
was (Author: cstamas):
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF non-null, session overrides everything, IF null,
remoteRepository policy is applied.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is CORRECT:
* -U present? set session to ALWAYS
* -nsu present? set session to NEVER
* otherwise leave it to remote repositories (their policies) to decide
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728846#comment-17728846
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:36 PM:
--
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in releases repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files never and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
Note: resolver and maven in this very moment is "prepared" and has "all the
infra" to UPDATE immutable files as well. This is basically part of legacy from
Maven2 and transition, where non-timestamped snapshots had to be supported by
Maven3. We need to decide should we keep this "super power" or simply drop it.
If we drop, solution becomes nearly trivial:
* artifacts are not to be updated at all, they can be "present" or "absent".
If present, fine, if absent, fetch them and make them "present".
* metadata should be updated => policy should become applicable to metadata
ONLY
In this case "never" (as value and especially as default value) makes no sense,
then default value might be "daily".
If we want to stick with this "superpower" to update artifacts, then:
* we may consider to split policies into artifactPolicy and metadataPolicy,
but this is not so trivial
was (Author: cstamas):
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in releases repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files never and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728846#comment-17728846
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:28 PM:
--
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in releases repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
Artifacts are "input" from users, like dependencies, plugins, parent POMs etc
(all addressable as GAV). Once an artifact is downloaded (implies checksum
validation, again, according to checksum policy – sadly warn is default),
resolver considers locally present file as "valid" file. Due that above
(immutability), these files never and cannot change.
Explanation for metadata: these files are NOT addressable by users, and
resolver handles them opaquely to obtain information depending on resolver use
case. They ARE stored on same URIs in remote repository and DO change, hence
"change detection" in form of policy + conditional GETs (or similar mechanism)
is a must.
was (Author: cstamas):
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in releases repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728846#comment-17728846
]
Tamas Cservenak commented on MNG-7802:
--
Explanation of artifact immutability: since Maven3 there is no "artifact" (POM,
JAR or ZIP or whatever, addressable by GAV) that once downloaded, could change
on remote repository.
* in releases repositories no "redeploy" should be possible
* in snapshot repositories effectively no redeploy can happen (as timestamp
and build No will change per deploy)
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728840#comment-17728840
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:07 PM:
--
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF non-null, session overrides everything, IF null,
remoteRepository policy is applied.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is CORRECT:
* -U present? set session to ALWAYS
* -nsu present? set session to NEVER
* otherwise leave it to remote repositories (their policies) to decide
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps, that not only did pull updates but "fixed" the
corruption in local repo as well)
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
* user added repositories MAY or MAY NOT have set policies (users usually set
them on snapshot repositories), so similar applies
* ultimately: since Maven 3 (timestamped snapshots supported only) I kinda
feel that "update policy" should be applied to metadata ONLY, as if you think
about, all the artifacts (release or snapshot) are de facto immutable (in
maven2 world, when remote repositories allowed foo-1.0-SNAPSHOT.jar, those were
NOT immutable, and had to be updated using usual means, ie. conditional GETs)
was (Author: cstamas):
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF non-null, session overrides everything, IF null,
remoteRepository policy is applied.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is CORRECT:
* -U present? set session to ALWAYS
* -nsu present? set session to NEVER
* otherwise leave it to remote repositories (their policies) to decide
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728840#comment-17728840
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:04 PM:
--
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF non-null, session overrides everything, IF null,
remoteRepository policy is applied.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is CORRECT:
* -U present? set session to ALWAYS
* -nsu present? set session to NEVER
* otherwise leave it to remote repositories (their policies) to decide
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps )
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
* user added repositories MAY or MAY NOT have set policies (users usually set
them on snapshot repositories), so similar applies
* ultimately: since Maven 3 (timestamped snapshots supported only) I kinda
feel that "update policy" should be applied to metadata ONLY, as if you think
about, all the artifacts (release or snapshot) are de facto immutable (in
maven2 world, when remote repositories allowed foo-1.0-SNAPSHOT.jar, those were
NOT immutable, and had to be updated using usual means, ie. conditional GETs)
was (Author: cstamas):
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy decide).
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728840#comment-17728840
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 7:01 PM:
--
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy decide).
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never" (when value is not set)
* central repo default value for update policy = "never" (as set in Maven)
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps )
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
* user added repositories MAY or MAY NOT have set policies (users usually set
them on snapshot repositories), so similar applies
* ultimately: since Maven 3 (timestamped snapshots supported only) I kinda
feel that "update policy" should be applied to metadata ONLY, as if you think
about, all the artifacts (release or snapshot) are de facto immutable (in
maven2 world, when remote repositories allowed foo-1.0-SNAPSHOT.jar, those were
NOT immutable, and had to be updated using usual means, ie. conditional GETs)
was (Author: cstamas):
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy decide).
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never"
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728840#comment-17728840
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 6:56 PM:
--
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy decide).
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never"
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps )
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
* user added repositories MAY or MAY NOT have set policies (users usually set
them on snapshot repositories), so similar applies
* ultimately: since Maven 3 (timestamped snapshots supported only) I kinda
feel that "update policy" should be applied to metadata ONLY, as if you think
about, all the artifacts (release or snapshot) are de facto immutable (in
maven2 world, when remote repositories allowed foo-1.0-SNAPSHOT.jar, those were
NOT immutable, and had to be updated using usual means, ie. conditional GETs)
was (Author: cstamas):
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy decide).
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never"
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728840#comment-17728840
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 6:55 PM:
--
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy decide).
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never"
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps )
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
* user added repositories MAY or MAY NOT have set policies (users usually set
them on snapshot repositories), so similar applies
* ultimately: since Maven 3 (timestamped snapshots supported only) I kinda
feel that "update policy" should be applied to metadata ONLY, as if you think
about, all the artifacts (release or snapshot) are de facto immutable (in
maven2 world, when remote repositories allowed foo-1.0-SNAPSHOT.jar, those were
NOT immutable)
was (Author: cstamas):
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy decide).
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never"
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728840#comment-17728840
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 6:55 PM:
--
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy decide).
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never"
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps )
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
* user added repositories MAY or MAY NOT have set policies (users usually set
them on snapshot repositories), so similar applies
* ultimately: since Maven 3 (timestamped snapshots allowed only) I kinda feel
that "update policy" should be applied to metadata ONLY, as if you think about,
all the artifacts (release or snapshot) are de factor immutable (in maven2
world, when remote repositories allowed foo-1.0-SNAPSHOT.jar, those were NOT
immutable)
was (Author: cstamas):
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy decide).
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never"
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
[jira] [Comment Edited] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728840#comment-17728840
]
Tamas Cservenak edited comment on MNG-7802 at 6/2/23 6:55 PM:
--
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy decide).
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never"
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps )
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
* user added repositories MAY or MAY NOT have set policies (users usually set
them on snapshot repositories), so similar applies
* ultimately: since Maven 3 (timestamped snapshots supported only) I kinda
feel that "update policy" should be applied to metadata ONLY, as if you think
about, all the artifacts (release or snapshot) are de factor immutable (in
maven2 world, when remote repositories allowed foo-1.0-SNAPSHOT.jar, those were
NOT immutable)
was (Author: cstamas):
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy decide).
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never"
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728840#comment-17728840
]
Tamas Cservenak commented on MNG-7802:
--
I retract my comment above, does not looks good. Here is what happens:
session.UpdatePolicy == IF null, remoteRepository policy is applied, IF
non-null, session overrides always.
So, what happens in maven-core DefaultRepositorySystemSessionFactory is
CORRECT(-U present? ALWAYS, -nsu present? NEVER, otherwise null => let the repo
policy decide).
Other question is like "why are they named like this" and how is this possible:
{noformat}
[cstamas@blondie maven (maven-3.9.x)]$ mvn -U -nsu clean
[INFO] Scanning for projects...
[INFO {noformat}
(so what happens now? both options given, but Maven does not nags about nothing)
But this is more for MNG-7803 (change help text and add some validation maybe?)
IMHO, problems for this issue are following:
* default value for update policy = "never"
* "en gros" application of policy (irrelevant is it "global", from session or
"local", from remote repo) to both, artifacts and metadata
Default value affects "built in" repository central only:
* if we set "never" as today, things like versions:display-plugin-updates and
alike (version resolution) will only work with -U, and this is the reason why
everyone on earth uses this plugin with -U
* if we set to "daily", it will make Maven perform conditional GETs for
release artifacts in central (that are immutable) => wasteful nonsense
Note: "never" policy and versions plugin has been addressed with a hack:
[https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e]
BUT IMHO this is not a solution, as every other Mojo relying on version
resolution is forced to do the same thing!
And here we arrive to 2nd problem: "en gros" application of policy to both,
artifacts and metadata.
As discovered during lengthy MRESOLVER-363 (and related
[https://github.com/mojohaus/versions/issues/959|https://github.com/mojohaus/versions/issues/959)]
TLDR; user had corrupted local repo, so "last update" for he's metadata was
Jan 1 1970 but Maven did not update (showed new version), as policy for central
is "never"! Only -U helps )
* central with "never" policy causes that central "show me updates" use cases
(versions:display-xxx-updates) does not work as expected without -U
* problem was not artifact, but metadata update, and in some sense, resolver
was right: did not update, as policy of central is "never"
* resolver distinguish (and have separate exec paths for artifacts and
metadata) but applies SAME policy (that configured in remote repository) to
BOTH
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728838#comment-17728838
]
ASF GitHub Bot commented on MNG-7802:
-
cstamas commented on PR #1144:
URL: https://github.com/apache/maven/pull/1144#issuecomment-1574131188
Looks good, but:
* the CLI `-U` should be changed (not snapshot update but all update, I mean
change the help text)
* as IT failures show, IF `-U` present, do what happened before (stick
ALWAYS to session), if not present, do partially what in PR
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] cstamas commented on pull request #1144: [MNG-7802] Fix behaviour of the maven update policy
cstamas commented on PR #1144: URL: https://github.com/apache/maven/pull/1144#issuecomment-1574131188 Looks good, but: * the CLI `-U` should be changed (not snapshot update but all update, I mean change the help text) * as IT failures show, IF `-U` present, do what happened before (stick ALWAYS to session), if not present, do partially what in PR -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-apache-parent] hgschmie commented on pull request #155: [MPOM-289] Use properties to define the versions of plugins
hgschmie commented on PR #155: URL: https://github.com/apache/maven-apache-parent/pull/155#issuecomment-1574110897 I use `dep.plugin..version` properties for a very long time: https://github.com/basepom/basepom/blob/main/poms/foundation/pom.xml#L236-L243 Using a hierarchical naming scheme gives you an opportunity to sort those (e.g. with the sortpom plugin - https://github.com/Ekryd/sortpom) and not have the versions strewn all over the place (the names all align on `dep.plugin` first). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728809#comment-17728809 ] ASF GitHub Bot commented on MNG-6112: - gnodet commented on code in PR #1142: URL: https://github.com/apache/maven/pull/1142#discussion_r1214558907 ## apache-maven/src/assembly/maven/conf/settings.xml: ## @@ -257,9 +286,11 @@ under the License. Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte >Assignee: Robert Scholte >Priority: Major > Labels: must-be-in-4.0.0-alpha-2 > Fix For: 4.0.x-candidate > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1142: [MNG-6112] Make central update policy coherent
gnodet commented on code in PR #1142: URL: https://github.com/apache/maven/pull/1142#discussion_r1214558907 ## apache-maven/src/assembly/maven/conf/settings.xml: ## @@ -257,9 +286,11 @@ under the License. -alwaysActiveProfile -anotherAlwaysActiveProfile +maven:core:central-repo Review Comment: So this PR is based on #1139, please check only commit https://github.com/apache/maven/pull/1142/commits/04268f9dd323dd31630a55004ee4ca10e412c360 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728807#comment-17728807 ] ASF GitHub Bot commented on MNG-6112: - gnodet commented on code in PR #1142: URL: https://github.com/apache/maven/pull/1142#discussion_r1214558907 ## apache-maven/src/assembly/maven/conf/settings.xml: ## @@ -257,9 +286,11 @@ under the License. Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte >Assignee: Robert Scholte >Priority: Major > Labels: must-be-in-4.0.0-alpha-2 > Fix For: 4.0.x-candidate > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1142: [MNG-6112] Make central update policy coherent
gnodet commented on code in PR #1142: URL: https://github.com/apache/maven/pull/1142#discussion_r1214558907 ## apache-maven/src/assembly/maven/conf/settings.xml: ## @@ -257,9 +286,11 @@ under the License. -alwaysActiveProfile -anotherAlwaysActiveProfile +maven:core:central-repo Review Comment: So this PR is based on #1139, please check only commit https://github.com/apache/maven/pull/1142/commits/1d7045dcf631926d3a6515bc8527d5e3241cc482 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728806#comment-17728806 ] ASF GitHub Bot commented on MNG-6112: - gnodet commented on code in PR #1142: URL: https://github.com/apache/maven/pull/1142#discussion_r1214556282 ## apache-maven/src/assembly/maven/conf/settings.xml: ## @@ -257,9 +286,11 @@ under the License. Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte >Assignee: Robert Scholte >Priority: Major > Labels: must-be-in-4.0.0-alpha-2 > Fix For: 4.0.x-candidate > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on a diff in pull request #1142: [MNG-6112] Make central update policy coherent
gnodet commented on code in PR #1142: URL: https://github.com/apache/maven/pull/1142#discussion_r1214556282 ## apache-maven/src/assembly/maven/conf/settings.xml: ## @@ -257,9 +286,11 @@ under the License. -alwaysActiveProfile -anotherAlwaysActiveProfile +maven:core:central-repo Review Comment: I need to revert that part, that comes from the original commit. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MNG-7803:
Assignee: Guillaume Nodet
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
[
https://issues.apache.org/jira/browse/MNG-7803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7803:
-
Description: The CLI options for {{-U}} and {{-nsu}} indicates that those
are for snapshots, while they actually affect version resolution, so those
should be renamed and their doc fixed.
> Deprecate -U and -nsu and provide correct options reflecting the real
> behaviour
> ---
>
> Key: MNG-7803
> URL: https://issues.apache.org/jira/browse/MNG-7803
> Project: Maven
> Issue Type: Improvement
>Reporter: Guillaume Nodet
>Priority: Major
>
> The CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect version resolution, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7802:
-
Description:
The update policy can be specified using the {{-U}} (force update) or {{-nsu}}
(no update) options, but those options change the whole repository session
policy and override any settings on the repositories.
This means that if {{-U}} is set, the resolver will attempt to check already
downloaded artifacts. This is wrong and the behaviour has been inherited from
maven 2.x.
What we really wants (and what's implied by the name of the options and docs)
is to check for new artifacts / updates, so this mainly affect _version
resolution_ and not {_}artifact resolution{_}.
was:
The update policy can be specified using the {{-U}} (force update) or {{-nsu}}
(no update) options, but those options change the whole repository session
policy and override any settings on the repositories.
This means that if {{-U}} is set, the resolver will attempt to check already
downloaded artifacts. This is wrong and the behaviour has been inherited from
maven 2.x.
What we really wants (and what's implied by the name of the options and docs)
is to check for new artifacts / updates, so this mainly affect _version
resolution_ and not {_}artifact resolution{_}.
Also, the CLI options for {{-U}} and {{-nsu}} indicates that those are for
snapshots, while they actually affect all policies, so those should be renamed
and their doc fixed.
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728804#comment-17728804 ] ASF GitHub Bot commented on MNG-6112: - slawekjaranowski commented on code in PR #1142: URL: https://github.com/apache/maven/pull/1142#discussion_r1214553840 ## apache-maven/src/assembly/maven/conf/settings.xml: ## @@ -257,9 +286,11 @@ under the License. Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte >Assignee: Robert Scholte >Priority: Major > Labels: must-be-in-4.0.0-alpha-2 > Fix For: 4.0.x-candidate > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7803) Deprecate -U and -nsu and provide correct options reflecting the real behaviour
Guillaume Nodet created MNG-7803: Summary: Deprecate -U and -nsu and provide correct options reflecting the real behaviour Key: MNG-7803 URL: https://issues.apache.org/jira/browse/MNG-7803 Project: Maven Issue Type: Improvement Reporter: Guillaume Nodet -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] slawekjaranowski commented on a diff in pull request #1142: [MNG-6112] Make central update policy coherent
slawekjaranowski commented on code in PR #1142: URL: https://github.com/apache/maven/pull/1142#discussion_r1214553840 ## apache-maven/src/assembly/maven/conf/settings.xml: ## @@ -257,9 +286,11 @@ under the License. -alwaysActiveProfile -anotherAlwaysActiveProfile +maven:core:central-repo Review Comment: Where is used? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728802#comment-17728802
]
ASF GitHub Bot commented on MNG-7802:
-
gnodet opened a new pull request, #1144:
URL: https://github.com/apache/maven/pull/1144
(no comment)
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
>
>
> Also, the CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect all policies, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7801) Clean doc for repositories policies
[
https://issues.apache.org/jira/browse/MNG-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728801#comment-17728801
]
ASF GitHub Bot commented on MNG-7801:
-
gnodet opened a new pull request, #1143:
URL: https://github.com/apache/maven/pull/1143
(no comment)
> Clean doc for repositories policies
> ---
>
> Key: MNG-7801
> URL: https://issues.apache.org/jira/browse/MNG-7801
> Project: Maven
> Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The model doc (and other) indicates that the default update policy is daily,
> but no value is set by default, and the resolver assumes {{never}} as a
> default (see
> [https://github.com/apache/maven-resolver/blob/97dfd1c2b9deb15734d5e401807e55cd0498332a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdatePolicyAnalyzer.java#L91)]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-6112) Central repository in the 4.0.0 super POM should declare update policy 'never'.
[ https://issues.apache.org/jira/browse/MNG-6112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728800#comment-17728800 ] ASF GitHub Bot commented on MNG-6112: - gnodet opened a new pull request, #1142: URL: https://github.com/apache/maven/pull/1142 - [MNG-4645] Move Central repo definition out of Maven's core so it can be more easily changed - [MNG-6112] Align artifacts and plugins policies using the default value > Central repository in the 4.0.0 super POM should declare update policy > 'never'. > --- > > Key: MNG-6112 > URL: https://issues.apache.org/jira/browse/MNG-6112 > Project: Maven > Issue Type: Bug >Affects Versions: 3.5.0-beta-1 >Reporter: Christian Schulte >Assignee: Robert Scholte >Priority: Major > Labels: must-be-in-4.0.0-alpha-2 > Fix For: 4.0.x-candidate > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet opened a new pull request, #1142: [MNG-6112] Make central update policy coherent
gnodet opened a new pull request, #1142: URL: https://github.com/apache/maven/pull/1142 - [MNG-4645] Move Central repo definition out of Maven's core so it can be more easily changed - [MNG-6112] Align artifacts and plugins policies using the default value -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-site] kwin commented on a diff in pull request #424: DRAFT Maven 3.9.3 Release notes
kwin commented on code in PR #424: URL: https://github.com/apache/maven-site/pull/424#discussion_r1214549527 ## content/markdown/docs/3.9.3/release-notes.md: ## @@ -0,0 +1,79 @@ + + +# Release Notes Maven 3.9.3 + +The Apache Maven team would like to announce the release of Maven 3.9.3. + +Maven 3.9.3 is [available for download][0]. + +Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting, and documentation from a central place. + +The core release is independent of plugin releases. Further releases of plugins will be made separately. See the [PluginList][1] for more information. + +If you have any questions, please consult: + +- the web site: [https://maven.apache.org/][2] +- the maven-user mailing list: [https://maven.apache.org/mailing-lists.html](/mailing-lists.html) +- the reference documentation: [https://maven.apache.org/ref/3.9.3/](/ref/3.9.3/) + +## Overview About the Changes + +* Regression fixes and changes based on user feedback from Maven 3.9.2 +* General performance and other fixes + +The full list of changes can be found in our [issue management system][4]. + +### Notable New Features + +* Updated [Eclipse Sisu](https://www.eclipse.org/sisu/) (a Guice based JSR330 container) to latest release. So far used Sisu version was quite old, it supported Java bytecode up to Java 11, limiting all DI managed components (so Mojos, extension and plugin components). This change +makes possible to create Maven components up to Java 21 bytecode. Naturally, Maven still remains Java 8, so to use plugins, extensions and components compiled into bytecode higher than Java 8, one must use corresponding Java version to run Maven as well. +* Huge effort of updating ASF Maven plugins is ongoing, and Maven received a ton of lifecycle bound plugin version updates since Maven 3.9.2 (that was released with same plugin versions as Maven 3.9.1). +* Plugin validation did shake up Maven users community, hence, on users request, they are "toned down". Validation messages are always collected (as before), but default display mode is again "inline" as it was in Maven 3.9.1. Moreover, by default only "project local" messages are displayed to user: issues +that user can fix by editing the project POM. Plugin non-configuration issues, that can be fixed by corresponding plugin developer only (and requires a release and updating in current project POM) are NOT displayed anymore by default. To enjoy them, one needs explicitly to enable "verbose" mode for plugin +validation. Furthermore, the precision of warnings and some badly worded messages are fixed. +* Updated Resolver brings transport related improvements and one interesting new feature: control of checksums per-remote repository. + +### Potentially Breaking Core Changes + +* The updated [Eclipse Sisu](https://www.eclipse.org/sisu/) might break certain extensions (e. g. Gradle Enterprise) and requires updating affected extensions. + Review Comment: @gnodet reverted the Sisu update so this is no longer applicable to 3.9.3 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7587) Update Sisu to a version supporting at least Java 17
[
https://issues.apache.org/jira/browse/MNG-7587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728798#comment-17728798
]
Marc Philipp commented on MNG-7587:
---
[~gnodet] Why's that?
> Update Sisu to a version supporting at least Java 17
>
>
> Key: MNG-7587
> URL: https://issues.apache.org/jira/browse/MNG-7587
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-6, 4.0.0
>
> Attachments: hello-maven-plugin.zip
>
>
> Version 0.3.5 (inherited from
> https://github.com/apache/maven-parent/blob/aff1eef5409009ca7f9d5f196233b2a575aba775/pom.xml#L934)
> in both Maven 4 and 3.9 of {{sisu.inject}} ships with ASM 5.0.2 (relaxed in
> https://github.com/eclipse/sisu.inject/commit/5e34add4790384dc764f77c9e31761cbc6e479aa
> to support up to Java 14).
> Given that Java 19 is the most recent one today Maven needs a newer version
> of {{sisu.inject}} to fully support newer Java bytecode than for Java 14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7802) Fix behaviour of the maven update policy
[
https://issues.apache.org/jira/browse/MNG-7802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7802:
-
Description:
The update policy can be specified using the {{-U}} (force update) or {{-nsu}}
(no update) options, but those options change the whole repository session
policy and override any settings on the repositories.
This means that if {{-U}} is set, the resolver will attempt to check already
downloaded artifacts. This is wrong and the behaviour has been inherited from
maven 2.x.
What we really wants (and what's implied by the name of the options and docs)
is to check for new artifacts / updates, so this mainly affect _version
resolution_ and not {_}artifact resolution{_}.
Also, the CLI options for {{-U}} and {{-nsu}} indicates that those are for
snapshots, while they actually affect all policies, so those should be renamed
and their doc fixed.
was:
The update policy can be specified using the {{-U}} (force update) or {{-nsu}}
(no update) options, but those options change the whole repository session
policy and override any settings on the repositories.
This means that if {{-U}} is set, the resolver will attempt to check already
downloaded artifacts. This is wrong and the behaviour has been inherited from
maven 2.x.
What we really wants (and what's implied by the name of the options and docs)
is to check for new artifacts / updates, so this mainly affect _version
resolution_ and not {_}artifact resolution{_}.
> Fix behaviour of the maven update policy
>
>
> Key: MNG-7802
> URL: https://issues.apache.org/jira/browse/MNG-7802
> Project: Maven
> Issue Type: Bug
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The update policy can be specified using the {{-U}} (force update) or
> {{-nsu}} (no update) options, but those options change the whole repository
> session policy and override any settings on the repositories.
> This means that if {{-U}} is set, the resolver will attempt to check already
> downloaded artifacts. This is wrong and the behaviour has been inherited
> from maven 2.x.
> What we really wants (and what's implied by the name of the options and docs)
> is to check for new artifacts / updates, so this mainly affect _version
> resolution_ and not {_}artifact resolution{_}.
>
>
> Also, the CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect all policies, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7802) Fix behaviour of the maven update policy
Guillaume Nodet created MNG-7802:
Summary: Fix behaviour of the maven update policy
Key: MNG-7802
URL: https://issues.apache.org/jira/browse/MNG-7802
Project: Maven
Issue Type: Bug
Reporter: Guillaume Nodet
Assignee: Guillaume Nodet
The update policy can be specified using the {{-U}} (force update) or {{-nsu}}
(no update) options, but those options change the whole repository session
policy and override any settings on the repositories.
This means that if {{-U}} is set, the resolver will attempt to check already
downloaded artifacts. This is wrong and the behaviour has been inherited from
maven 2.x.
What we really wants (and what's implied by the name of the options and docs)
is to check for new artifacts / updates, so this mainly affect _version
resolution_ and not {_}artifact resolution{_}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7801) Clean doc for repositories policies
[
https://issues.apache.org/jira/browse/MNG-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7801:
-
Description:
The model doc (and other) indicates that the default update policy is daily,
but no value is set by default, and the resolver assumes {{never}} as a default
(see
[https://github.com/apache/maven-resolver/blob/97dfd1c2b9deb15734d5e401807e55cd0498332a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdatePolicyAnalyzer.java#L91)]
was:
The model doc (and other) indicates that the default update policy is daily,
but no value is set by default, and the resolver assumes {{never}} as a default
(see
[https://github.com/apache/maven-resolver/blob/97dfd1c2b9deb15734d5e401807e55cd0498332a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdatePolicyAnalyzer.java#L91)]
Also, the CLI options for {{-U}} and {{-nsu}} indicates that those are for
snapshots, while they actually affect all policies, so those should be renamed
and their doc fixed.
> Clean doc for repositories policies
> ---
>
> Key: MNG-7801
> URL: https://issues.apache.org/jira/browse/MNG-7801
> Project: Maven
> Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The model doc (and other) indicates that the default update policy is daily,
> but no value is set by default, and the resolver assumes {{never}} as a
> default (see
> [https://github.com/apache/maven-resolver/blob/97dfd1c2b9deb15734d5e401807e55cd0498332a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdatePolicyAnalyzer.java#L91)]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-apache-parent] ctubbsii commented on pull request #155: [MPOM-289] Use properties to define the versions of plugins
ctubbsii commented on PR #155: URL: https://github.com/apache/maven-apache-parent/pull/155#issuecomment-1573924231 Oh, one other comment on this: I've noticed that overriding versions in the child POMs by overriding the property does not cause versions-maven-plugin to notice newer versions when running: `mvn -U versions:display-pluginupdates`. That's not really an issue for this project... more a deficiency in versions-maven-plugin... but I wanted to mention it here, because if a user used these new properties to override the plugin versions instead of defining a version override in their own `` section, they might not notice that the versions-maven-plugin has that limitation. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-apache-parent] ctubbsii commented on a diff in pull request #155: [MPOM-289] Use properties to define the versions of plugins
ctubbsii commented on code in PR #155: URL: https://github.com/apache/maven-apache-parent/pull/155#discussion_r1214516616 ## pom.xml: ## @@ -96,6 +96,34 @@ under the License. 3.1.0 3.9.0 posix + + +0.15 +3.1.0 +3.6.0 +3.2.0 +3.11.0 +3.6.0 +3.1.1 +3.3.0 +3.3.0 +3.1.0 +3.4.0 +3.1.1 +3.5.1 +3.3.0 +3.5.0 + 3.4.3 +3.0.0 + 3.1.0 +3.3.1 +2.0.1 +3.2.1 +3.4.1 +3.12.1 +3.3.0 +3.3.2 Review Comment: > I respect your opinion, as you look at linked issues such convention is already used in many Maven projects > > I also was trying to find what kind of properties are used in other ASF project ... I have found, eg: `.version` `-version` `.version` > > I didn't found properties with versions word as prefix. I haven't found many that do this either... but in my experience, it's a much better convention to put version at the front, especially when using plugins like sortpom-maven-plugin to organize the POM and sort the properties. It's very convenient to have all the versions grouped together. Many projects don't know about sortpom-maven-plugin, and don't use it, though, despite it being a superb plugin for POM quality control. > > I afraid that there is no convention which can be ok for all, how many projects, so many opinions Agreed. But my hope is that the reasons I provided are worth serious consideration, and more people will adopt similar conventions on the same grounds, in the absence of arguments against. Specifically: sort-ability and search-ability are the reasons I gave (I think both help with maintainability: smaller diffs, easier to find and update things). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7801) Clean doc for repositories policies
[
https://issues.apache.org/jira/browse/MNG-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728776#comment-17728776
]
Guillaume Nodet commented on MNG-7801:
--
It really feels wrong to change the CLI to reflect to real behaviour, and this
behaviour is definitely not intuitive nor desired imho.
The {{-U}} option applies to both released/snapshots artifacts/metadata, and
comes from maven 2.x which did not had timestamped snapshots. With
introduction of those timestamped artifacts, artifacts should really never be
updated and what is actually wanted is only to change the policy to check for
snapshots. So what we really want is to change the update policy on the
metadata.
> Clean doc for repositories policies
> ---
>
> Key: MNG-7801
> URL: https://issues.apache.org/jira/browse/MNG-7801
> Project: Maven
> Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The model doc (and other) indicates that the default update policy is daily,
> but no value is set by default, and the resolver assumes {{never}} as a
> default (see
> [https://github.com/apache/maven-resolver/blob/97dfd1c2b9deb15734d5e401807e55cd0498332a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdatePolicyAnalyzer.java#L91)]
>
> Also, the CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect all policies, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MPIR-441) Fix DependenciesReportTest
[
https://issues.apache.org/jira/browse/MPIR-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728761#comment-17728761
]
ASF GitHub Bot commented on MPIR-441:
-
michael-o opened a new pull request, #62:
URL: https://github.com/apache/maven-project-info-reports-plugin/pull/62
This closes #62
Following this checklist to help us incorporate your
contribution quickly and easily:
- [ ] Make sure there is a [JIRA
issue](https://issues.apache.org/jira/browse/MPIR) filed
for the change (usually before you start working on it). Trivial
changes like typos do not
require a JIRA issue. Your pull request should address just this
issue, without
pulling in other changes.
- [ ] Each commit in the pull request should have a meaningful subject line
and body.
- [ ] Format the pull request title like `[MPIR-XXX] - Fixes bug in
ApproximateQuantiles`,
where you replace `MPIR-XXX` with the appropriate JIRA issue. Best
practice
is to use the JIRA issue title in the pull request title and in the
first line of the
commit message.
- [ ] Write a pull request description that is detailed enough to
understand what the pull request does, how, and why.
- [ ] Run `mvn clean verify` to make sure basic checks pass. A more
thorough check will
be performed on your pull request automatically.
- [ ] You have run the integration tests successfully (`mvn -Prun-its clean
verify`).
If your pull request is about ~20 lines of code you don't need to sign an
[Individual Contributor License
Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure
please ask on the developers list.
To make clear that you license your contribution under
the [Apache License Version 2.0, January
2004](http://www.apache.org/licenses/LICENSE-2.0)
you have to acknowledge this by using the following check-box.
- [ ] I hereby declare this contribution to be licenced under the [Apache
License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0)
- [ ] In any other case, please file an [Apache Individual Contributor
License Agreement](https://www.apache.org/licenses/icla.pdf).
> Fix DependenciesReportTest
> --
>
> Key: MPIR-441
> URL: https://issues.apache.org/jira/browse/MPIR-441
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.4.5
>
>
> Currently excluded from the pom.xml with a FIXME:
> {{
> maven-surefire-plugin
>
>
> **/DependenciesReportTest*
>
>
>
>
> }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-project-info-reports-plugin] michael-o opened a new pull request, #62: [MPIR-441] Fix DependenciesReportTest
michael-o opened a new pull request, #62: URL: https://github.com/apache/maven-project-info-reports-plugin/pull/62 This closes #62 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MPIR) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MPIR-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MPIR-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MPIR-441) Fix DependenciesReportTest
[
https://issues.apache.org/jira/browse/MPIR-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-441:
Fix Version/s: 3.4.5
> Fix DependenciesReportTest
> --
>
> Key: MPIR-441
> URL: https://issues.apache.org/jira/browse/MPIR-441
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 3.4.5
>
>
> Currently excluded from the pom.xml with a FIXME:
> {{
> maven-surefire-plugin
>
>
> **/DependenciesReportTest*
>
>
>
>
> }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MPIR-441) Fix DependenciesReportTest
[
https://issues.apache.org/jira/browse/MPIR-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MPIR-441:
---
Assignee: Michael Osipov
> Fix DependenciesReportTest
> --
>
> Key: MPIR-441
> URL: https://issues.apache.org/jira/browse/MPIR-441
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Assignee: Michael Osipov
>Priority: Minor
>
> Currently excluded from the pom.xml with a FIXME:
> {{
> maven-surefire-plugin
>
>
> **/DependenciesReportTest*
>
>
>
>
> }}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7587) Update Sisu to a version supporting at least Java 17
[
https://issues.apache.org/jira/browse/MNG-7587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MNG-7587:
-
Fix Version/s: (was: 3.9.3)
> Update Sisu to a version supporting at least Java 17
>
>
> Key: MNG-7587
> URL: https://issues.apache.org/jira/browse/MNG-7587
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-6, 4.0.0
>
> Attachments: hello-maven-plugin.zip
>
>
> Version 0.3.5 (inherited from
> https://github.com/apache/maven-parent/blob/aff1eef5409009ca7f9d5f196233b2a575aba775/pom.xml#L934)
> in both Maven 4 and 3.9 of {{sisu.inject}} ships with ASM 5.0.2 (relaxed in
> https://github.com/eclipse/sisu.inject/commit/5e34add4790384dc764f77c9e31761cbc6e479aa
> to support up to Java 14).
> Given that Java 19 is the most recent one today Maven needs a newer version
> of {{sisu.inject}} to fully support newer Java bytecode than for Java 14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7587) Update Sisu to a version supporting at least Java 17
[
https://issues.apache.org/jira/browse/MNG-7587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728748#comment-17728748
]
Guillaume Nodet commented on MNG-7587:
--
I've reverted the change to 3.9.3.
> Update Sisu to a version supporting at least Java 17
>
>
> Key: MNG-7587
> URL: https://issues.apache.org/jira/browse/MNG-7587
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Reporter: Konrad Windszus
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-6, 4.0.0
>
> Attachments: hello-maven-plugin.zip
>
>
> Version 0.3.5 (inherited from
> https://github.com/apache/maven-parent/blob/aff1eef5409009ca7f9d5f196233b2a575aba775/pom.xml#L934)
> in both Maven 4 and 3.9 of {{sisu.inject}} ships with ASM 5.0.2 (relaxed in
> https://github.com/eclipse/sisu.inject/commit/5e34add4790384dc764f77c9e31761cbc6e479aa
> to support up to Java 14).
> Given that Java 19 is the most recent one today Maven needs a newer version
> of {{sisu.inject}} to fully support newer Java bytecode than for Java 14.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Moved] (MNG-7801) Clean doc for repositories policies
[
https://issues.apache.org/jira/browse/MNG-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet moved MRESOLVER-368 to MNG-7801:
Key: MNG-7801 (was: MRESOLVER-368)
Project: Maven (was: Maven Resolver)
> Clean doc for repositories policies
> ---
>
> Key: MNG-7801
> URL: https://issues.apache.org/jira/browse/MNG-7801
> Project: Maven
> Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The model doc (and other) indicates that the default update policy is daily,
> but no value is set by default, and the resolver assumes {{never}} as a
> default (see
> [https://github.com/apache/maven-resolver/blob/97dfd1c2b9deb15734d5e401807e55cd0498332a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdatePolicyAnalyzer.java#L91)]
>
> Also, the CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect all policies, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-368) Clean doc for repositories policies
[
https://issues.apache.org/jira/browse/MRESOLVER-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated MRESOLVER-368:
--
Summary: Clean doc for repositories policies (was: Clean doc for
repositories)
> Clean doc for repositories policies
> ---
>
> Key: MRESOLVER-368
> URL: https://issues.apache.org/jira/browse/MRESOLVER-368
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The model doc (and other) indicates that the default update policy is daily,
> but no value is set by default, and the resolver assumes {{never}} as a
> default (see
> [https://github.com/apache/maven-resolver/blob/97dfd1c2b9deb15734d5e401807e55cd0498332a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdatePolicyAnalyzer.java#L91)]
>
> Also, the CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect all policies, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-368) Clean doc for repositories
Guillaume Nodet created MRESOLVER-368:
-
Summary: Clean doc for repositories
Key: MRESOLVER-368
URL: https://issues.apache.org/jira/browse/MRESOLVER-368
Project: Maven Resolver
Issue Type: Task
Reporter: Guillaume Nodet
The model doc (and other) indicates that the default update policy is daily,
but no value is set by default, and the resolver assumes {{never}} as a default
(see
[https://github.com/apache/maven-resolver/blob/97dfd1c2b9deb15734d5e401807e55cd0498332a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdatePolicyAnalyzer.java#L91)]
Also, the CLI options for {{-U}} and {{-nsu}} indicates that those are for
snapshots, while they actually affect all policies, so those should be renamed
and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-368) Clean doc for repositories
[
https://issues.apache.org/jira/browse/MRESOLVER-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet reassigned MRESOLVER-368:
-
Assignee: Guillaume Nodet
> Clean doc for repositories
> --
>
> Key: MRESOLVER-368
> URL: https://issues.apache.org/jira/browse/MRESOLVER-368
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
>
> The model doc (and other) indicates that the default update policy is daily,
> but no value is set by default, and the resolver assumes {{never}} as a
> default (see
> [https://github.com/apache/maven-resolver/blob/97dfd1c2b9deb15734d5e401807e55cd0498332a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdatePolicyAnalyzer.java#L91)]
>
> Also, the CLI options for {{-U}} and {{-nsu}} indicates that those are for
> snapshots, while they actually affect all policies, so those should be
> renamed and their doc fixed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-parent] gnodet commented on pull request #122: [MPOM-421] Bump sisu from 0.3.5 to 0.9.0.M2
gnodet commented on PR #122: URL: https://github.com/apache/maven-parent/pull/122#issuecomment-1573724662 > > > While I'm ok to use the newer Sisu plugin, I'm not sure about the impact of updating Sisu as dependency. > > > > > > Agreed, though maven 3.9.x and master have recently upgraded to that one. > > That means if the min API level for the plugin will be updated to 3.9.3(?) This new impl will be injected by Maven. In any earlier Maven - plugin will get the old version. Right? We are not using too much of Sisu internals yet. In the release note I saw enhancement to define configuration. Soon we may get Path support as Parameter type in Sisu, this may lead to some confusion, hope our CI could catch it. Maven actually controls which version of sisu.plexus is used, so I doubt the upgrade will have any effect for plugins or other components since whatever they depend on will be overridden by the version provided by maven. My goal was really to target the plugin or APT processor. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-parent] gnodet merged pull request #115: [MPOM-346] Do not run ITs in release
gnodet merged PR #115: URL: https://github.com/apache/maven-parent/pull/115 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] elharo commented on pull request #653: update commons-io to 2.12.0
elharo commented on PR #653: URL: https://github.com/apache/maven-surefire/pull/653#issuecomment-1573693135 I suppose there's some dispute about what constitutes a "trivial change". Again, some reviewers tell me not to file issues for this sort of thing. Some tell me to file issues. There simply isn't consensus here. And if we require Jira issues for every dependency change, dependabot really doesn't work. :-( -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-integration-testing] gnodet commented on pull request #267: Upgrade parent and reformat code
gnodet commented on PR #267: URL: https://github.com/apache/maven-integration-testing/pull/267#issuecomment-1573690309 I'd like to rebase that one soon rather than later, as any PR merge will cause this PR build to fail and would need a rebase/merge. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7338) Reduce carbon footprint in CI
[
https://issues.apache.org/jira/browse/MNG-7338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728727#comment-17728727
]
ASF GitHub Bot commented on MNG-7338:
-
gnodet commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1214326567
##
maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
##
@@ -173,7 +177,17 @@ public CLIManager() {
.build());
options.addOption(Option.builder(Character.toString(BATCH_MODE))
.longOpt("batch-mode")
-.desc("Run in non-interactive (batch) mode (disables output
color)")
+.desc(
+"Run in non-interactive (batch) mode (disables output
color) - alias for --non-interactive (kept for backwards compatability)")
+.build());
+options.addOption(Option.builder(NON_INTERACTIVE)
+.longOpt("non-interactive")
+.desc("Run in non-interactive (batch) mode (disables output
color) - alias for --batch-mode")
+.build());
+options.addOption(Option.builder(FORCE_INTERACTIVE)
+.longOpt("force-interactive")
+.desc(
+"Run in interactive mode - even when the environment
variable CI is set to true and --non-interactive or --batch-mode are set")
Review Comment:
I'm not sure the flag is relevant for jansi.
> Reduce carbon footprint in CI
> -
>
> Key: MNG-7338
> URL: https://issues.apache.org/jira/browse/MNG-7338
> Project: Maven
> Issue Type: Bug
>Reporter: Jörg Hohwiller
>Assignee: Martin Kanters
>Priority: Major
>
> MNG-4198 was closed with a simple workaround to add {{-B}} option.
> However, if you look at the real world you will notice that in travis,
> circle-ci, jenkins, github-actions, etc. 99% of the builds do not use it (not
> even by defaults from the makers of build templates) and hence 80% of the log
> files are pure spam and waste:
> {code}
> Progress (2): 0.9/2.6 MB | 160/502 kB
> Progress (2): 0.9/2.6 MB | 164/502 kB
> Progress (2): 0.9/2.6 MB | 168/502 kB
> Progress (2): 0.9/2.6 MB | 172/502 kB
> Progress (2): 0.9/2.6 MB | 176/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 0.9/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 180/502 kB
> Progress (2): 1.0/2.6 MB | 184/502 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 4.1/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 8.2/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 12/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 16/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 20/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 25/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 29/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 33/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 37/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 41/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 45/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 49/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 53/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 57/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 61/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 66/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 70/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 74/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 78/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 82/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 86/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 90/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 94/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 98/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 102/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 106/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 111/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 184/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 188/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 193/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 197/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 201/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 205/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 209/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 213/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 217/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 221/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 225/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 229/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 233/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 238/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 242/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 246/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 250/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB | 254/502 kB | 115/196 kB
> Progress (3): 1.0/2.6 MB |
[GitHub] [maven] gnodet commented on a diff in pull request #869: [MNG-7338] Automatically activate batch-mode and make output quiet when running in CI.
gnodet commented on code in PR #869:
URL: https://github.com/apache/maven/pull/869#discussion_r1214326567
##
maven-embedder/src/main/java/org/apache/maven/cli/CLIManager.java:
##
@@ -173,7 +177,17 @@ public CLIManager() {
.build());
options.addOption(Option.builder(Character.toString(BATCH_MODE))
.longOpt("batch-mode")
-.desc("Run in non-interactive (batch) mode (disables output
color)")
+.desc(
+"Run in non-interactive (batch) mode (disables output
color) - alias for --non-interactive (kept for backwards compatability)")
+.build());
+options.addOption(Option.builder(NON_INTERACTIVE)
+.longOpt("non-interactive")
+.desc("Run in non-interactive (batch) mode (disables output
color) - alias for --batch-mode")
+.build());
+options.addOption(Option.builder(FORCE_INTERACTIVE)
+.longOpt("force-interactive")
+.desc(
+"Run in interactive mode - even when the environment
variable CI is set to true and --non-interactive or --batch-mode are set")
Review Comment:
I'm not sure the flag is relevant for jansi.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-shared-utils] elharo merged pull request #152: Remove ConstantConditions warning suppressions that no longer apply
elharo merged PR #152: URL: https://github.com/apache/maven-shared-utils/pull/152 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-7585) Get rid of duplicate utility classes
[
https://issues.apache.org/jira/browse/MNG-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet closed MNG-7585.
Resolution: Fixed
> Get rid of duplicate utility classes
>
>
> Key: MNG-7585
> URL: https://issues.apache.org/jira/browse/MNG-7585
> Project: Maven
> Issue Type: Task
>Affects Versions: 4.0.0-alpha-2
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-6
>
>
> We currently have 3 copies of {{WrapperList}} and {{WrapperProperties}} and 4
> copies of {{{}ImmutableCollections{}}}.
> It would be nice to find a way to keep a single copy of those without adding
> a dependency on some utility module, especially for the
> {{ImmutableCollections}} which are non public classes inside the v4 api.
>
> One possibility may be to use maven-shade-plugin to include a copy of the
> needed classes as non public classes inside the needed package... ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7585) Get rid of duplicate utility classes
[
https://issues.apache.org/jira/browse/MNG-7585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728709#comment-17728709
]
ASF GitHub Bot commented on MNG-7585:
-
gnodet merged PR #1135:
URL: https://github.com/apache/maven/pull/1135
> Get rid of duplicate utility classes
>
>
> Key: MNG-7585
> URL: https://issues.apache.org/jira/browse/MNG-7585
> Project: Maven
> Issue Type: Task
>Affects Versions: 4.0.0-alpha-2
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-6
>
>
> We currently have 3 copies of {{WrapperList}} and {{WrapperProperties}} and 4
> copies of {{{}ImmutableCollections{}}}.
> It would be nice to find a way to keep a single copy of those without adding
> a dependency on some utility module, especially for the
> {{ImmutableCollections}} which are non public classes inside the v4 api.
>
> One possibility may be to use maven-shade-plugin to include a copy of the
> needed classes as non public classes inside the needed package... ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] gnodet merged pull request #1135: [MNG-7585] Remove duplicate classes
gnodet merged PR #1135: URL: https://github.com/apache/maven/pull/1135 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shared-utils] elharo merged pull request #150: Clean up and correct Javadoc
elharo merged PR #150: URL: https://github.com/apache/maven-shared-utils/pull/150 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shared-utils] elharo merged pull request #151: remove last dependency on plexus
elharo merged PR #151: URL: https://github.com/apache/maven-shared-utils/pull/151 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shared-utils] elharo merged pull request #149: Clear a couple of TODOs by better testing exceptions
elharo merged PR #149: URL: https://github.com/apache/maven-shared-utils/pull/149 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] elharo commented on pull request #653: update commons-io to 2.12.0
elharo commented on PR #653: URL: https://github.com/apache/maven-surefire/pull/653#issuecomment-1573572674 FYI commit messages are the same. Different reviewers request different and sometimes contradictory commit conventions. There aren't any established project wide standards for this that anyone pays attention to. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] elharo commented on pull request #653: update commons-io to 2.12.0
elharo commented on PR #653: URL: https://github.com/apache/maven-surefire/pull/653#issuecomment-1573569906 We honestly don't seem to have any consensus on filing issues for straightforward dependency upgrades like this one. I've been told by some reviewers on some PRs to file issues and on others by other reviewers not to file issues. If we're going to use dependabot or renovatebot, requiring Jira issues mostly defeats the purpose. Unless it resolves an active bug in the Maven project itself — not the dependency — my preference is not to file an issue. And if it does resolve a bug, the issue should focus on the bug, not the dependency upgrade. As a user I prefer to not have the release notes cluttered with dependency upgrades that have no visible effect on my work. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7800) Upgrade to resolver 1.9.11
[ https://issues.apache.org/jira/browse/MNG-7800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-7800: - Component/s: Dependencies > Upgrade to resolver 1.9.11 > -- > > Key: MNG-7800 > URL: https://issues.apache.org/jira/browse/MNG-7800 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0 > > > Ingest resolver 1.9.11 with latest fixes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7698) Allow comments in .mvn/maven.config
[
https://issues.apache.org/jira/browse/MNG-7698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-7698:
-
Component/s: Command Line
> Allow comments in .mvn/maven.config
> ---
>
> Key: MNG-7698
> URL: https://issues.apache.org/jira/browse/MNG-7698
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Reporter: Slawomir Jaranowski
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> Since {{.mvn/maven.config}} requires each arguments in new line,
> it is easy to skip line beginning with special char - like {{#}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7698) Allow comments in .mvn/maven.config
[
https://issues.apache.org/jira/browse/MNG-7698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728692#comment-17728692
]
ASF GitHub Bot commented on MNG-7698:
-
cstamas opened a new pull request, #1141:
URL: https://github.com/apache/maven/pull/1141
Backport of https://github.com/apache/maven/pull/1134
---
https://issues.apache.org/jira/browse/MNG-7698
> Allow comments in .mvn/maven.config
> ---
>
> Key: MNG-7698
> URL: https://issues.apache.org/jira/browse/MNG-7698
> Project: Maven
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 3.9.3, 4.0.0-alpha-6, 4.0.0
>
>
> Since {{.mvn/maven.config}} requires each arguments in new line,
> it is easy to skip line beginning with special char - like {{#}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] cstamas opened a new pull request, #1141: [MNG-7698] Allow comments in .mvn/maven.config
cstamas opened a new pull request, #1141: URL: https://github.com/apache/maven/pull/1141 Backport of https://github.com/apache/maven/pull/1134 --- https://issues.apache.org/jira/browse/MNG-7698 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7548) Kill off "legacy" repository metadata support
[ https://issues.apache.org/jira/browse/MNG-7548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728688#comment-17728688 ] ASF GitHub Bot commented on MNG-7548: - cstamas commented on PR #1138: URL: https://github.com/apache/maven/pull/1138#issuecomment-1573535199 Ah, I meant "we have many other places **in ecosystem**" like that invoker plugin etc. So we need to search'n'destroy all those places. > Kill off "legacy" repository metadata support > - > > Key: MNG-7548 > URL: https://issues.apache.org/jira/browse/MNG-7548 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > > Maven 3.0 introduced repository metadata model version "1.1.0" (MNG-4452), > while Maven 2 used repository metadata model version "1.0.0" (could not > resolve snapshot artifacts having classifiers). > Current Maven should never generate "legacy" metadata anymore, as 2.x line is > EOL, and model version is in effect since Maven 3.0. > Mixing metadata causes issues like MRESOLVER-224 (alas, this is actually > MINVOKER issue, as it "crafts" legacy metadata using pure DOM) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] cstamas commented on pull request #1138: [MNG-7548] Kill off "legacy" repository metadata support
cstamas commented on PR #1138: URL: https://github.com/apache/maven/pull/1138#issuecomment-1573535199 Ah, I meant "we have many other places **in ecosystem**" like that invoker plugin etc. So we need to search'n'destroy all those places. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-release] tonymcveigh opened a new pull request, #195: This one
tonymcveigh opened a new pull request, #195: URL: https://github.com/apache/maven-release/pull/195 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MRELEASE) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MRELEASE-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MRELEASE-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify -Prun-its` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-7548) Kill off "legacy" repository metadata support
[ https://issues.apache.org/jira/browse/MNG-7548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17728687#comment-17728687 ] ASF GitHub Bot commented on MNG-7548: - gnodet commented on PR #1138: URL: https://github.com/apache/maven/pull/1138#issuecomment-1573534252 > LGTM, but as issue mentions, we have other places to look into as well @cstamas What are you referring it ? I read the issue again but I don't see... > Kill off "legacy" repository metadata support > - > > Key: MNG-7548 > URL: https://issues.apache.org/jira/browse/MNG-7548 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Guillaume Nodet >Priority: Major > > Maven 3.0 introduced repository metadata model version "1.1.0" (MNG-4452), > while Maven 2 used repository metadata model version "1.0.0" (could not > resolve snapshot artifacts having classifiers). > Current Maven should never generate "legacy" metadata anymore, as 2.x line is > EOL, and model version is in effect since Maven 3.0. > Mixing metadata causes issues like MRESOLVER-224 (alas, this is actually > MINVOKER issue, as it "crafts" legacy metadata using pure DOM) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven] gnodet commented on pull request #1138: [MNG-7548] Kill off "legacy" repository metadata support
gnodet commented on PR #1138: URL: https://github.com/apache/maven/pull/1138#issuecomment-1573534252 > LGTM, but as issue mentions, we have other places to look into as well @cstamas What are you referring it ? I read the issue again but I don't see... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
