[jira] [Updated] (MNG-8115) Upgrade dependencies
[ https://issues.apache.org/jira/browse/MNG-8115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8115: - Component/s: Dependencies > Upgrade dependencies > > > Key: MNG-8115 > URL: https://issues.apache.org/jira/browse/MNG-8115 > Project: Maven > Issue Type: Dependency upgrade > Components: Dependencies >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.9.7, 3.9.x-candidate > > > Apache commons, Classword -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-555) Existence check should lax the repository update policy
[
https://issues.apache.org/jira/browse/MRESOLVER-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843367#comment-17843367
]
Tamas Cservenak commented on MRESOLVER-555:
---
This is wrong. This cannot happen in all cases...
Simply put, Resolver has no notion of "wandering artifacts", but it does try
hard to enforce error policy ("cache 404").
I think the proper solution would be to be able to assign
{{org.eclipse.aether.resolution.ResolutionErrorPolicy}} not only session-wide,
but to a RemoteRepository (code change in Resolver but also code change in
Maven). As then, solution would be:
* super POM states "do not cache 404 for Central", but
* do cache as today (per session level)
Also with this exposed, any organization could set/configure whatever setup
they have, like "by the book" setup of staging suite that ends up in releases
repo...
Ideas welcome.
> Existence check should lax the repository update policy
> ---
>
> Key: MRESOLVER-555
> URL: https://issues.apache.org/jira/browse/MRESOLVER-555
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-beta-1
>
>
> Maybe only when update policy is "never".
> Order of events:
> * attempt a build with not-yet-released-artifact (for example resolver in
> maven)
> * as it is not in central, build will fail, and central URL will be "cached"
> as 404 for given artifact
> * fix, rinse, repeat, add staging repository, rebuild
> * build will pass ok, as staging repository will have the artifact, it is
> cached to local repository (from staging repository)
> * later, staging repository is dropped, release promoted to central.
> * rebuild: here, Resolver will nag that "artifact is present but not
> available", which is true: it was cached from staging repository
> * it will go try to see is it available in central (existence check), but:
> central has 404 cached (see step 1), and in this case update policy is being
> obeyed, that is "never"
> * due "never" update policy existence check will fail, and build will fail
> Now, IMO, for "existence check" Resolver should lax the policy ONLY if it is
> "never" maybe? As from this situation only escape route is build with -U that
> will reset local repository state and build will pass.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-555) Existence check should lax the repository update policy
[ https://issues.apache.org/jira/browse/MRESOLVER-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-555: -- Description: Maybe only when update policy is "never". Order of events: * attempt a build with not-yet-released-artifact (for example resolver in maven) * as it is not in central, build will fail, and central URL will be "cached" as 404 * fix, rinse, repeat, add staging repository, rebuild * build will pass ok, as staging repository will have the artifact, it is cached to local repository (from staging repository) * later, staging repository is dropped, release promoted to central. * rebuild: here, Resolver will nag that "artifact is present but not available", which is true: it was cached from staging repository * it will go try to see is it available in central (existence check), but: central has 404 cached (see step 1), and in this case update policy is being obeyed, that is "never" * due "never" update policy existence check will fail, and build will fail Now, IMO, for "existence check" Resolver should lax the policy ONLY if it is "never" maybe? As from this situation only escape route is build with -U that will reset local repository state and build will pass. was: Maybe only when update policy is "never". Order of events: * attempt a build with not-yet-released-artifact (for example resolver in maven) * as it is not in central, build will fail, and central URL will be "cached" as 404 * fix, rinse, repeat, add staging repository, rebuild * build will pass ok, as staging repository will have the artifact, it is cached to local repository (from staging repository) * later, staging repository is dropped, release promoted to central. * rebuild: here, Resolver will nag that "artifact is present but not available", which is true: it was cached from staging repository * it will go try to see is it available in central (existence check), but: central has 404 cached (see step 1), and in this case update policy is being obeyed, that is "never" * due "never" update policy existence check will fail, and build will fail > Existence check should lax the repository update policy > --- > > Key: MRESOLVER-555 > URL: https://issues.apache.org/jira/browse/MRESOLVER-555 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > > Maybe only when update policy is "never". > Order of events: > * attempt a build with not-yet-released-artifact (for example resolver in > maven) > * as it is not in central, build will fail, and central URL will be "cached" > as 404 > * fix, rinse, repeat, add staging repository, rebuild > * build will pass ok, as staging repository will have the artifact, it is > cached to local repository (from staging repository) > * later, staging repository is dropped, release promoted to central. > * rebuild: here, Resolver will nag that "artifact is present but not > available", which is true: it was cached from staging repository > * it will go try to see is it available in central (existence check), but: > central has 404 cached (see step 1), and in this case update policy is being > obeyed, that is "never" > * due "never" update policy existence check will fail, and build will fail > Now, IMO, for "existence check" Resolver should lax the policy ONLY if it is > "never" maybe? As from this situation only escape route is build with -U that > will reset local repository state and build will pass. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-555) Existence check should lax the repository update policy
[ https://issues.apache.org/jira/browse/MRESOLVER-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-555: -- Description: Maybe only when update policy is "never". Order of events: * attempt a build with not-yet-released-artifact (for example resolver in maven) * as it is not in central, build will fail, and central URL will be "cached" as 404 for given artifact * fix, rinse, repeat, add staging repository, rebuild * build will pass ok, as staging repository will have the artifact, it is cached to local repository (from staging repository) * later, staging repository is dropped, release promoted to central. * rebuild: here, Resolver will nag that "artifact is present but not available", which is true: it was cached from staging repository * it will go try to see is it available in central (existence check), but: central has 404 cached (see step 1), and in this case update policy is being obeyed, that is "never" * due "never" update policy existence check will fail, and build will fail Now, IMO, for "existence check" Resolver should lax the policy ONLY if it is "never" maybe? As from this situation only escape route is build with -U that will reset local repository state and build will pass. was: Maybe only when update policy is "never". Order of events: * attempt a build with not-yet-released-artifact (for example resolver in maven) * as it is not in central, build will fail, and central URL will be "cached" as 404 * fix, rinse, repeat, add staging repository, rebuild * build will pass ok, as staging repository will have the artifact, it is cached to local repository (from staging repository) * later, staging repository is dropped, release promoted to central. * rebuild: here, Resolver will nag that "artifact is present but not available", which is true: it was cached from staging repository * it will go try to see is it available in central (existence check), but: central has 404 cached (see step 1), and in this case update policy is being obeyed, that is "never" * due "never" update policy existence check will fail, and build will fail Now, IMO, for "existence check" Resolver should lax the policy ONLY if it is "never" maybe? As from this situation only escape route is build with -U that will reset local repository state and build will pass. > Existence check should lax the repository update policy > --- > > Key: MRESOLVER-555 > URL: https://issues.apache.org/jira/browse/MRESOLVER-555 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > > Maybe only when update policy is "never". > Order of events: > * attempt a build with not-yet-released-artifact (for example resolver in > maven) > * as it is not in central, build will fail, and central URL will be "cached" > as 404 for given artifact > * fix, rinse, repeat, add staging repository, rebuild > * build will pass ok, as staging repository will have the artifact, it is > cached to local repository (from staging repository) > * later, staging repository is dropped, release promoted to central. > * rebuild: here, Resolver will nag that "artifact is present but not > available", which is true: it was cached from staging repository > * it will go try to see is it available in central (existence check), but: > central has 404 cached (see step 1), and in this case update policy is being > obeyed, that is "never" > * due "never" update policy existence check will fail, and build will fail > Now, IMO, for "existence check" Resolver should lax the policy ONLY if it is > "never" maybe? As from this situation only escape route is build with -U that > will reset local repository state and build will pass. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8076) when jar in local repository from other repository id, should not reject but check if it is also available in current repository id context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843360#comment-17843360
]
Tamas Cservenak commented on MNG-8076:
--
created https://issues.apache.org/jira/browse/MRESOLVER-555
> when jar in local repository from other repository id, should not reject but
> check if it is also available in current repository id context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
> maven-shade-plugin-3.5.2-source-release.zip>reference=
> maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
> maven-shade-plugin-3.5.2-cyclonedx.json>reference=
> {noformat}
> the fact that all these artifacts were initially downloaded through
> "reference" repository id does not mean that they are not *also* available
> with the "central" id
> as a precise workaround, i did not delete the _remote.repositories file but
> replaced reference with central and it works as expected. The opposite update
> can restore the failing behaviour...
> for now, I know that by rebuilding releases from Apache staging area, I'm
> polluting my local repository :/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MRESOLVER-555) Existence check should lax the repository update policy
Tamas Cservenak created MRESOLVER-555: - Summary: Existence check should lax the repository update policy Key: MRESOLVER-555 URL: https://issues.apache.org/jira/browse/MRESOLVER-555 Project: Maven Resolver Issue Type: Bug Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-beta-1 Maybe only when update policy is "never". Order of events: * attempt a build with not-yet-released-artifact (for example resolver in maven) * as it is not in central, build will fail, and central URL will be "cached" as 404 * fix, rinse, repeat, add staging repository, rebuild * build will pass ok, as staging repository will have the artifact, it is cached to local repository (from staging repository) * later, staging repository is dropped, release promoted to central. * rebuild: here, Resolver will nag that "artifact is present but not available", which is true: it was cached from staging repository * it will go try to see is it available in central (existence check), but: central has 404 cached (see step 1), and in this case update policy is being obeyed, that is "never" * due "never" update policy existence check will fail, and build will fail -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8041) Maven Core bug regarding resolution scopes for Mojos
[
https://issues.apache.org/jira/browse/MNG-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8041:
-
Fix Version/s: 4.0.0-beta-2
(was: 4.0.0-beta-1)
> Maven Core bug regarding resolution scopes for Mojos
>
>
> Key: MNG-8041
> URL: https://issues.apache.org/jira/browse/MNG-8041
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-2
>
>
> This bug affects all released Maven versions.
> Reproducer: [https://github.com/cstamas/MNG-8041]
> Description of the bug: when a Mojo requires Core to collect/resolve given
> ResolutionScope, Maven Core does it wrong. Problem is how
> LifecycleDependencyResolver and DefaultProjectDependenciesResolver colaborate
> plus, how Resolver works. LDR constructs the Resolver filters properly, then
> it calls into DPDR, that performs collection. To achieve that, DPDR *blindly*
> adds all the POM dependencies to Collect request (which is graph root). But
> this is wrong, as this should happen with considering requested (to be
> included or to be excluded) scopes. Next what happens, that when collect
> request is processed by Resolver, it will contain nodes from unwanted scopes
> (as Maven Core blindly added all of them from POM). Just as detail: if
> Resolver would be asked to create root, it would NOT add these in the first
> place. Due these present, conflict resolver may possibly eliminate other
> nodes (as POM ones "always wins", are the closest to graph root. Finally,
> these winners may be eliminated in subsequent step, for example due scope
> filtering. This results in incomplete resolution scope.
> Example: let's consider example where Mojo asks for "runtime" resolution
> scope. To serve this, Maven will add ALL dependencies present in POM to
> collect request (even those in scopes to be omitted, like "test" scoped
> ones), and will perform "collect" using Resolver. When Resolver returns the
> graph, it will contain nodes (as 1st level was populated by Maven) that MAY
> be contained in deeper nodes of non-test scoped ones (the guice+guava
> example). Next, "conflict resolution" happens, and naturally all the "test"
> scoped 1st level dependencies will "win", rendering removal of others.
> Finally, due "runtime" requested resolution scope, the "test" scoped
> dependencies are (rightfully) filtered out. {*}This obviously leads to
> incomplete runtime build path{*}.
> Or in other words, Maven is wrong here: it adds 1st level dependencies to
> CollectRequest that should not be there in the first place (in example above,
> the "test" scoped ones), that will cause that Resolver "collect" step build a
> graph that has "unwanted" scoped nodes closer to root than actually needed
> runtime dependencies (remember: test nodes will be not affected by filter, as
> they are already present, added by Maven, and test node children are
> collected also as "runtime", just to have "test" scope inherited later in the
> process, hence all the children of "test" node will end up in "test" scope,
> despite "exclude test" is present!), this will cause that in dependency
> conflict resolution step, they will kick out all the rightful runtime
> dependencies, and finally, all these winners are removed due scope filter.
> Implication of this bug is following important fact: the project "runtime"
> resolution scope (as when asked by Mojo) and project "runtime" resolution
> scope (as when used as a dependency on some downstream project) {*}were not
> the same{*}!
> Effects of this bug are explained in "Important Consequences" section of this
> page
> [https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-7/common-misconceptions.html#important-consequences]
> (that is wrongly written: all that is a consequence of this bug). Also, have
> to note, that when this bug get addressed, it will NOT render "workarounds"
> broken (ie. introduction of another module just to package "runtime"
> classpath using m-assembly-p or alike plugins), just "obsolete", as packaging
> of runtime dependencies will become possible in-situ (in the same module of
> the project).
> Exercises: check out reproducer and execute these commands:
> * {{mvn dependency:tree}} => OK, it shows "dependencies included from all
> scopes" (this is equiv to "test" build scope), guava is in test scope
> * {{mvn dependency:tree -Dscope=runtime}} => NOT OK, it will show effect of
> this bug, guava is missing from runtime resolution scope
> * install the reproducer project into local repository, and create another
> project (or use {{downstream/pom.xml}} from reproducer) that uses reproducer
> project as dependency (only one, no
[jira] [Closed] (MNG-8073) Generated XSD files needs to have ASL2.0 license headers
[ https://issues.apache.org/jira/browse/MNG-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-8073. Resolution: Fixed > Generated XSD files needs to have ASL2.0 license headers > > > Key: MNG-8073 > URL: https://issues.apache.org/jira/browse/MNG-8073 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-13 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > > Currently we were adding them manually during release process. > Maybe also collecting them to single place would be handy, instead to "hunt > them down" in checkout post release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8076) when jar in local repository from other repository id, should not reject but check if it is also available in current repository id context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843307#comment-17843307
]
Tamas Cservenak commented on MNG-8076:
--
Oh, nvm: the problem is "never" update interval of Central, so it seems in this
case Resolver should be smarter?
> when jar in local repository from other repository id, should not reject but
> check if it is also available in current repository id context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
> maven-shade-plugin-3.5.2-source-release.zip>reference=
> maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
> maven-shade-plugin-3.5.2-cyclonedx.json>reference=
> {noformat}
> the fact that all these artifacts were initially downloaded through
> "reference" repository id does not mean that they are not *also* available
> with the "central" id
> as a precise workaround, i did not delete the _remote.repositories file but
> replaced reference with central and it works as expected. The opposite update
> can restore the failing behaviour...
> for now, I know that by rebuilding releases from Apache staging area, I'm
> polluting my local repository :/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8076) when jar in local repository from other repository id, should not reject but check if it is also available in current repository id context
[
https://issues.apache.org/jira/browse/MNG-8076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843306#comment-17843306
]
Tamas Cservenak commented on MNG-8076:
--
Something is fishy... here what happened (maybe helps to reproduce): Maven
master had merged a PR with Resolver2 alpha-11 that added staging repo (as
Resolver vote was ongoing). This state of master was built on my laptop, so
alpha-11 was present in my local repo. Fast forward a week, git update and
tried to build again. Since then Resolver vote passed, staging repo is gone,
and Resolver alpha-11 is in central. So I got message from Maven "alpha-11 is
present in local repo", but "from different repo that is not available in the
build". The next message said it "will check availability" from central (it is
available), but failed. The only thing helped was -U.
> when jar in local repository from other repository id, should not reject but
> check if it is also available in current repository id context
> ---
>
> Key: MNG-8076
> URL: https://issues.apache.org/jira/browse/MNG-8076
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.9.6
>Reporter: Herve Boutemy
>Priority: Major
>
> precise context: Reproducible Central
> https://github.com/jvm-repo-rebuild/reproducible-central
> in the past, I rebuilt maven-shade-plugin 3.5.2 during the vote, which
> downloaded the reference jar in a staging remote repository with "reference"
> id (that's part of the artifact:compare logic in Apache staging: see
> https://github.com/jvm-repo-rebuild/reproducible-central/issues/140 for
> details on this recent Reproducible Central feature)
> When I'm trying to rebuild a project that uses this maven-shade-plugin 3.5.2
> release, I get:
> {noformat}
> [INFO] Artifact org.apache.maven.plugins:maven-shade-plugin:pom:3.5.2 is
> present in the local repository, but cached from a remote repository ID that
> is unavailable in current build context, verifying that is downloadable from
> [central (https://repo.maven.apache.org/maven2, default, releases)]
> {noformat}
> looking in the local repository, I get
> {noformat}
> cat
> ~/.m2/repository/org/apache/maven/plugins/maven-shade-plugin/3.5.2/_remote.repositories
> #NOTE: This is a Maven Resolver internal implementation file, its format can
> be changed without prior notice.
> #Sun Feb 18 15:03:27 UTC 2024
> maven-shade-plugin-3.5.2-sources.jar>reference=
> maven-shade-plugin-3.5.2.pom>reference=
> maven-shade-plugin-3.5.2.jar>reference=
> maven-shade-plugin-3.5.2-source-release.zip>reference=
> maven-shade-plugin-3.5.2-cyclonedx.xml>reference=
> maven-shade-plugin-3.5.2-cyclonedx.json>reference=
> {noformat}
> the fact that all these artifacts were initially downloaded through
> "reference" repository id does not mean that they are not *also* available
> with the "central" id
> as a precise workaround, i did not delete the _remote.repositories file but
> replaced reference with central and it works as expected. The opposite update
> can restore the failing behaviour...
> for now, I know that by rebuilding releases from Apache staging area, I'm
> polluting my local repository :/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MPLUGIN-519) Update to Parent POM 42, prerequisite 3.6.3
[ https://issues.apache.org/jira/browse/MPLUGIN-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MPLUGIN-519. --- Resolution: Fixed > Update to Parent POM 42, prerequisite 3.6.3 > --- > > Key: MPLUGIN-519 > URL: https://issues.apache.org/jira/browse/MPLUGIN-519 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.12.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MPLUGIN-520) Get rid of maven-compat classes use
[ https://issues.apache.org/jira/browse/MPLUGIN-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MPLUGIN-520. --- Resolution: Fixed > Get rid of maven-compat classes use > --- > > Key: MPLUGIN-520 > URL: https://issues.apache.org/jira/browse/MPLUGIN-520 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.12.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-554) Support configuration of upload/download threads individually
[ https://issues.apache.org/jira/browse/MRESOLVER-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-554. - Resolution: Fixed > Support configuration of upload/download threads individually > - > > Key: MRESOLVER-554 > URL: https://issues.apache.org/jira/browse/MRESOLVER-554 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Matt Nelson >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > > Parallel deploys were introduced in MRESOLVER-32. The thread pool > configuration is shared for uploads and downloads. It has been observed in > our environment that uploads frequently error out when attempting to upload > with the default thread pool size(5), but conversely we don't see the same > errors for downloads. > The proposal is to support configuration of upload/download thread pools > individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8113) Inconsistent way of overriding core components from extensions
Tamas Cservenak created MNG-8113:
Summary: Inconsistent way of overriding core components from
extensions
Key: MNG-8113
URL: https://issues.apache.org/jira/browse/MNG-8113
Project: Maven
Issue Type: Bug
Components: Core
Reporter: Tamas Cservenak
Problem: "let's have a (core) extension that is overriding some component X in
Maven Core".
Doing this is very inconsistent, and depends HOW core component is defined in
the first place.
IF core component is JSR330, then is simple: just define an own JSR330
component (w/ some higher than zero Priority) and done. This can be loaded from
{{.mvn/extensions.xml}} just fine.
IF core component is Plexus, then is not simple:
* using JSR330 – could not do it
* using Plexus annotation + XML – does not works when JAR is in
{{.mvn/extensions.xml}} !
* using Plexus annotation + XML – works only when using
{{-Dmaven.ext.class.path}} w/ JAR enlisted here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-554) Support configuration of upload/download threads individually
[ https://issues.apache.org/jira/browse/MRESOLVER-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842490#comment-17842490 ] Tamas Cservenak edited comment on MRESOLVER-554 at 4/30/24 7:36 PM: One ask, if I may have: please pressure your artifact MRM provider, as since "parallel upload" was introduced, both major implementations (AF and Nx3, but not Nx2!) were reported to... well, nicely said: belly up during uploads. Basically, report this issue and let vendors fix their products :) was (Author: cstamas): One ask, if I may have: please pressure your artifact MRM provider, as since "parallel upload" was introduced, both major implementations (AF and Nx3,but not Nx2!) were reported to... well, nicely said: belly up during uploads. Basically, report this issue and let vendors fix their products :) > Support configuration of upload/download threads individually > - > > Key: MRESOLVER-554 > URL: https://issues.apache.org/jira/browse/MRESOLVER-554 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Matt Nelson >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > > Parallel deploys were introduced in MRESOLVER-32. The thread pool > configuration is shared for uploads and downloads. It has been observed in > our environment that uploads frequently error out when attempting to upload > with the default thread pool size(5), but conversely we don't see the same > errors for downloads. > The proposal is to support configuration of upload/download thread pools > individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-554) Support configuration of upload/download threads individually
[ https://issues.apache.org/jira/browse/MRESOLVER-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842490#comment-17842490 ] Tamas Cservenak commented on MRESOLVER-554: --- One ask, if I may have: please pressure your artifact MRM provider, as since "parallel upload" was introduced, both major implementations (AF and Nx3,but not Nx2!) were reported to... well, nicely said: belly up during uploads. Basically, report this issue and let vendors fix their products :) > Support configuration of upload/download threads individually > - > > Key: MRESOLVER-554 > URL: https://issues.apache.org/jira/browse/MRESOLVER-554 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Matt Nelson >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > > Parallel deploys were introduced in MRESOLVER-32. The thread pool > configuration is shared for uploads and downloads. It has been observed in > our environment that uploads frequently error out when attempting to upload > with the default thread pool size(5), but conversely we don't see the same > errors for downloads. > The proposal is to support configuration of upload/download thread pools > individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-554) Support configuration of upload/download threads individually
[ https://issues.apache.org/jira/browse/MRESOLVER-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-554: - Assignee: Tamas Cservenak > Support configuration of upload/download threads individually > - > > Key: MRESOLVER-554 > URL: https://issues.apache.org/jira/browse/MRESOLVER-554 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Matt Nelson >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > > Parallel deploys were introduced in MRESOLVER-32. The thread pool > configuration is shared for uploads and downloads. It has been observed in > our environment that uploads frequently error out when attempting to upload > with the default thread pool size(5), but conversely we don't see the same > errors for downloads. > The proposal is to support configuration of upload/download thread pools > individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-554) Support configuration of upload/download threads individually
[ https://issues.apache.org/jira/browse/MRESOLVER-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-554: -- Fix Version/s: 2.0.0 2.0.0-beta-1 > Support configuration of upload/download threads individually > - > > Key: MRESOLVER-554 > URL: https://issues.apache.org/jira/browse/MRESOLVER-554 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Matt Nelson >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > > Parallel deploys were introduced in MRESOLVER-32. The thread pool > configuration is shared for uploads and downloads. It has been observed in > our environment that uploads frequently error out when attempting to upload > with the default thread pool size(5), but conversely we don't see the same > errors for downloads. > The proposal is to support configuration of upload/download thread pools > individually. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-554) Support configuration of upload/download threads individually
[
https://issues.apache.org/jira/browse/MRESOLVER-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842467#comment-17842467
]
Tamas Cservenak commented on MRESOLVER-554:
---
Good idea. Still, you already have {{aether.connector.basic.parallelPut}} that
will disable "parallel upload". Is this not enough?
> Support configuration of upload/download threads individually
> -
>
> Key: MRESOLVER-554
> URL: https://issues.apache.org/jira/browse/MRESOLVER-554
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Matt Nelson
>Priority: Major
>
> Parallel deploys were introduced in MRESOLVER-32. The thread pool
> configuration is shared for uploads and downloads. It has been observed in
> our environment that uploads frequently error out when attempting to upload
> with the default thread pool size(5), but conversely we don't see the same
> errors for downloads.
> The proposal is to support configuration of upload/download thread pools
> individually.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8062) Maven should factor in session close failure into build outcome
[
https://issues.apache.org/jira/browse/MNG-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8062.
Resolution: Fixed
After reviewing code, what is in place is enough: session close will throw
RuntimeEx, and it will end up as "internal error", as it should. In other
words, is fine what we have now.
> Maven should factor in session close failure into build outcome
> ---
>
> Key: MNG-8062
> URL: https://issues.apache.org/jira/browse/MNG-8062
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-1
>
>
> Since closeable session in Resolver 2.0, the close was implemented, but any
> possible failure during closing the session would "bubble up", instead to be
> handled.
> Maven should close and also handle any error that may happen during session
> close operation. The build outcome ("build success" or "build failure") is
> evaluated WAY BEFORE repository system session is closed, and this is wrong,
> as build should fail if session close failed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-8062) Maven should factor in session close failure into build outcome
[
https://issues.apache.org/jira/browse/MNG-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8062.
Resolution: Won't Fix
> Maven should factor in session close failure into build outcome
> ---
>
> Key: MNG-8062
> URL: https://issues.apache.org/jira/browse/MNG-8062
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Since closeable session in Resolver 2.0, the close was implemented, but any
> possible failure during closing the session would "bubble up", instead to be
> handled.
> Maven should close and also handle any error that may happen during session
> close operation. The build outcome ("build success" or "build failure") is
> evaluated WAY BEFORE repository system session is closed, and this is wrong,
> as build should fail if session close failed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (MNG-8062) Maven should factor in session close failure into build outcome
[
https://issues.apache.org/jira/browse/MNG-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reopened MNG-8062:
--
> Maven should factor in session close failure into build outcome
> ---
>
> Key: MNG-8062
> URL: https://issues.apache.org/jira/browse/MNG-8062
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Since closeable session in Resolver 2.0, the close was implemented, but any
> possible failure during closing the session would "bubble up", instead to be
> handled.
> Maven should close and also handle any error that may happen during session
> close operation. The build outcome ("build success" or "build failure") is
> evaluated WAY BEFORE repository system session is closed, and this is wrong,
> as build should fail if session close failed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8062) Maven should factor in session close failure into build outcome
[
https://issues.apache.org/jira/browse/MNG-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8062:
-
Fix Version/s: (was: 4.0.0)
(was: 4.0.0-beta-1)
> Maven should factor in session close failure into build outcome
> ---
>
> Key: MNG-8062
> URL: https://issues.apache.org/jira/browse/MNG-8062
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
>
> Since closeable session in Resolver 2.0, the close was implemented, but any
> possible failure during closing the session would "bubble up", instead to be
> handled.
> Maven should close and also handle any error that may happen during session
> close operation. The build outcome ("build success" or "build failure") is
> evaluated WAY BEFORE repository system session is closed, and this is wrong,
> as build should fail if session close failed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8073) Generated XSD files needs to have ASL2.0 license headers
[ https://issues.apache.org/jira/browse/MNG-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-8073: Assignee: Tamas Cservenak > Generated XSD files needs to have ASL2.0 license headers > > > Key: MNG-8073 > URL: https://issues.apache.org/jira/browse/MNG-8073 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-13 >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > > Currently we were adding them manually during release process. > Maybe also collecting them to single place would be handy, instead to "hunt > them down" in checkout post release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8073) Generated XSD files needs to have ASL2.0 license headers
[ https://issues.apache.org/jira/browse/MNG-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842387#comment-17842387 ] Tamas Cservenak commented on MNG-8073: -- Pending, waits for modello release w/ feature added in PR above > Generated XSD files needs to have ASL2.0 license headers > > > Key: MNG-8073 > URL: https://issues.apache.org/jira/browse/MNG-8073 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-13 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > > Currently we were adding them manually during release process. > Maybe also collecting them to single place would be handy, instead to "hunt > them down" in checkout post release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-8062) Maven should factor in session close failure into build outcome
[
https://issues.apache.org/jira/browse/MNG-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MNG-8062:
Assignee: Tamas Cservenak
> Maven should factor in session close failure into build outcome
> ---
>
> Key: MNG-8062
> URL: https://issues.apache.org/jira/browse/MNG-8062
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-1
>
>
> Since closeable session in Resolver 2.0, the close was implemented, but any
> possible failure during closing the session would "bubble up", instead to be
> handled.
> Maven should close and also handle any error that may happen during session
> close operation. The build outcome ("build success" or "build failure") is
> evaluated WAY BEFORE repository system session is closed, and this is wrong,
> as build should fail if session close failed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8055) Investigate possible solutions for build number diffs on deploy
[
https://issues.apache.org/jira/browse/MNG-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8055:
-
Description:
The "snapshot freeze" is a common practice during development: simply use a
timestamped snapshot as dependency version instead of "-SNAPSHOT" ending one to
"freeze" given snapshot deploy.
This works for simple cases (one dependency, or "aligned" reactor).
But take a look at Resolver itself: it has new-old and added-gone-readded
modules, and their build numbers are different.
Problem is, that while timestamp is _same_ (deduced from session start), the
build number is determined from remote repository (deploy target) state.
This makes "snapshot lock down" impossible on long(er) running projects, like
Resolver itself is.
PR adds {{-Dmaven.buildNumber=N}} support, that is still just "half solution",
as one needs to figure out what N is (max+1 of all build numbers across all
modules being deployed), but at least allows fixing the situation.
was:
The "snapshot freeze" is a common practice during development: simply use a
timestamped snapshot as dependency version instead of "-SNAPSHOT" ending one to
"freeze" given snapshot deploy.
This works for simple cases (one dependency, or "aligned" reactor).
But take a look at Resolver itself: it has new-old and added-gone-readded
modules, and their build numbers are different.
Problem is, that while timestamp is _same_ (deduced from session start), the
build number is determined from remote repository (deploy target) state.
This makes "snapshot lock down" impossible on long(er) running projects, like
Resolver itself is.
> Investigate possible solutions for build number diffs on deploy
> ---
>
> Key: MNG-8055
> URL: https://issues.apache.org/jira/browse/MNG-8055
> Project: Maven
> Issue Type: Task
> Components: Artifacts and Repositories
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7
>
>
> The "snapshot freeze" is a common practice during development: simply use a
> timestamped snapshot as dependency version instead of "-SNAPSHOT" ending one
> to "freeze" given snapshot deploy.
> This works for simple cases (one dependency, or "aligned" reactor).
> But take a look at Resolver itself: it has new-old and added-gone-readded
> modules, and their build numbers are different.
> Problem is, that while timestamp is _same_ (deduced from session start), the
> build number is determined from remote repository (deploy target) state.
> This makes "snapshot lock down" impossible on long(er) running projects, like
> Resolver itself is.
> PR adds {{-Dmaven.buildNumber=N}} support, that is still just "half
> solution", as one needs to figure out what N is (max+1 of all build numbers
> across all modules being deployed), but at least allows fixing the situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-8111) Version 3.9.6 is not reproducible
[
https://issues.apache.org/jira/browse/MNG-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842281#comment-17842281
]
Tamas Cservenak edited comment on MNG-8111 at 4/30/24 7:59 AM:
---
That is strange, I just checked out maven-3.9.6 tag and rebuilt it w/o any
problem (Maven 3.9.6 and Maven 3.8.8 w/ Java 21.0.3 Temurin, Fedora 40).
was (Author: cstamas):
That is strange, I just checked out maven-3.9.6 tag and rebuilt it w/o any
problem (Maven 3.9.6, Java 21.0.3 Temurin, Fedora 40).
> Version 3.9.6 is not reproducible
> -
>
> Key: MNG-8111
> URL: https://issues.apache.org/jira/browse/MNG-8111
> Project: Maven
> Issue Type: Bug
> Components: Core, General
>Affects Versions: 3.9.6
> Environment: Arch Linux updated (29/04/2024)
>Reporter: Leonidas Spyropoulos
>Priority: Major
> Labels: reproducibility
> Attachments: maven-3.9.6-1-x86_64-build.log
>
>
> Version 3.9.6 is not reproducible. It seems like the compiled classes are
> different.
> - JDK used: OpenJDK version 8.412.u08
> - Command line used:
> {code:bash}
> mvn package \
> -DbuildNumber="bc0240f3c744dd6b6ec2920b3cd08dcc295161ae" \
> -Dline.separator=$'\r\n' \
> -Dproject.build.sourceEncoding=UTF-8 -e \
> -Dmaven.repo.local="./repo" \
> -DskipTests
> {code}
> buildNumber is found from:
> {code}
> bsdtar xOf <(bsdtar xOf apache-maven-3.9.6-bin.tar.gz
> apache-maven-3.9.6/lib/maven-core-3.9.6.jar) \
> org/apache/maven/messages/build.properties | grep buildNumber | cut -d=
> -f2 | tr -cd '[:print:]'
> {code}
> Relevant issue: https://issues.apache.org/jira/browse/MNG-6276
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-8111) Version 3.9.6 is not reproducible
[
https://issues.apache.org/jira/browse/MNG-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842281#comment-17842281
]
Tamas Cservenak edited comment on MNG-8111 at 4/30/24 8:00 AM:
---
That is strange, I just checked out maven-3.9.6 tag and rebuilt it twice w/o
any problem (Maven 3.9.6 and Maven 3.8.8 w/ Java 21.0.3 Temurin, Fedora 40).
was (Author: cstamas):
That is strange, I just checked out maven-3.9.6 tag and rebuilt it w/o any
problem (Maven 3.9.6 and Maven 3.8.8 w/ Java 21.0.3 Temurin, Fedora 40).
> Version 3.9.6 is not reproducible
> -
>
> Key: MNG-8111
> URL: https://issues.apache.org/jira/browse/MNG-8111
> Project: Maven
> Issue Type: Bug
> Components: Core, General
>Affects Versions: 3.9.6
> Environment: Arch Linux updated (29/04/2024)
>Reporter: Leonidas Spyropoulos
>Priority: Major
> Labels: reproducibility
> Attachments: maven-3.9.6-1-x86_64-build.log
>
>
> Version 3.9.6 is not reproducible. It seems like the compiled classes are
> different.
> - JDK used: OpenJDK version 8.412.u08
> - Command line used:
> {code:bash}
> mvn package \
> -DbuildNumber="bc0240f3c744dd6b6ec2920b3cd08dcc295161ae" \
> -Dline.separator=$'\r\n' \
> -Dproject.build.sourceEncoding=UTF-8 -e \
> -Dmaven.repo.local="./repo" \
> -DskipTests
> {code}
> buildNumber is found from:
> {code}
> bsdtar xOf <(bsdtar xOf apache-maven-3.9.6-bin.tar.gz
> apache-maven-3.9.6/lib/maven-core-3.9.6.jar) \
> org/apache/maven/messages/build.properties | grep buildNumber | cut -d=
> -f2 | tr -cd '[:print:]'
> {code}
> Relevant issue: https://issues.apache.org/jira/browse/MNG-6276
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8111) Version 3.9.6 is not reproducible
[
https://issues.apache.org/jira/browse/MNG-8111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842281#comment-17842281
]
Tamas Cservenak commented on MNG-8111:
--
That is strange, I just checked out maven-3.9.6 tag and rebuilt it w/o any
problem (Maven 3.9.6, Java 21.0.3 Temurin, Fedora 40).
> Version 3.9.6 is not reproducible
> -
>
> Key: MNG-8111
> URL: https://issues.apache.org/jira/browse/MNG-8111
> Project: Maven
> Issue Type: Bug
> Components: Core, General
>Affects Versions: 3.9.6
> Environment: Arch Linux updated (29/04/2024)
>Reporter: Leonidas Spyropoulos
>Priority: Major
> Labels: reproducibility
> Attachments: maven-3.9.6-1-x86_64-build.log
>
>
> Version 3.9.6 is not reproducible. It seems like the compiled classes are
> different.
> - JDK used: OpenJDK version 8.412.u08
> - Command line used:
> {code:bash}
> mvn package \
> -DbuildNumber="bc0240f3c744dd6b6ec2920b3cd08dcc295161ae" \
> -Dline.separator=$'\r\n' \
> -Dproject.build.sourceEncoding=UTF-8 -e \
> -Dmaven.repo.local="./repo" \
> -DskipTests
> {code}
> buildNumber is found from:
> {code}
> bsdtar xOf <(bsdtar xOf apache-maven-3.9.6-bin.tar.gz
> apache-maven-3.9.6/lib/maven-core-3.9.6.jar) \
> org/apache/maven/messages/build.properties | grep buildNumber | cut -d=
> -f2 | tr -cd '[:print:]'
> {code}
> Relevant issue: https://issues.apache.org/jira/browse/MNG-6276
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MPLUGIN-520) Get rid of maven-compat classes use
[ https://issues.apache.org/jira/browse/MPLUGIN-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MPLUGIN-520: --- Assignee: Tamas Cservenak > Get rid of maven-compat classes use > --- > > Key: MPLUGIN-520 > URL: https://issues.apache.org/jira/browse/MPLUGIN-520 > Project: Maven Plugin Tools > Issue Type: Improvement > Components: Plugin Plugin >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.12.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPLUGIN-520) Get rid of maven-compat classes use
Tamas Cservenak created MPLUGIN-520: --- Summary: Get rid of maven-compat classes use Key: MPLUGIN-520 URL: https://issues.apache.org/jira/browse/MPLUGIN-520 Project: Maven Plugin Tools Issue Type: Improvement Components: Plugin Plugin Reporter: Tamas Cservenak Fix For: 3.12.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MPLUGIN-519) Update to Parent POM 42, prerequisite 3.6.3
Tamas Cservenak created MPLUGIN-519: --- Summary: Update to Parent POM 42, prerequisite 3.6.3 Key: MPLUGIN-519 URL: https://issues.apache.org/jira/browse/MPLUGIN-519 Project: Maven Plugin Tools Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 3.12.1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MPLUGIN-519) Update to Parent POM 42, prerequisite 3.6.3
[ https://issues.apache.org/jira/browse/MPLUGIN-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MPLUGIN-519: --- Assignee: Tamas Cservenak > Update to Parent POM 42, prerequisite 3.6.3 > --- > > Key: MPLUGIN-519 > URL: https://issues.apache.org/jira/browse/MPLUGIN-519 > Project: Maven Plugin Tools > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.12.1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8109) Resolver 1.9.20
[ https://issues.apache.org/jira/browse/MNG-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-8109. Resolution: Fixed > Resolver 1.9.20 > --- > > Key: MNG-8109 > URL: https://issues.apache.org/jira/browse/MNG-8109 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.7 > > > Upgrade resolver to 1.9.20 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8070) Document Maven Runtime Requirement for Java 17
[ https://issues.apache.org/jira/browse/MNG-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-8070. Resolution: Fixed > Document Maven Runtime Requirement for Java 17 > -- > > Key: MNG-8070 > URL: https://issues.apache.org/jira/browse/MNG-8070 > Project: Maven > Issue Type: Task > Components: Documentation: General >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > > Followup for MNG-8061 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DOXIASITETOOLS-337) Move maven-compat to test scope
Tamas Cservenak created DOXIASITETOOLS-337: -- Summary: Move maven-compat to test scope Key: DOXIASITETOOLS-337 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-337 Project: Maven Doxia Sitetools Issue Type: Dependency upgrade Components: Integration Tools Reporter: Tamas Cservenak Fix For: 2.0.0 As maven-compat is not runtime/transitive dependency, is used in tests only. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-8109) Resolver 1.9.20
[ https://issues.apache.org/jira/browse/MNG-8109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-8109: Assignee: Tamas Cservenak > Resolver 1.9.20 > --- > > Key: MNG-8109 > URL: https://issues.apache.org/jira/browse/MNG-8109 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.7 > > > Upgrade resolver to 1.9.20 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8109) Resolver 1.9.20
Tamas Cservenak created MNG-8109: Summary: Resolver 1.9.20 Key: MNG-8109 URL: https://issues.apache.org/jira/browse/MNG-8109 Project: Maven Issue Type: Dependency upgrade Components: Artifacts and Repositories Reporter: Tamas Cservenak Fix For: 3.9.7 Upgrade resolver to 1.9.20 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8073) Generated XSD files needs to have AL2.0 license headers
[ https://issues.apache.org/jira/browse/MNG-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841263#comment-17841263 ] Tamas Cservenak commented on MNG-8073: -- Created [https://github.com/codehaus-plexus/modello/pull/437] Basically to have it done in simplest way. > Generated XSD files needs to have AL2.0 license headers > --- > > Key: MNG-8073 > URL: https://issues.apache.org/jira/browse/MNG-8073 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-13 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > > Currently we were adding them manually during release process. > Maybe also collecting them to single place would be handy, instead to "hunt > them down" in checkout post release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8073) Generated XSD files needs to have ASL2.0 license headers
[ https://issues.apache.org/jira/browse/MNG-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8073: - Summary: Generated XSD files needs to have ASL2.0 license headers (was: Generated XSD files needs to have AL2.0 license headers) > Generated XSD files needs to have ASL2.0 license headers > > > Key: MNG-8073 > URL: https://issues.apache.org/jira/browse/MNG-8073 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-13 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > > Currently we were adding them manually during release process. > Maybe also collecting them to single place would be handy, instead to "hunt > them down" in checkout post release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-8070) Document Maven Runtime Requirement for Java 17
[ https://issues.apache.org/jira/browse/MNG-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-8070: Assignee: Tamas Cservenak > Document Maven Runtime Requirement for Java 17 > -- > > Key: MNG-8070 > URL: https://issues.apache.org/jira/browse/MNG-8070 > Project: Maven > Issue Type: Task > Components: Documentation: General >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > > Followup for MNG-8061 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8070) Document Maven Runtime Requirement for Java 17
[ https://issues.apache.org/jira/browse/MNG-8070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8070: - Fix Version/s: 4.0.0 > Document Maven Runtime Requirement for Java 17 > -- > > Key: MNG-8070 > URL: https://issues.apache.org/jira/browse/MNG-8070 > Project: Maven > Issue Type: Task > Components: Documentation: General >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > > Followup for MNG-8061 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8038) Model builder API
[
https://issues.apache.org/jira/browse/MNG-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8038:
-
Fix Version/s: 4.0.0
> Model builder API
> -
>
> Key: MNG-8038
> URL: https://issues.apache.org/jira/browse/MNG-8038
> Project: Maven
> Issue Type: Improvement
> Components: API
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-1
>
>
> In some cases, it may be needed to access the _raw_ or the _effective_ model
> of artifacts downloaded from repositories (usually dependencies of the
> current project). The file model can already be read using the
> {{ModelXmlFactory}} but that's quite limited in scope.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8084) Make the v4 api usable outside the Maven runtime
[ https://issues.apache.org/jira/browse/MNG-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8084: - Fix Version/s: 4.0.0 > Make the v4 api usable outside the Maven runtime > > > Key: MNG-8084 > URL: https://issues.apache.org/jira/browse/MNG-8084 > Project: Maven > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8082) Exceptions of proxied SessionScoped components are not working correctly
[
https://issues.apache.org/jira/browse/MNG-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8082:
-
Fix Version/s: 4.0.0
> Exceptions of proxied SessionScoped components are not working correctly
>
>
> Key: MNG-8082
> URL: https://issues.apache.org/jira/browse/MNG-8082
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 4.0.0-alpha-13
>Reporter: Jonas Rutishauser
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0, 4.0.0-beta-1
>
>
> As the {{InvocationTargetException}} is not handled in the proxy a runtime
> exception will be wrapped by an {{InvocationTargetException}} and an
> application exception is additional wrapped by an
> {{UndeclaredThrowableException}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8106) Maven Metadata corruption if repository directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8106:
-
Fix Version/s: 4.0.0
> Maven Metadata corruption if repository directory role overlaps
> ---
>
> Key: MNG-8106
> URL: https://issues.apache.org/jira/browse/MNG-8106
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6,
> 4.0.0-alpha-2, 4.0.0-alpha-3, 4.0.0-alpha-4, 4.0.0-alpha-5, 4.0.0-alpha-7,
> 4.0.0-alpha-8, 4.0.0-alpha-9, 4.0.0-alpha-10, 4.0.0-alpha-12, 4.0.0-alpha-13
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0, 4.0.0-beta-1
>
>
> In case certain directory role in repository is manifold (which IS against
> best practices), data loss occurs. Metadata will contain this or that, but
> not both data.
> Example: consider project producing these artifacts
> * org.foo:bar:1.0
> * org.foo.bar:baz:1.0
> In this case, the local (and remote) repository path {{org/foo/bar}} that is
> a directory, will overlap in a way, it is G level for one artifact, and A
> level for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level
> should contain plugin related (G level) metadata. At the same time, due
> org.foo:bar this directory should contain A level metadata (list of
> versions). Affected maven versions will simply drop "the other" metadata (so
> if last deployed using this directory as G, the A data will be missing, and
> other way around).
> Have to note that doing this kind of naming is against "best practices", but
> still, can occur, for example in case of some refactoring/renaming of long
> running project modules.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8073) Generated XSD files needs to have AL2.0 license headers
[ https://issues.apache.org/jira/browse/MNG-8073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8073: - Fix Version/s: 4.0.0 > Generated XSD files needs to have AL2.0 license headers > --- > > Key: MNG-8073 > URL: https://issues.apache.org/jira/browse/MNG-8073 > Project: Maven > Issue Type: Task >Affects Versions: 4.0.0-alpha-13 >Reporter: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > > Currently we were adding them manually during release process. > Maybe also collecting them to single place would be handy, instead to "hunt > them down" in checkout post release. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8107) Upgrade to Resolver 2.0.0-alpha-11
[ https://issues.apache.org/jira/browse/MNG-8107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MNG-8107. Resolution: Fixed > Upgrade to Resolver 2.0.0-alpha-11 > -- > > Key: MNG-8107 > URL: https://issues.apache.org/jira/browse/MNG-8107 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MNG-8107) Upgrade to Resolver 2.0.0-alpha-11
[ https://issues.apache.org/jira/browse/MNG-8107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MNG-8107: Assignee: Tamas Cservenak > Upgrade to Resolver 2.0.0-alpha-11 > -- > > Key: MNG-8107 > URL: https://issues.apache.org/jira/browse/MNG-8107 > Project: Maven > Issue Type: Dependency upgrade > Components: Artifacts and Repositories >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 4.0.0, 4.0.0-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8107) Upgrade to Resolver 2.0.0-alpha-11
Tamas Cservenak created MNG-8107: Summary: Upgrade to Resolver 2.0.0-alpha-11 Key: MNG-8107 URL: https://issues.apache.org/jira/browse/MNG-8107 Project: Maven Issue Type: Dependency upgrade Components: Artifacts and Repositories Reporter: Tamas Cservenak Fix For: 4.0.0, 4.0.0-beta-1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7122) Require specific Maven compatibility version for plugins
[ https://issues.apache.org/jira/browse/MNG-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841190#comment-17841190 ] Tamas Cservenak edited comment on MNG-7122 at 4/26/24 12:10 PM: maven-compat is about to be removed from Maven4, so Maven2 plugins will just break. was (Author: cstamas): maven-compat is about to be removed from Maven4, so they will just break. > Require specific Maven compatibility version for plugins > > > Key: MNG-7122 > URL: https://issues.apache.org/jira/browse/MNG-7122 > Project: Maven > Issue Type: New Feature > Components: Plugins and Lifecycle >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 4.0.x-candidate > > > By removing the WagonExcluder (MNG-7020) it could mean that plugins that rely > on Maven2 dependencies might leak an old wagon-version onto the classpath. > Plugins can already define a prerequisite for the Maven version, but we also > need a mechanism to do it the other way around: plugins should at least > require maven dependencies of version x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7122) Require specific Maven compatibility version for plugins
[ https://issues.apache.org/jira/browse/MNG-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841190#comment-17841190 ] Tamas Cservenak commented on MNG-7122: -- maven-compat is about to be removed from Maven4, so they will just break. > Require specific Maven compatibility version for plugins > > > Key: MNG-7122 > URL: https://issues.apache.org/jira/browse/MNG-7122 > Project: Maven > Issue Type: New Feature > Components: Plugins and Lifecycle >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 4.0.x-candidate > > > By removing the WagonExcluder (MNG-7020) it could mean that plugins that rely > on Maven2 dependencies might leak an old wagon-version onto the classpath. > Plugins can already define a prerequisite for the Maven version, but we also > need a mechanism to do it the other way around: plugins should at least > require maven dependencies of version x. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-526) Import Eclipse Aether wiki content to Maven Site
[
https://issues.apache.org/jira/browse/MRESOLVER-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-526:
--
Fix Version/s: 2.0.0
2.0.0-beta-1
> Import Eclipse Aether wiki content to Maven Site
>
>
> Key: MRESOLVER-526
> URL: https://issues.apache.org/jira/browse/MRESOLVER-526
> Project: Maven Resolver
> Issue Type: Task
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: 2.0.0, 2.0.0-beta-1
>
> Attachments: EclipseAetherWikiExportAsMD.zip,
> Eclipsepedia-20240410130147.xml
>
>
> As the Eclipse wiki is gonna be shutdown soon the content currently only
> available on https://wiki.eclipse.org/Aether (and other pages with category
> {{Aether}}) should be migrated to the resolver site.
> The steps for exporting and converting to Markdown are outlined at
> https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-Move-FAQ.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-553) Undo site redirection
[ https://issues.apache.org/jira/browse/MRESOLVER-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-553: -- Fix Version/s: 2.0.0 > Undo site redirection > - > > Key: MRESOLVER-553 > URL: https://issues.apache.org/jira/browse/MRESOLVER-553 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-beta-1 > > > Undo MRESOLVER-552 as it was done when 1.x was already staged and on vote. > It is actually 1.x that should go LATEST-1.x -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-553) Undo site redirection
Tamas Cservenak created MRESOLVER-553: - Summary: Undo site redirection Key: MRESOLVER-553 URL: https://issues.apache.org/jira/browse/MRESOLVER-553 Project: Maven Resolver Issue Type: Task Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0-beta-1 Undo MRESOLVER-552 as it was done when 1.x was already staged and on vote. It is actually 1.x that should go LATEST-1.x -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-552) Redirect site creation to enable concurrent release of 1.x and 2.x resolver
[
https://issues.apache.org/jira/browse/MRESOLVER-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MRESOLVER-552.
-
Resolution: Fixed
> Redirect site creation to enable concurrent release of 1.x and 2.x resolver
> ---
>
> Key: MRESOLVER-552
> URL: https://issues.apache.org/jira/browse/MRESOLVER-552
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-11
>
>
> Basically just append and make it {{LATEST-2.x}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-552) Redirect site creation to enable concurrent release of 1.x and 2.x resolver
[
https://issues.apache.org/jira/browse/MRESOLVER-552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MRESOLVER-552:
-
Assignee: Tamas Cservenak
> Redirect site creation to enable concurrent release of 1.x and 2.x resolver
> ---
>
> Key: MRESOLVER-552
> URL: https://issues.apache.org/jira/browse/MRESOLVER-552
> Project: Maven Resolver
> Issue Type: Task
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0, 2.0.0-alpha-11
>
>
> Basically just append and make it {{LATEST-2.x}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MRESOLVER-542) Reduce usage of final classes
[ https://issues.apache.org/jira/browse/MRESOLVER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-542. - Resolution: Fixed > Reduce usage of final classes > - > > Key: MRESOLVER-542 > URL: https://issues.apache.org/jira/browse/MRESOLVER-542 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > > Historically, Resolver APIs were exposed via Maven (were kinda part of Maven > API in Maven3) and they went long run to keep boundaries what users can do. > One of these examples is overuse of `final` classes. > Main goal was to make GenericVersionScheme not final, also perform some > cleanup. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-552) Redirect site creation to enable concurrent release of 1.x and 2.x resolver
Tamas Cservenak created MRESOLVER-552:
-
Summary: Redirect site creation to enable concurrent release of
1.x and 2.x resolver
Key: MRESOLVER-552
URL: https://issues.apache.org/jira/browse/MRESOLVER-552
Project: Maven Resolver
Issue Type: Task
Components: Resolver
Reporter: Tamas Cservenak
Fix For: 2.0.0, 2.0.0-alpha-11
Basically just append and make it {{LATEST-2.x}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-542) Reduce usage of final classes
[ https://issues.apache.org/jira/browse/MRESOLVER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-542: -- Description: Historically, Resolver APIs were exposed via Maven (were kinda part of Maven API in Maven3) and they went long run to keep boundaries what users can do. One of these examples is overuse of `final` classes. Main goal was to make GenericVersionScheme not final, also perform some cleanup. was:Historically, Resolver APIs were exposed via Maven (were kinda part of Maven API in Maven3) and they went long run to keep boundaries what users can do. One of these examples is overuse of `final` classes. > Reduce usage of final classes > - > > Key: MRESOLVER-542 > URL: https://issues.apache.org/jira/browse/MRESOLVER-542 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > > Historically, Resolver APIs were exposed via Maven (were kinda part of Maven > API in Maven3) and they went long run to keep boundaries what users can do. > One of these examples is overuse of `final` classes. > Main goal was to make GenericVersionScheme not final, also perform some > cleanup. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-550) Bump Redisson from 3.28.0 to 3.29.0
[ https://issues.apache.org/jira/browse/MRESOLVER-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-550. - Resolution: Fixed > Bump Redisson from 3.28.0 to 3.29.0 > --- > > Key: MRESOLVER-550 > URL: https://issues.apache.org/jira/browse/MRESOLVER-550 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.20 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-551) (build) Bump japicmp from 0.17.2 to 0.21.1
[ https://issues.apache.org/jira/browse/MRESOLVER-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-551. - Resolution: Fixed > (build) Bump japicmp from 0.17.2 to 0.21.1 > -- > > Key: MRESOLVER-551 > URL: https://issues.apache.org/jira/browse/MRESOLVER-551 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.20 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-549) Use parent POM 42
[ https://issues.apache.org/jira/browse/MRESOLVER-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-549. - Resolution: Fixed > Use parent POM 42 > - > > Key: MRESOLVER-549 > URL: https://issues.apache.org/jira/browse/MRESOLVER-549 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.20 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
[ https://issues.apache.org/jira/browse/MRESOLVER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-547: -- Issue Type: Bug (was: Improvement) > BF collector always copies artifacts, even when it should not > - > > Key: MRESOLVER-547 > URL: https://issues.apache.org/jira/browse/MRESOLVER-547 > Project: Maven Resolver > Issue Type: Bug > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11, 1.9.20 > > > Artifact instances are always copied, even when they should not be. > https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-550) Bump Redisson from 3.28.0 to 3.29.0
[ https://issues.apache.org/jira/browse/MRESOLVER-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-550: - Assignee: Tamas Cservenak > Bump Redisson from 3.28.0 to 3.29.0 > --- > > Key: MRESOLVER-550 > URL: https://issues.apache.org/jira/browse/MRESOLVER-550 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.20 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-551) (build) Bump japicmp from 0.17.2 to 0.21.1
[ https://issues.apache.org/jira/browse/MRESOLVER-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-551: - Assignee: Tamas Cservenak > (build) Bump japicmp from 0.17.2 to 0.21.1 > -- > > Key: MRESOLVER-551 > URL: https://issues.apache.org/jira/browse/MRESOLVER-551 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.20 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-549) Use parent POM 42
[ https://issues.apache.org/jira/browse/MRESOLVER-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-549: - Assignee: Tamas Cservenak > Use parent POM 42 > - > > Key: MRESOLVER-549 > URL: https://issues.apache.org/jira/browse/MRESOLVER-549 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.20 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-550) Bump Redisson from 3.28.0 to 3.29.0
Tamas Cservenak created MRESOLVER-550: - Summary: Bump Redisson from 3.28.0 to 3.29.0 Key: MRESOLVER-550 URL: https://issues.apache.org/jira/browse/MRESOLVER-550 Project: Maven Resolver Issue Type: Dependency upgrade Components: Resolver Reporter: Tamas Cservenak Fix For: 1.9.20 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-551) (build) Bump japicmp from 0.17.2 to 0.21.1
Tamas Cservenak created MRESOLVER-551: - Summary: (build) Bump japicmp from 0.17.2 to 0.21.1 Key: MRESOLVER-551 URL: https://issues.apache.org/jira/browse/MRESOLVER-551 Project: Maven Resolver Issue Type: Dependency upgrade Components: Resolver Reporter: Tamas Cservenak Fix For: 1.9.20 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-499) IPC Named Locks
[ https://issues.apache.org/jira/browse/MRESOLVER-499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-499: -- Fix Version/s: (was: 2.0.0-alpha-11) > IPC Named Locks > --- > > Key: MRESOLVER-499 > URL: https://issues.apache.org/jira/browse/MRESOLVER-499 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Create IPC named locks implementation. Depends on MRESOLVER-421. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-549) Use parent POM 42
Tamas Cservenak created MRESOLVER-549: - Summary: Use parent POM 42 Key: MRESOLVER-549 URL: https://issues.apache.org/jira/browse/MRESOLVER-549 Project: Maven Resolver Issue Type: Dependency upgrade Components: Resolver Reporter: Tamas Cservenak Fix For: 1.9.20 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
[ https://issues.apache.org/jira/browse/MRESOLVER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-547. - Resolution: Fixed > BF collector always copies artifacts, even when it should not > - > > Key: MRESOLVER-547 > URL: https://issues.apache.org/jira/browse/MRESOLVER-547 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11, 1.9.20 > > > Artifact instances are always copied, even when they should not be. > https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-548) Artifact path/file improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-548. - Resolution: Won't Fix > Artifact path/file improvements > --- > > Key: MRESOLVER-548 > URL: https://issues.apache.org/jira/browse/MRESOLVER-548 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-548) Artifact path/file improvements
[ https://issues.apache.org/jira/browse/MRESOLVER-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-548: -- Fix Version/s: (was: 2.0.0) (was: 2.0.0-alpha-11) > Artifact path/file improvements > --- > > Key: MRESOLVER-548 > URL: https://issues.apache.org/jira/browse/MRESOLVER-548 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MGPG-128) Update to parent POM 42, prerequisite 3.6.3
[ https://issues.apache.org/jira/browse/MGPG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MGPG-128. Resolution: Fixed > Update to parent POM 42, prerequisite 3.6.3 > --- > > Key: MGPG-128 > URL: https://issues.apache.org/jira/browse/MGPG-128 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.2.5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
[ https://issues.apache.org/jira/browse/MRESOLVER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-547: - Assignee: Tamas Cservenak > BF collector always copies artifacts, even when it should not > - > > Key: MRESOLVER-547 > URL: https://issues.apache.org/jira/browse/MRESOLVER-547 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11, 1.9.20 > > > Artifact instances are always copied, even when they should not be. > https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
[ https://issues.apache.org/jira/browse/MRESOLVER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-547: -- Fix Version/s: 1.9.20 > BF collector always copies artifacts, even when it should not > - > > Key: MRESOLVER-547 > URL: https://issues.apache.org/jira/browse/MRESOLVER-547 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11, 1.9.20 > > > Artifact instances are always copied, even when they should not be. > https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-548) Artifact path/file improvements
Tamas Cservenak created MRESOLVER-548: - Summary: Artifact path/file improvements Key: MRESOLVER-548 URL: https://issues.apache.org/jira/browse/MRESOLVER-548 Project: Maven Resolver Issue Type: Improvement Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-alpha-11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-547) BF collector always copies artifacts, even when it should not
Tamas Cservenak created MRESOLVER-547: - Summary: BF collector always copies artifacts, even when it should not Key: MRESOLVER-547 URL: https://issues.apache.org/jira/browse/MRESOLVER-547 Project: Maven Resolver Issue Type: Improvement Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-alpha-11 Artifact instances are always copied, even when they should not be. https://github.com/apache/maven-resolver/blob/9c2e5a1d29254d1c3b49dd25dca310c0cec8e1f6/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/bf/BfDependencyCollector.java#L454 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper type
[ https://issues.apache.org/jira/browse/MWRAPPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MWRAPPER-135: - Summary: Provide a reliable way to determine the Maven Wrapper type (was: Provide a reliable way to determine the Maven Wrapper version) > Provide a reliable way to determine the Maven Wrapper type > -- > > Key: MWRAPPER-135 > URL: https://issues.apache.org/jira/browse/MWRAPPER-135 > Project: Maven Wrapper > Issue Type: Task > Components: Maven Wrapper Plugin >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.3.2 > > > Just like MWRAPPER-134 but for type. I completely forgot about this. As this > way, tooling can figure out not only version but type (also for humans, just > peek at properties). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MWRAPPER-135) Provide a reliable way to determine the Maven Wrapper version
Tamas Cservenak created MWRAPPER-135: Summary: Provide a reliable way to determine the Maven Wrapper version Key: MWRAPPER-135 URL: https://issues.apache.org/jira/browse/MWRAPPER-135 Project: Maven Wrapper Issue Type: Task Components: Maven Wrapper Plugin Reporter: Tamas Cservenak Fix For: 3.3.2 Just like MWRAPPER-134 but for type. I completely forgot about this. As this way, tooling can figure out not only version but type (also for humans, just peek at properties). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8100) Upgrade default plugin bindings
[
https://issues.apache.org/jira/browse/MNG-8100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MNG-8100:
-
Component/s: Plugins and Lifecycle
> Upgrade default plugin bindings
> ---
>
> Key: MNG-8100
> URL: https://issues.apache.org/jira/browse/MNG-8100
> Project: Maven
> Issue Type: Dependency upgrade
> Components: Plugins and Lifecycle
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.9.7
>
>
> {noformat}
> 3.9.x
> compiler3.11.0 -> 3.13.0
> surefire3.2.2 -> 3.2.5
> jar 3.3.0 -> 3.4.1
> plugin 3.9.0 -> 3.12.0
> 4.x
> compiler3.11.0 -> 3.13.0
> surefire3.1.2 -> 3.2.5
> jar 3.3.0 -> 3.4.1
> plugin 3.9.0 -> 3.12.0
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8101) Upgrade Parent to 42
[ https://issues.apache.org/jira/browse/MNG-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MNG-8101: - Component/s: Bootstrap & Build > Upgrade Parent to 42 > > > Key: MNG-8101 > URL: https://issues.apache.org/jira/browse/MNG-8101 > Project: Maven > Issue Type: Dependency upgrade > Components: Bootstrap Build >Reporter: Slawomir Jaranowski >Assignee: Slawomir Jaranowski >Priority: Major > Fix For: 3.9.7 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8106) Maven Metadata corruption if repository directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MNG-8106.
Resolution: Fixed
> Maven Metadata corruption if repository directory role overlaps
> ---
>
> Key: MNG-8106
> URL: https://issues.apache.org/jira/browse/MNG-8106
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.9.0, 3.9.1, 3.9.2, 3.9.3, 3.9.4, 3.9.5, 3.9.6,
> 4.0.0-alpha-2, 4.0.0-alpha-3, 4.0.0-alpha-4, 4.0.0-alpha-5, 4.0.0-alpha-7,
> 4.0.0-alpha-8, 4.0.0-alpha-9, 4.0.0-alpha-10, 4.0.0-alpha-12, 4.0.0-alpha-13
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role in repository is manifold (which IS against
> best practices), data loss occurs. Metadata will contain this or that, but
> not both data.
> Example: consider project producing these artifacts
> * org.foo:bar:1.0
> * org.foo.bar:baz:1.0
> In this case, the local (and remote) repository path {{org/foo/bar}} that is
> a directory, will overlap in a way, it is G level for one artifact, and A
> level for another. Now, if org.foo.bar:baz is a Maven Plugin, the G level
> should contain plugin related (G level) metadata. At the same time, due
> org.foo:bar this directory should contain A level metadata (list of
> versions). Affected maven versions will simply drop "the other" metadata (so
> if last deployed using this directory as G, the A data will be missing, and
> other way around).
> Have to note that doing this kind of naming is against "best practices", but
> still, can occur, for example in case of some refactoring/renaming of long
> running project modules.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MGPG-128) Update to parent POM 42, prerequisite 3.6.3
[ https://issues.apache.org/jira/browse/MGPG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MGPG-128: - Summary: Update to parent POM 42, prerequisite 3.6.3 (was: Update to parent POM 42) > Update to parent POM 42, prerequisite 3.6.3 > --- > > Key: MGPG-128 > URL: https://issues.apache.org/jira/browse/MGPG-128 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.2.5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MGPG-128) Update to parent POM 42
Tamas Cservenak created MGPG-128: Summary: Update to parent POM 42 Key: MGPG-128 URL: https://issues.apache.org/jira/browse/MGPG-128 Project: Maven GPG Plugin Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 3.2.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MGPG-128) Update to parent POM 42
[ https://issues.apache.org/jira/browse/MGPG-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MGPG-128: Assignee: Tamas Cservenak > Update to parent POM 42 > --- > > Key: MGPG-128 > URL: https://issues.apache.org/jira/browse/MGPG-128 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.2.5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MGPG-127) Bump bouncycastleVersion from 1.78 to 1.78.1
[ https://issues.apache.org/jira/browse/MGPG-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MGPG-127: Assignee: Tamas Cservenak > Bump bouncycastleVersion from 1.78 to 1.78.1 > > > Key: MGPG-127 > URL: https://issues.apache.org/jira/browse/MGPG-127 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.2.5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MGPG-127) Bump bouncycastleVersion from 1.78 to 1.78.1
[ https://issues.apache.org/jira/browse/MGPG-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MGPG-127. Resolution: Fixed > Bump bouncycastleVersion from 1.78 to 1.78.1 > > > Key: MGPG-127 > URL: https://issues.apache.org/jira/browse/MGPG-127 > Project: Maven GPG Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.2.5 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MGPG-127) Bump bouncycastleVersion from 1.78 to 1.78.1
Tamas Cservenak created MGPG-127: Summary: Bump bouncycastleVersion from 1.78 to 1.78.1 Key: MGPG-127 URL: https://issues.apache.org/jira/browse/MGPG-127 Project: Maven GPG Plugin Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 3.2.5 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-546) Bump org.codehaus.plexus:plexus-utils from 4.0.0 to 4.0.1
Tamas Cservenak created MRESOLVER-546: - Summary: Bump org.codehaus.plexus:plexus-utils from 4.0.0 to 4.0.1 Key: MRESOLVER-546 URL: https://issues.apache.org/jira/browse/MRESOLVER-546 Project: Maven Resolver Issue Type: Dependency upgrade Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0, 2.0.0-alpha-11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-546) Bump org.codehaus.plexus:plexus-utils from 4.0.0 to 4.0.1
[ https://issues.apache.org/jira/browse/MRESOLVER-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-546. - Resolution: Fixed > Bump org.codehaus.plexus:plexus-utils from 4.0.0 to 4.0.1 > - > > Key: MRESOLVER-546 > URL: https://issues.apache.org/jira/browse/MRESOLVER-546 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-546) Bump org.codehaus.plexus:plexus-utils from 4.0.0 to 4.0.1
[ https://issues.apache.org/jira/browse/MRESOLVER-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-546: - Assignee: Tamas Cservenak > Bump org.codehaus.plexus:plexus-utils from 4.0.0 to 4.0.1 > - > > Key: MRESOLVER-546 > URL: https://issues.apache.org/jira/browse/MRESOLVER-546 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-543) (build) Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.20.0 to 0.21.1
[ https://issues.apache.org/jira/browse/MRESOLVER-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-543. - Resolution: Fixed > (build) Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.20.0 to > 0.21.1 > - > > Key: MRESOLVER-543 > URL: https://issues.apache.org/jira/browse/MRESOLVER-543 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-544) Bump org.redisson:redisson from 3.28.0 to 3.29.0
[ https://issues.apache.org/jira/browse/MRESOLVER-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-544: - Assignee: Tamas Cservenak > Bump org.redisson:redisson from 3.28.0 to 3.29.0 > > > Key: MRESOLVER-544 > URL: https://issues.apache.org/jira/browse/MRESOLVER-544 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-544) Bump org.redisson:redisson from 3.28.0 to 3.29.0
[ https://issues.apache.org/jira/browse/MRESOLVER-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-544. - Resolution: Fixed > Bump org.redisson:redisson from 3.28.0 to 3.29.0 > > > Key: MRESOLVER-544 > URL: https://issues.apache.org/jira/browse/MRESOLVER-544 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-545) Bump bouncycastleVersion from 1.78 to 1.78.1
[ https://issues.apache.org/jira/browse/MRESOLVER-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-545: - Assignee: Tamas Cservenak > Bump bouncycastleVersion from 1.78 to 1.78.1 > > > Key: MRESOLVER-545 > URL: https://issues.apache.org/jira/browse/MRESOLVER-545 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-543) (build) Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.20.0 to 0.21.1
[ https://issues.apache.org/jira/browse/MRESOLVER-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-543: - Assignee: Tamas Cservenak > (build) Bump com.github.siom79.japicmp:japicmp-maven-plugin from 0.20.0 to > 0.21.1 > - > > Key: MRESOLVER-543 > URL: https://issues.apache.org/jira/browse/MRESOLVER-543 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-545) Bump bouncycastleVersion from 1.78 to 1.78.1
[ https://issues.apache.org/jira/browse/MRESOLVER-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-545. - Resolution: Fixed > Bump bouncycastleVersion from 1.78 to 1.78.1 > > > Key: MRESOLVER-545 > URL: https://issues.apache.org/jira/browse/MRESOLVER-545 > Project: Maven Resolver > Issue Type: Dependency upgrade > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0, 2.0.0-alpha-11 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
