Re: [PR] Bump resolverVersion from 1.4.1 to 1.9.19 [maven-dependency-plugin]
slawekjaranowski commented on PR #384: URL: https://github.com/apache/maven-dependency-plugin/pull/384#issuecomment-2074219070 @dependabot ignore this dependency -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump resolverVersion from 1.4.1 to 1.9.19 [maven-dependency-plugin]
dependabot[bot] closed pull request #384: Bump resolverVersion from 1.4.1 to 1.9.19 URL: https://github.com/apache/maven-dependency-plugin/pull/384 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump resolverVersion from 1.4.1 to 1.9.19 [maven-dependency-plugin]
dependabot[bot] commented on PR #384: URL: https://github.com/apache/maven-dependency-plugin/pull/384#issuecomment-2074219206 OK, I won't notify you about any of these dependencies again, unless you re-open this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump mavenVersion from 3.6.3 to 3.9.6 [maven-dependency-plugin]
slawekjaranowski commented on PR #385: URL: https://github.com/apache/maven-dependency-plugin/pull/385#issuecomment-2074219659 @dependabot ignore this dependency -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump mavenVersion from 3.6.3 to 3.9.6 [maven-dependency-plugin]
dependabot[bot] closed pull request #385: Bump mavenVersion from 3.6.3 to 3.9.6 URL: https://github.com/apache/maven-dependency-plugin/pull/385 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump mavenVersion from 3.6.3 to 3.9.6 [maven-dependency-plugin]
dependabot[bot] commented on PR #385: URL: https://github.com/apache/maven-dependency-plugin/pull/385#issuecomment-2074219747 OK, I won't notify you about any of these dependencies again, unless you re-open this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MBUILDCACHE-86] bugfix / enhancements restoration of outputs on disk [maven-build-cache-extension]
hboutemy commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2074220142 > some "weird" pom files oh, this is Maven 4 consumer POMs, that seem to have been generated with random file names @gnodet do we really want these random file names? Do we need to create a hack in build cache extension to manage this randomness? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MBUILDCACHE-86) Bugfix and enhancements with the restoration of outputs on disk
[ https://issues.apache.org/jira/browse/MBUILDCACHE-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840304#comment-17840304 ] ASF GitHub Bot commented on MBUILDCACHE-86: --- hboutemy commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2074220142 > some "weird" pom files oh, this is Maven 4 consumer POMs, that seem to have been generated with random file names @gnodet do we really want these random file names? Do we need to create a hack in build cache extension to manage this randomness? > Bugfix and enhancements with the restoration of outputs on disk > --- > > Key: MBUILDCACHE-86 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-86 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Kevin Buntrock >Priority: Major > Labels: pull-request-available > > *Fixes :* > * Files containing an underscore in their name can't be restored in the > cache directory correctly (not in the same directory location). > * The cache is able to extract/restore files in locations outside the > project. I guess the extraction part is not a vulnerability since someone > with commit permissions can guess other ways to extract data. But the > possibility of restoring at any place on the disk looks pretty dangerous to > me if a remote cache server is compromised. > *Enhancements :* > * Possibility to restore artefacts on disk, with a dedicated property : > maven.build.cache.restoreOnDiskArtefacts (default to true). Meaning in the > project directory, as opposed to the cache directory. > ** IDE integration and use of the cache locally in developement is way > easier. It is now possible to retrieve a cached jar in the "target" directory. > * Introduce "globs" to filter extra attached outputs by filenames. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-8084] add di & api-impl [maven]
gnodet commented on PR #1461: URL: https://github.com/apache/maven/pull/1461#issuecomment-2074304566 > I'm happy to update it if you tell me what remains to do: it's just a small update of an OpenOffice document, save as .svg and run the update `prepare-svg.sh` script > > > It's not readable unfortunately, but it started from generated graph, so it's correct with current master. > > BTW, I'd be interested to be able to create this type of automatic drawing as a reference `mvn org.fusesource.mvnplugins:maven-graph-plugin:reactor` does render something automatically...  -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-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:comment-tabpanel&focusedCommentId=17840320#comment-17840320 ] ASF GitHub Bot commented on MNG-8084: - gnodet commented on PR #1461: URL: https://github.com/apache/maven/pull/1461#issuecomment-2074304566 > I'm happy to update it if you tell me what remains to do: it's just a small update of an OpenOffice document, save as .svg and run the update `prepare-svg.sh` script > > > It's not readable unfortunately, but it started from generated graph, so it's correct with current master. > > BTW, I'd be interested to be able to create this type of automatic drawing as a reference `mvn org.fusesource.mvnplugins:maven-graph-plugin:reactor` does render something automatically...  > 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-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-8084] add di & api-impl [maven]
gnodet commented on PR #1461: URL: https://github.com/apache/maven/pull/1461#issuecomment-2074335291 > > I'm happy to update it if you tell me what remains to do: it's just a small update of an OpenOffice document, save as .svg and run the update `prepare-svg.sh` script > > > It's not readable unfortunately, but it started from generated graph, so it's correct with current master. > > > > > > BTW, I'd be interested to be able to create this type of automatic drawing as a reference > `mvn org.fusesource.mvnplugins:maven-graph-plugin:reactor -Dhide-version -Dhide-group-id -Dhide-scope=test -Dhide-transitive` gives the following:  -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-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:comment-tabpanel&focusedCommentId=17840324#comment-17840324 ] ASF GitHub Bot commented on MNG-8084: - gnodet commented on PR #1461: URL: https://github.com/apache/maven/pull/1461#issuecomment-2074335291 > > I'm happy to update it if you tell me what remains to do: it's just a small update of an OpenOffice document, save as .svg and run the update `prepare-svg.sh` script > > > It's not readable unfortunately, but it started from generated graph, so it's correct with current master. > > > > > > BTW, I'd be interested to be able to create this type of automatic drawing as a reference > `mvn org.fusesource.mvnplugins:maven-graph-plugin:reactor -Dhide-version -Dhide-group-id -Dhide-scope=test -Dhide-transitive` gives the following:  > 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-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINSTALL-195) Include artifactId in messages of InstallMojo#processProject
[
https://issues.apache.org/jira/browse/MINSTALL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MINSTALL-195:
-
Fix Version/s: 3.1.2
> Include artifactId in messages of InstallMojo#processProject
>
>
> Key: MINSTALL-195
> URL: https://issues.apache.org/jira/browse/MINSTALL-195
> Project: Maven Install Plugin
> Issue Type: Improvement
> Components: install:install
>Affects Versions: 3.1.1
>Reporter: András Péteri
>Priority: Major
> Fix For: 3.1.2
>
>
> A companion request for MDEPLOY-314: if an issue is encountered in "install
> at end" mode in the method mentioned in the title, the {{project}} method
> argument's artifact ID should be mentioned as it might not be the same as the
> {{project}} parameter on the class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINSTALL-193) Upgrade Parent Version 42
[ https://issues.apache.org/jira/browse/MINSTALL-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MINSTALL-193: - Summary: Upgrade Parent Version 42 (was: Upgrade Parent Version 40) > Upgrade Parent Version 42 > - > > Key: MINSTALL-193 > URL: https://issues.apache.org/jira/browse/MINSTALL-193 > Project: Maven Install Plugin > Issue Type: Task >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINSTALL-190) Fix Temporary File Information Disclosure Vulnerability
[ https://issues.apache.org/jira/browse/MINSTALL-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MINSTALL-190. Resolution: Fixed Fixed with https://github.com/apache/maven-install-plugin/pull/61 > Fix Temporary File Information Disclosure Vulnerability > --- > > Key: MINSTALL-190 > URL: https://issues.apache.org/jira/browse/MINSTALL-190 > Project: Maven Install Plugin > Issue Type: Bug >Reporter: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.1.2 > > > https://github.com/apache/maven-install-plugin/pull/47 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MBUILDCACHE-86] bugfix / enhancements restoration of outputs on disk [maven-build-cache-extension]
kbuntrock commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2074391072 > > some "weird" pom files > > oh, this is Maven 4 consumer POMs, that seem to have been generated with random file names > > @gnodet do we really want these random file names? Do we need to create a hack in build cache extension to manage this randomness? To add a bit of context, I did some experiment yesterday evening. Here are some extract of the file `buildinfo.xml` after the execution of the goal package in different contexts: ### Test "IncrementalRestoreTest", on this branch: ```xml package org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT jar mbuildcache-incremental.jar 887c667918b9b71d 3119 target/mbuildcache-incremental-final.jar org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT consumer pom mbuildcache-incremental-consumer.pom bf52cc397806673a 430 target/consumer-4676390733155918308.pom ``` ### Test "IncrementalRestoreTest", on the branch master: ```xml package org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT jar mbuildcache-incremental.jar 41e8d89e0385f771 3119 org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT consumer pom mbuildcache-incremental-consumer.pom bf52cc397806673a 430 ``` ### On a standalone project based on "IncrementalRestoreTest", with the extension code of this branch: ```xml package org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT jar mbuildcache-incremental.jar 8d6a9a9795c1f249 3122 target/mbuildcache-incremental-final.jar ``` Meaning that: - It might be linked to the IT execution context - It is not related to this PR, so I will focus on updating the current tests and put this problem aside. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MBUILDCACHE-86) Bugfix and enhancements with the restoration of outputs on disk
[ https://issues.apache.org/jira/browse/MBUILDCACHE-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840338#comment-17840338 ] ASF GitHub Bot commented on MBUILDCACHE-86: --- kbuntrock commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2074391072 > > some "weird" pom files > > oh, this is Maven 4 consumer POMs, that seem to have been generated with random file names > > @gnodet do we really want these random file names? Do we need to create a hack in build cache extension to manage this randomness? To add a bit of context, I did some experiment yesterday evening. Here are some extract of the file `buildinfo.xml` after the execution of the goal package in different contexts: ### Test "IncrementalRestoreTest", on this branch: ```xml package org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT jar mbuildcache-incremental.jar 887c667918b9b71d 3119 target/mbuildcache-incremental-final.jar org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT consumer pom mbuildcache-incremental-consumer.pom bf52cc397806673a 430 target/consumer-4676390733155918308.pom ``` ### Test "IncrementalRestoreTest", on the branch master: ```xml package org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT jar mbuildcache-incremental.jar 41e8d89e0385f771 3119 org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT consumer pom mbuildcache-incremental-consumer.pom bf52cc397806673a 430 ``` ### On a standalone project based on "IncrementalRestoreTest", with the extension code of this branch: ```xml package org.apache.maven.caching.test mbuildcache-incremental 0.0.1-SNAPSHOT jar mbuildcache-incremental.jar 8d6a9a9795c1f249 3122 target/mbuildcache-incremental-final.jar ``` Meaning that: - It might be linked to the IT execution context - It is not related to this PR, so I will focus on updating the current tests and put this problem aside. > Bugfix and enhancements with the restoration of outputs on disk > --- > > Key: MBUILDCACHE-86 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-86 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Kevin Buntrock >Priority: Major > Labels: pull-request-available > > *Fixes :* > * Files containing an underscore in their name can't be restored in the > cache directory correctly (not in the same directory location). > * The cache is able to extract/restore files in locations outside the > project. I guess the extraction part is not a vulnerability since someone > with commit permissions can guess other ways to extract data. But the > possibility of restoring at any place on the disk looks pretty dangerous to > me if a remote cache server is compromised. > *Enhancements :* > * Possibility to restore artefacts on disk, with a dedicated property : > maven.build.cache.restoreOnDiskArtefacts (default to true). Meaning in the > project directory, as opposed to the cache directory. > ** IDE integration and use of the cache locally in developement is way > easier. It is now possible to retrieve a cached jar in the "target" directory. > * Introduce "globs" to filter extra attached outputs by filenames. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINSTALL-191) Metadata for submodules seems to be incomplete
[
https://issues.apache.org/jira/browse/MINSTALL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840341#comment-17840341
]
Tamas Cservenak commented on MINSTALL-191:
--
This is a user mistake, and cannot be supported well by Maven repository
layout, hence, these things should be avoided. The example project has 3
artifacts:
{noformat}
at.dvallant.maven:maven-install-plugin-bug:0.1.0-SNAPSHOT (root/parent POM)
at.dvallant.maven:plugins:0.1.0-SNAPSHOT
at.dvalland.maven.plugins:my-maven-plugin:0.1.0-SNAPSHOT{noformat}
Clearly can be seen, that the two overlap: {{at.dwallant.maven:plugins}} (GA)
and {{at.dvallant.maven.plugins}} (G). This means that on disk (mapped by
layout) this directory contains once G level metadata (for
at.dvalland.maven.plugins:my-maven-plugin plugin) and once A level metadata
(for at.dvallant.maven:plugins artifact). These situations should be avoided.
> Metadata for submodules seems to be incomplete
> --
>
> Key: MINSTALL-191
> URL: https://issues.apache.org/jira/browse/MINSTALL-191
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 3.0.0-M1, 3.0.0, 3.1.0, 3.1.1
> Environment: Apache Maven 3.8.8
> (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Java version: 11.0.18, vendor: Eclipse Adoptium
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-83-generic", arch: "amd64", family: "unix"
>Reporter: Dorian Vallant
>Priority: Major
> Attachments: maven-install-plugin-bug.tgz
>
>
> maven-install-plugin 3.x (and maven-deploy-plugin 3.x too) seems to have a
> bug when generating maven-metadata-*.xml for submodules containing custom
> maven-plugins.
> With version 2.5.2 maven-install-plugin generates the local metadata as
> follows:
> {code:xml}
>
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082036
>
>
>
> my-maven-plugin
> my
> my-maven-plugin
>
>
>
> {code}
>
> After upgrading to 3.1.1 (also testet with 3.0.0-M1, 3.0.0 and 3.1.0) the
> generated file looks this:
> {code:xml}
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082207
>
>
> {code}
> A test-project to reproduce the issue is attached.
> To reproduce build the project by calling `mvn clean install` and then check
> the contents of
> `~/.m2/repository/at/dvallant/maven/plugins/maven-metadata-local.xml`.
> If you downgrade the version to 2.5.2, metadata generation works as expected.
> If you could give me a hint where the problem might be in the code I can try
> to fix it and open a pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINSTALL-191) Metadata for submodules seems to be incomplete
[
https://issues.apache.org/jira/browse/MINSTALL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MINSTALL-191:
-
Fix Version/s: 3.1.2
> Metadata for submodules seems to be incomplete
> --
>
> Key: MINSTALL-191
> URL: https://issues.apache.org/jira/browse/MINSTALL-191
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 3.0.0-M1, 3.0.0, 3.1.0, 3.1.1
> Environment: Apache Maven 3.8.8
> (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Java version: 11.0.18, vendor: Eclipse Adoptium
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-83-generic", arch: "amd64", family: "unix"
>Reporter: Dorian Vallant
>Priority: Major
> Fix For: 3.1.2
>
> Attachments: maven-install-plugin-bug.tgz
>
>
> maven-install-plugin 3.x (and maven-deploy-plugin 3.x too) seems to have a
> bug when generating maven-metadata-*.xml for submodules containing custom
> maven-plugins.
> With version 2.5.2 maven-install-plugin generates the local metadata as
> follows:
> {code:xml}
>
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082036
>
>
>
> my-maven-plugin
> my
> my-maven-plugin
>
>
>
> {code}
>
> After upgrading to 3.1.1 (also testet with 3.0.0-M1, 3.0.0 and 3.1.0) the
> generated file looks this:
> {code:xml}
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082207
>
>
> {code}
> A test-project to reproduce the issue is attached.
> To reproduce build the project by calling `mvn clean install` and then check
> the contents of
> `~/.m2/repository/at/dvallant/maven/plugins/maven-metadata-local.xml`.
> If you downgrade the version to 2.5.2, metadata generation works as expected.
> If you could give me a hint where the problem might be in the code I can try
> to fix it and open a pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINSTALL-193) Upgrade Parent Version 42
[ https://issues.apache.org/jira/browse/MINSTALL-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MINSTALL-193: - Issue Type: Dependency upgrade (was: Task) > Upgrade Parent Version 42 > - > > Key: MINSTALL-193 > URL: https://issues.apache.org/jira/browse/MINSTALL-193 > Project: Maven Install Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINSTALL-197) Upgrade parent to 41, remove deprecations
[ https://issues.apache.org/jira/browse/MINSTALL-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MINSTALL-197: - Issue Type: Dependency upgrade (was: Task) > Upgrade parent to 41, remove deprecations > - > > Key: MINSTALL-197 > URL: https://issues.apache.org/jira/browse/MINSTALL-197 > Project: Maven Install Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.1.2 > > > Upgrade parent to 41, remove deprecations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINSTALL-193) Upgrade Parent Version 42, require min Maven 3.6.3
[ https://issues.apache.org/jira/browse/MINSTALL-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MINSTALL-193: - Summary: Upgrade Parent Version 42, require min Maven 3.6.3 (was: Upgrade Parent Version 42) > Upgrade Parent Version 42, require min Maven 3.6.3 > -- > > Key: MINSTALL-193 > URL: https://issues.apache.org/jira/browse/MINSTALL-193 > Project: Maven Install Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINSTALL-193) Upgrade Parent Version 42, require min Maven 3.6.3
[ https://issues.apache.org/jira/browse/MINSTALL-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840347#comment-17840347 ] ASF GitHub Bot commented on MINSTALL-193: - cstamas opened a new pull request, #64: URL: https://github.com/apache/maven-install-plugin/pull/64 --- https://issues.apache.org/jira/browse/MINSTALL-193 > Upgrade Parent Version 42, require min Maven 3.6.3 > -- > > Key: MINSTALL-193 > URL: https://issues.apache.org/jira/browse/MINSTALL-193 > Project: Maven Install Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MBUILDCACHE-86] bugfix / enhancements restoration of outputs on disk [maven-build-cache-extension]
hboutemy commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2074492962 notice: if you build with Maven 3, you won't have this extra file, which is Maven 4 specific https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MBUILDCACHE-86) Bugfix and enhancements with the restoration of outputs on disk
[ https://issues.apache.org/jira/browse/MBUILDCACHE-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840354#comment-17840354 ] ASF GitHub Bot commented on MBUILDCACHE-86: --- hboutemy commented on PR #104: URL: https://github.com/apache/maven-build-cache-extension/pull/104#issuecomment-2074492962 notice: if you build with Maven 3, you won't have this extra file, which is Maven 4 specific https://cwiki.apache.org/confluence/display/MAVEN/Build+vs+Consumer+POM > Bugfix and enhancements with the restoration of outputs on disk > --- > > Key: MBUILDCACHE-86 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-86 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Kevin Buntrock >Priority: Major > Labels: pull-request-available > > *Fixes :* > * Files containing an underscore in their name can't be restored in the > cache directory correctly (not in the same directory location). > * The cache is able to extract/restore files in locations outside the > project. I guess the extraction part is not a vulnerability since someone > with commit permissions can guess other ways to extract data. But the > possibility of restoring at any place on the disk looks pretty dangerous to > me if a remote cache server is compromised. > *Enhancements :* > * Possibility to restore artefacts on disk, with a dedicated property : > maven.build.cache.restoreOnDiskArtefacts (default to true). Meaning in the > project directory, as opposed to the cache directory. > ** IDE integration and use of the cache locally in developement is way > easier. It is now possible to retrieve a cached jar in the "target" directory. > * Introduce "globs" to filter extra attached outputs by filenames. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-8106) Maven Metadata corruption if directory role overlaps
Tamas Cservenak created MNG-8106:
Summary: Maven Metadata corruption if 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.6, 3.9.5, 3.9.4, 3.9.3, 3.9.2, 3.9.1, 3.9.0
Reporter: Tamas Cservenak
Fix For: 3.9.7
In case certain directory role 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).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-8106) Maven Metadata corruption if 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-beta-1
> Maven Metadata corruption if 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
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role 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).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MNG-8106) Maven Metadata corruption if directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MNG-8106:
Assignee: Tamas Cservenak
> Maven Metadata corruption if 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
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role 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).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8106) Maven Metadata corruption if directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840355#comment-17840355
]
ASF GitHub Bot commented on MNG-8106:
-
cstamas opened a new pull request, #1480:
URL: https://github.com/apache/maven/pull/1480
As currently if given metadata serves multiple roles (G, A or V level), data
loss occurs.
---
https://issues.apache.org/jira/browse/MNG-8106
> Maven Metadata corruption if 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
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role 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).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8106) Maven Metadata corruption if directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840358#comment-17840358
]
ASF GitHub Bot commented on MNG-8106:
-
cstamas opened a new pull request, #1481:
URL: https://github.com/apache/maven/pull/1481
As currently if given metadata serves multiple roles (G, A or V level), data
loss occurs.
---
https://issues.apache.org/jira/browse/MNG-8106
> Maven Metadata corruption if 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
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role 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).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MASSEMBLY-1029) Warning "failed to build parent project"
Guillaume Nodet created MASSEMBLY-1029:
--
Summary: Warning "failed to build parent project"
Key: MASSEMBLY-1029
URL: https://issues.apache.org/jira/browse/MASSEMBLY-1029
Project: Maven Assembly Plugin
Issue Type: Bug
Affects Versions: 3.7.1
Reporter: Guillaume Nodet
Here's what happens when building maven core
(529d80a1697c8fd1d53a0a3842261a1343cc3510) during the assembly:
{code}
[WARNING] Failed to build parent project for
jakarta.inject:jakarta.inject-api:jar:2.0.1
org.apache.maven.project.ProjectBuildingException: Some problems were
encountered while processing the POMs
at
org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:338)
at
org.apache.maven.project.DefaultProjectBuilder$BuildSession.initParent(DefaultProjectBuilder.java:849)
at
org.apache.maven.project.DefaultProjectBuilder$BuildSession.initProject(DefaultProjectBuilder.java:682)
at
org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:323)
at
org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:382)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:155)
at
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:148)
at
org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:150)
at
org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:115)
at
org.apache.maven.plugins.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:84)
at
org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:172)
at
org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:493)
at
org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:54)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
at
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:323)
at
org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:311)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:178)
at
org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:167)
at
org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:164)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:107)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:60)
at
org.apache.maven.lifecycle.internal.DefaultLifecycleStarter.execute(DefaultLifecycleStarter.java:123)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:225)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:149)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
at
jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
at java.lang.reflect.Method.invoke(Method.java:580)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
Caused by: org.apache.maven.model.building.ModelBuildingException: 8 problems
were encountered while building the effective model for
/Users/gnodet/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom
- [ERROR]
'profiles.profile[snapshots].repositories.repository.[sonatype-nexus-snapshots].url'
contains an expression but should be a constant. @
org.eclipse.ee4j:project:1.0.6,
/Users/gnodet/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom,
line 252, column 21
- [ERROR]
'profiles.profile[snapshots].pluginRepositories.pluginRepository.[sonatype-nexus-snapshots].url'
contains an expression but should be a constant. @
org.eclipse.ee4j:project:1.0.6,
/Users/gnodet/.m2/repository/org/eclipse/ee4j/p
[jira] [Commented] (MASSEMBLY-1029) Warning "failed to build parent project"
[
https://issues.apache.org/jira/browse/MASSEMBLY-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840364#comment-17840364
]
Guillaume Nodet commented on MASSEMBLY-1029:
So maybe simply setting the validation level to a lower value (than the default
one) in:
https://github.com/apache/maven-assembly-plugin/blob/07c6a2ee65e6505e40c0500d2ebc23893060a979/src/main/java/org/apache/maven/plugins/assembly/archive/task/AddDependencySetsTask.java#L168-L169
> Warning "failed to build parent project"
>
>
> Key: MASSEMBLY-1029
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1029
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.7.1
>Reporter: Guillaume Nodet
>Priority: Major
>
> Here's what happens when building maven core
> (529d80a1697c8fd1d53a0a3842261a1343cc3510) during the assembly:
> {code}
> [WARNING] Failed to build parent project for
> jakarta.inject:jakarta.inject-api:jar:2.0.1
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:338)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initParent(DefaultProjectBuilder.java:849)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initProject(DefaultProjectBuilder.java:682)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:323)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:382)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:155)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:148)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:150)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:115)
> at
> org.apache.maven.plugins.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:84)
> at
> org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:172)
> at
> org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:493)
> at
> org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:54)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:323)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:311)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:178)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:167)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:164)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:107)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:60)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleStarter.execute(DefaultLifecycleStarter.java:123)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:225)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:149)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.model.building.ModelBuildingExcepti
[jira] [Commented] (MBUILDCACHE-59) Accommodate Maven CI-friendly versions
[
https://issues.apache.org/jira/browse/MBUILDCACHE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840386#comment-17840386
]
Marquis Wang commented on MBUILDCACHE-59:
-
I am observing the same thing - it seems to work correctly for dependencies,
but not with annotationProcessorPaths.
> Accommodate Maven CI-friendly versions
> --
>
> Key: MBUILDCACHE-59
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-59
> Project: Maven Build Cache Extension
> Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Bas van Erp
>Priority: Major
>
> I would argue that the Maven Build Cache Extension (MBCE) can provide the
> greatest value for users that utilize large multi-module (mono-)repositories,
> since those projects tend to have large amounts of "stable" code which isn't
> modified frequently.
> Speeding up the build of these multi-module projects using the MBCE would be
> totally awesome!
> But for my particular project (200K LOC, 400 modules, mono-repo) our initial
> trials with the MBCE have proven somewhat troublesome.
> It has to do with our use of [https://maven.apache.org/maven-ci-friendly.html]
> h2. Example setup
> {{repo/.mvn/maven.config}}
> {code:java}
> -Drevision=0.0.0-local-SNAPSHOT {code}
> {{repo/pom.xml}}
> {code:java}
> com.corp
> parent
> ${revision}
> pom {code}
> {{repo/moduleX/pom.xml}}
> {code:java}
>
> com.corp
> parent
> ${revision}
> ../pom.xml
>
> moduleX
> jar{code}
> {{repo/moduleY/pom.xml}}
> {code:java}
>
> com.corp
> parent
> ${revision}
> ../pom.xml
>
> moduleY
> jar
>
>
> com.corp
> moduleX
> ${revision}
>
> {code}
> {{repo/Jenkinsfile}}
> {code:java}
> mvn clean deploy -Drevision=$(git describe){code}
> h2. Effect
> This setup effectively means that while all our 150 developers might
> theoretically get decent cache hit % since they are all always using version
> {{0.0.0-local-SNAPSHOT}} for every single POM for every single build, our CI
> pipelines are out of luck.
> Since the effective-POMs will change radically with each new Git commit, the
> hashes will virtually never collide.
> h2. Solution?
> I'm very new to the MBCE so I might be way off the mark, but I think
> accommodating this setup will not be trivial to implement. It would probably
> require parsing the effective-POM for every module picked-up by the reactor
> and then removing all clauses of the module, the parent, and each
> dependency and plugin which are part of the reactor build.
> Doesn't sound easy to me. But perhaps I'm missing something.
>
> p.s. Congrats on the v1.0.0 release :). I'm enjoying experimenting with it.
> But the documentation could use some love. It's pretty hard to read. Some
> paragraphs are confusing, terse or lacking in detail, are clearly written by
> non-English-native writers (like myself), or even stop mid-sentence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] [MNG-8106] IT [maven-integration-testing]
cstamas opened a new pull request, #336: URL: https://github.com/apache/maven-integration-testing/pull/336 https://issues.apache.org/jira/browse/MNG-8106 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-8106) Maven Metadata corruption if 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:
-
Description:
In case certain directory role 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).
was:
In case certain directory role 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).
> Maven Metadata corruption if 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
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role 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).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Clean warnings [maven]
gnodet opened a new pull request, #1482: URL: https://github.com/apache/maven/pull/1482 - **Cleanup dependencies** - **Deprecate test classes in maven-compat which cause lots of warnings** -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MASSEMBLY-1029) Warning "failed to build parent project"
[
https://issues.apache.org/jira/browse/MASSEMBLY-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840394#comment-17840394
]
ASF GitHub Bot commented on MASSEMBLY-1029:
---
gnodet opened a new pull request, #204:
URL: https://github.com/apache/maven-assembly-plugin/pull/204
(no comment)
> Warning "failed to build parent project"
>
>
> Key: MASSEMBLY-1029
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1029
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.7.1
>Reporter: Guillaume Nodet
>Priority: Major
>
> Here's what happens when building maven core
> (529d80a1697c8fd1d53a0a3842261a1343cc3510) during the assembly:
> {code}
> [WARNING] Failed to build parent project for
> jakarta.inject:jakarta.inject-api:jar:2.0.1
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:338)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initParent(DefaultProjectBuilder.java:849)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initProject(DefaultProjectBuilder.java:682)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:323)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:382)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:155)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:148)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:150)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:115)
> at
> org.apache.maven.plugins.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:84)
> at
> org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:172)
> at
> org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:493)
> at
> org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:54)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:323)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:311)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:178)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:167)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:164)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:107)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:60)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleStarter.execute(DefaultLifecycleStarter.java:123)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:225)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:149)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.model.building.ModelBuildingException: 8 problems
> were encountered while building the effective model for
> /Users/gnodet/.m2/repository/org/eclipse/ee4j/project/1.0.6/project-1.0.6.pom
> - [
Re: [PR] [MNG-8106] IT [maven-integration-testing]
cstamas commented on PR #336: URL: https://github.com/apache/maven-integration-testing/pull/336#issuecomment-2074716885 @slachiewicz @gnodet pls review, I'd like to have this merged to have checked my fix PRs (in maven 3.9.7 and beta-1) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] Use the new resolver provider [maven]
gnodet opened a new pull request, #1483: URL: https://github.com/apache/maven/pull/1483 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] SUMMARY`, where you replace `MNG-XXX` and `SUMMARY` with the appropriate JIRA issue. - [ ] Also format the first line of the commit message like `[MNG-XXX] SUMMARY`. Best practice is to use the JIRA issue title in both the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] [3.9.x] [MNG-8106] IT [maven-integration-testing]
cstamas opened a new pull request, #337: URL: https://github.com/apache/maven-integration-testing/pull/337 Created IT that does "wrong" (as same directory has once G and once A role), and verify that both level metadata is present. In other words, but none is dropped. --- https://issues.apache.org/jira/browse/MNG-8106 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [3.9.x][MNG-8106] Fix metadata merge [maven]
cstamas commented on PR #1480: URL: https://github.com/apache/maven/pull/1480#issuecomment-2074807997 There is some CI (not IT) related issue on macOS? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8106) Maven Metadata corruption if directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840412#comment-17840412
]
ASF GitHub Bot commented on MNG-8106:
-
cstamas commented on PR #1480:
URL: https://github.com/apache/maven/pull/1480#issuecomment-2074807997
There is some CI (not IT) related issue on macOS?
> Maven Metadata corruption if 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
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role 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).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Make Maven 4.0.0 be beta-1 [maven]
cstamas opened a new pull request, #1484: URL: https://github.com/apache/maven/pull/1484 Set version from `4.0.0-alpha-14-SNAPSHOT` to `4.0.0-beta-1-SNAPSHOT`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MNG-8106] Fix metadata merge [maven]
cstamas commented on PR #1481: URL: https://github.com/apache/maven/pull/1481#issuecomment-2074934664 Note: new IT did not run (it did on 3.9.x PR https://github.com/apache/maven/pull/1480) as master is still alpha-14... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8106) Maven Metadata corruption if directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840438#comment-17840438
]
ASF GitHub Bot commented on MNG-8106:
-
cstamas commented on PR #1481:
URL: https://github.com/apache/maven/pull/1481#issuecomment-2074934664
Note: new IT did not run (it did on 3.9.x PR
https://github.com/apache/maven/pull/1480) as master is still alpha-14...
> Maven Metadata corruption if 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
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.9.7, 4.0.0-beta-1
>
>
> In case certain directory role 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).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MINSTALL-191) Metadata for submodules seems to be incomplete
[
https://issues.apache.org/jira/browse/MINSTALL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MINSTALL-191:
-
Fix Version/s: (was: 3.1.2)
> Metadata for submodules seems to be incomplete
> --
>
> Key: MINSTALL-191
> URL: https://issues.apache.org/jira/browse/MINSTALL-191
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 3.0.0-M1, 3.0.0, 3.1.0, 3.1.1
> Environment: Apache Maven 3.8.8
> (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Java version: 11.0.18, vendor: Eclipse Adoptium
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-83-generic", arch: "amd64", family: "unix"
>Reporter: Dorian Vallant
>Priority: Major
> Attachments: maven-install-plugin-bug.tgz
>
>
> maven-install-plugin 3.x (and maven-deploy-plugin 3.x too) seems to have a
> bug when generating maven-metadata-*.xml for submodules containing custom
> maven-plugins.
> With version 2.5.2 maven-install-plugin generates the local metadata as
> follows:
> {code:xml}
>
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082036
>
>
>
> my-maven-plugin
> my
> my-maven-plugin
>
>
>
> {code}
>
> After upgrading to 3.1.1 (also testet with 3.0.0-M1, 3.0.0 and 3.1.0) the
> generated file looks this:
> {code:xml}
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082207
>
>
> {code}
> A test-project to reproduce the issue is attached.
> To reproduce build the project by calling `mvn clean install` and then check
> the contents of
> `~/.m2/repository/at/dvallant/maven/plugins/maven-metadata-local.xml`.
> If you downgrade the version to 2.5.2, metadata generation works as expected.
> If you could give me a hint where the problem might be in the code I can try
> to fix it and open a pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MINSTALL-191) Metadata for submodules seems to be incomplete
[
https://issues.apache.org/jira/browse/MINSTALL-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840441#comment-17840441
]
Tamas Cservenak commented on MINSTALL-191:
--
Ok, so this is actually a Maven bug:
https://issues.apache.org/jira/browse/MNG-8106
Will be fixed in 3.9.7
> Metadata for submodules seems to be incomplete
> --
>
> Key: MINSTALL-191
> URL: https://issues.apache.org/jira/browse/MINSTALL-191
> Project: Maven Install Plugin
> Issue Type: Bug
> Components: install:install
>Affects Versions: 3.0.0-M1, 3.0.0, 3.1.0, 3.1.1
> Environment: Apache Maven 3.8.8
> (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
> Java version: 11.0.18, vendor: Eclipse Adoptium
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "5.15.0-83-generic", arch: "amd64", family: "unix"
>Reporter: Dorian Vallant
>Priority: Major
> Attachments: maven-install-plugin-bug.tgz
>
>
> maven-install-plugin 3.x (and maven-deploy-plugin 3.x too) seems to have a
> bug when generating maven-metadata-*.xml for submodules containing custom
> maven-plugins.
> With version 2.5.2 maven-install-plugin generates the local metadata as
> follows:
> {code:xml}
>
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082036
>
>
>
> my-maven-plugin
> my
> my-maven-plugin
>
>
>
> {code}
>
> After upgrading to 3.1.1 (also testet with 3.0.0-M1, 3.0.0 and 3.1.0) the
> generated file looks this:
> {code:xml}
>
> at.dvallant.maven
> plugins
>
>
> 0.1.0-SNAPSHOT
>
> 20230831082207
>
>
> {code}
> A test-project to reproduce the issue is attached.
> To reproduce build the project by calling `mvn clean install` and then check
> the contents of
> `~/.m2/repository/at/dvallant/maven/plugins/maven-metadata-local.xml`.
> If you downgrade the version to 2.5.2, metadata generation works as expected.
> If you could give me a hint where the problem might be in the code I can try
> to fix it and open a pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MINSTALL-195] Include artifactId in InstallMojo#processProject messages [maven-install-plugin]
cstamas commented on PR #59: URL: https://github.com/apache/maven-install-plugin/pull/59#issuecomment-2074983534 Done as e9143678bac698483693b3b2ed2d58407920 (had to tweak it) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MINSTALL-195] Include artifactId in InstallMojo#processProject messages [maven-install-plugin]
cstamas closed pull request #59: [MINSTALL-195] Include artifactId in InstallMojo#processProject messages URL: https://github.com/apache/maven-install-plugin/pull/59 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MINSTALL-193] Parent 42, min Maven 3.6.3 [maven-install-plugin]
cstamas merged PR #64: URL: https://github.com/apache/maven-install-plugin/pull/64 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MINSTALL-193) Upgrade Parent Version 42, require min Maven 3.6.3
[ https://issues.apache.org/jira/browse/MINSTALL-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840447#comment-17840447 ] ASF GitHub Bot commented on MINSTALL-193: - cstamas merged PR #64: URL: https://github.com/apache/maven-install-plugin/pull/64 > Upgrade Parent Version 42, require min Maven 3.6.3 > -- > > Key: MINSTALL-193 > URL: https://issues.apache.org/jira/browse/MINSTALL-193 > Project: Maven Install Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MINSTALL-193) Upgrade Parent Version 42, require min Maven 3.6.3
[ https://issues.apache.org/jira/browse/MINSTALL-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MINSTALL-193. Resolution: Fixed > Upgrade Parent Version 42, require min Maven 3.6.3 > -- > > Key: MINSTALL-193 > URL: https://issues.apache.org/jira/browse/MINSTALL-193 > Project: Maven Install Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINSTALL-195) Include artifactId in messages of InstallMojo#processProject
[
https://issues.apache.org/jira/browse/MINSTALL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840446#comment-17840446
]
ASF GitHub Bot commented on MINSTALL-195:
-
cstamas closed pull request #59: [MINSTALL-195] Include artifactId in
InstallMojo#processProject messages
URL: https://github.com/apache/maven-install-plugin/pull/59
> Include artifactId in messages of InstallMojo#processProject
>
>
> Key: MINSTALL-195
> URL: https://issues.apache.org/jira/browse/MINSTALL-195
> Project: Maven Install Plugin
> Issue Type: Improvement
> Components: install:install
>Affects Versions: 3.1.1
>Reporter: András Péteri
>Priority: Major
> Fix For: 3.1.2
>
>
> A companion request for MDEPLOY-314: if an issue is encountered in "install
> at end" mode in the method mentioned in the title, the {{project}} method
> argument's artifact ID should be mentioned as it might not be the same as the
> {{project}} parameter on the class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MINSTALL-195) Include artifactId in messages of InstallMojo#processProject
[
https://issues.apache.org/jira/browse/MINSTALL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MINSTALL-195.
Assignee: Tamas Cservenak
Resolution: Fixed
> Include artifactId in messages of InstallMojo#processProject
>
>
> Key: MINSTALL-195
> URL: https://issues.apache.org/jira/browse/MINSTALL-195
> Project: Maven Install Plugin
> Issue Type: Improvement
> Components: install:install
>Affects Versions: 3.1.1
>Reporter: András Péteri
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 3.1.2
>
>
> A companion request for MDEPLOY-314: if an issue is encountered in "install
> at end" mode in the method mentioned in the title, the {{project}} method
> argument's artifact ID should be mentioned as it might not be the same as the
> {{project}} parameter on the class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MINSTALL-195) Include artifactId in messages of InstallMojo#processProject
[
https://issues.apache.org/jira/browse/MINSTALL-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840445#comment-17840445
]
ASF GitHub Bot commented on MINSTALL-195:
-
cstamas commented on PR #59:
URL:
https://github.com/apache/maven-install-plugin/pull/59#issuecomment-2074983534
Done as e9143678bac698483693b3b2ed2d58407920
(had to tweak it)
> Include artifactId in messages of InstallMojo#processProject
>
>
> Key: MINSTALL-195
> URL: https://issues.apache.org/jira/browse/MINSTALL-195
> Project: Maven Install Plugin
> Issue Type: Improvement
> Components: install:install
>Affects Versions: 3.1.1
>Reporter: András Péteri
>Priority: Major
> Fix For: 3.1.2
>
>
> A companion request for MDEPLOY-314: if an issue is encountered in "install
> at end" mode in the method mentioned in the title, the {{project}} method
> argument's artifact ID should be mentioned as it might not be the same as the
> {{project}} parameter on the class.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Bump org.apache.maven.plugins:maven-plugins from 41 to 42 [maven-install-plugin]
dependabot[bot] commented on PR #62: URL: https://github.com/apache/maven-install-plugin/pull/62#issuecomment-2074988409 Looks like org.apache.maven.plugins:maven-plugins is up-to-date now, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.maven.plugins:maven-plugins from 41 to 42 [maven-install-plugin]
cstamas commented on PR #62: URL: https://github.com/apache/maven-install-plugin/pull/62#issuecomment-2074987596 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.maven.plugins:maven-plugins from 41 to 42 [maven-install-plugin]
dependabot[bot] closed pull request #62: Bump org.apache.maven.plugins:maven-plugins from 41 to 42 URL: https://github.com/apache/maven-install-plugin/pull/62 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MDEPLOY-314) Include artifactId in messages of DeployMojo#processProject
[
https://issues.apache.org/jira/browse/MDEPLOY-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MDEPLOY-314:
Fix Version/s: 3.1.2
> Include artifactId in messages of DeployMojo#processProject
> ---
>
> Key: MDEPLOY-314
> URL: https://issues.apache.org/jira/browse/MDEPLOY-314
> Project: Maven Deploy Plugin
> Issue Type: Improvement
> Components: deploy:deploy
>Affects Versions: 3.1.1
>Reporter: András Péteri
>Priority: Minor
> Fix For: 3.1.2
>
>
> In "deploy all at once" mode a single project does the heavy lifting for all
> reactor projects once it is determined that others have already been marked
> with an instance of the {{State}} enum earlier.
> As mentioned in a
> [comment|https://github.com/apache/maven-deploy-plugin/pull/39/files/327e65c5dd5e5ed92910858d4cf66ce946e22bbe#r1398970349]
> on PR #39, if a warning is written to the log or an exception is thrown at
> this point, the issue can be falsely attributed to the current project, and
> the real culprit can only be determined by temporarily switching back to
> eager deploy mode.
> It would be nice to display which project is being processed, making this
> investigation easier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MDEPLOY-316) Update parent to 42, up prerequisite to 3.6.3
Tamas Cservenak created MDEPLOY-316: --- Summary: Update parent to 42, up prerequisite to 3.6.3 Key: MDEPLOY-316 URL: https://issues.apache.org/jira/browse/MDEPLOY-316 Project: Maven Deploy Plugin Issue Type: Dependency upgrade Reporter: Tamas Cservenak Fix For: 3.1.2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEPLOY-316) Update parent to 42, up prerequisite to 3.6.3
[ https://issues.apache.org/jira/browse/MDEPLOY-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840450#comment-17840450 ] ASF GitHub Bot commented on MDEPLOY-316: cstamas opened a new pull request, #54: URL: https://github.com/apache/maven-deploy-plugin/pull/54 Update parent to 42 and prerequisite to Maven 3.6.3 --- https://issues.apache.org/jira/browse/MDEPLOY-316 > Update parent to 42, up prerequisite to 3.6.3 > - > > Key: MDEPLOY-316 > URL: https://issues.apache.org/jira/browse/MDEPLOY-316 > Project: Maven Deploy Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Priority: Major > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MDEPLOY-316) Update parent to 42, up prerequisite to 3.6.3
[ https://issues.apache.org/jira/browse/MDEPLOY-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MDEPLOY-316: --- Assignee: Tamas Cservenak > Update parent to 42, up prerequisite to 3.6.3 > - > > Key: MDEPLOY-316 > URL: https://issues.apache.org/jira/browse/MDEPLOY-316 > Project: Maven Deploy Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MDEPLOY-316] Parent 42 and prerequisite 3.6.3 [maven-deploy-plugin]
cstamas merged PR #54: URL: https://github.com/apache/maven-deploy-plugin/pull/54 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MDEPLOY-316) Update parent to 42, up prerequisite to 3.6.3
[ https://issues.apache.org/jira/browse/MDEPLOY-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MDEPLOY-316. --- Resolution: Fixed > Update parent to 42, up prerequisite to 3.6.3 > - > > Key: MDEPLOY-316 > URL: https://issues.apache.org/jira/browse/MDEPLOY-316 > Project: Maven Deploy Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MDEPLOY-316) Update parent to 42, up prerequisite to 3.6.3
[ https://issues.apache.org/jira/browse/MDEPLOY-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840455#comment-17840455 ] ASF GitHub Bot commented on MDEPLOY-316: cstamas merged PR #54: URL: https://github.com/apache/maven-deploy-plugin/pull/54 > Update parent to 42, up prerequisite to 3.6.3 > - > > Key: MDEPLOY-316 > URL: https://issues.apache.org/jira/browse/MDEPLOY-316 > Project: Maven Deploy Plugin > Issue Type: Dependency upgrade >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.1.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MDEPLOY-314) Include artifactId in messages of DeployMojo#processProject
[
https://issues.apache.org/jira/browse/MDEPLOY-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak reassigned MDEPLOY-314:
---
Assignee: Tamas Cservenak
> Include artifactId in messages of DeployMojo#processProject
> ---
>
> Key: MDEPLOY-314
> URL: https://issues.apache.org/jira/browse/MDEPLOY-314
> Project: Maven Deploy Plugin
> Issue Type: Improvement
> Components: deploy:deploy
>Affects Versions: 3.1.1
>Reporter: András Péteri
>Assignee: Tamas Cservenak
>Priority: Minor
> Fix For: 3.1.2
>
>
> In "deploy all at once" mode a single project does the heavy lifting for all
> reactor projects once it is determined that others have already been marked
> with an instance of the {{State}} enum earlier.
> As mentioned in a
> [comment|https://github.com/apache/maven-deploy-plugin/pull/39/files/327e65c5dd5e5ed92910858d4cf66ce946e22bbe#r1398970349]
> on PR #39, if a warning is written to the log or an exception is thrown at
> this point, the issue can be falsely attributed to the current project, and
> the real culprit can only be determined by temporarily switching back to
> eager deploy mode.
> It would be nice to display which project is being processed, making this
> investigation easier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MDEPLOY-314] Include artifactId in DeployMojo#processProject messages [maven-deploy-plugin]
cstamas closed pull request #45: [MDEPLOY-314] Include artifactId in DeployMojo#processProject messages URL: https://github.com/apache/maven-deploy-plugin/pull/45 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MDEPLOY-314] Include artifactId in DeployMojo#processProject messages [maven-deploy-plugin]
cstamas commented on PR #45: URL: https://github.com/apache/maven-deploy-plugin/pull/45#issuecomment-2075072568 merged w/ tweaks as b9c1c8bc486c7defb92171e1ea9169075b76695c -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.maven.plugins:maven-plugins from 41 to 42 [maven-deploy-plugin]
cstamas commented on PR #52: URL: https://github.com/apache/maven-deploy-plugin/pull/52#issuecomment-2075073030 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.maven.plugins:maven-plugins from 41 to 42 [maven-deploy-plugin]
dependabot[bot] commented on PR #52: URL: https://github.com/apache/maven-deploy-plugin/pull/52#issuecomment-2075073733 Looks like org.apache.maven.plugins:maven-plugins is up-to-date now, so this is no longer needed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.maven.plugins:maven-plugins from 41 to 42 [maven-deploy-plugin]
dependabot[bot] closed pull request #52: Bump org.apache.maven.plugins:maven-plugins from 41 to 42 URL: https://github.com/apache/maven-deploy-plugin/pull/52 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEPLOY-314) Include artifactId in messages of DeployMojo#processProject
[
https://issues.apache.org/jira/browse/MDEPLOY-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840459#comment-17840459
]
ASF GitHub Bot commented on MDEPLOY-314:
cstamas closed pull request #45: [MDEPLOY-314] Include artifactId in
DeployMojo#processProject messages
URL: https://github.com/apache/maven-deploy-plugin/pull/45
> Include artifactId in messages of DeployMojo#processProject
> ---
>
> Key: MDEPLOY-314
> URL: https://issues.apache.org/jira/browse/MDEPLOY-314
> Project: Maven Deploy Plugin
> Issue Type: Improvement
> Components: deploy:deploy
>Affects Versions: 3.1.1
>Reporter: András Péteri
>Assignee: Tamas Cservenak
>Priority: Minor
> Fix For: 3.1.2
>
>
> In "deploy all at once" mode a single project does the heavy lifting for all
> reactor projects once it is determined that others have already been marked
> with an instance of the {{State}} enum earlier.
> As mentioned in a
> [comment|https://github.com/apache/maven-deploy-plugin/pull/39/files/327e65c5dd5e5ed92910858d4cf66ce946e22bbe#r1398970349]
> on PR #39, if a warning is written to the log or an exception is thrown at
> this point, the issue can be falsely attributed to the current project, and
> the real culprit can only be determined by temporarily switching back to
> eager deploy mode.
> It would be nice to display which project is being processed, making this
> investigation easier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MDEPLOY-314) Include artifactId in messages of DeployMojo#processProject
[
https://issues.apache.org/jira/browse/MDEPLOY-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak closed MDEPLOY-314.
---
Resolution: Fixed
> Include artifactId in messages of DeployMojo#processProject
> ---
>
> Key: MDEPLOY-314
> URL: https://issues.apache.org/jira/browse/MDEPLOY-314
> Project: Maven Deploy Plugin
> Issue Type: Improvement
> Components: deploy:deploy
>Affects Versions: 3.1.1
>Reporter: András Péteri
>Assignee: Tamas Cservenak
>Priority: Minor
> Fix For: 3.1.2
>
>
> In "deploy all at once" mode a single project does the heavy lifting for all
> reactor projects once it is determined that others have already been marked
> with an instance of the {{State}} enum earlier.
> As mentioned in a
> [comment|https://github.com/apache/maven-deploy-plugin/pull/39/files/327e65c5dd5e5ed92910858d4cf66ce946e22bbe#r1398970349]
> on PR #39, if a warning is written to the log or an exception is thrown at
> this point, the issue can be falsely attributed to the current project, and
> the real culprit can only be determined by temporarily switching back to
> eager deploy mode.
> It would be nice to display which project is being processed, making this
> investigation easier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MDEPLOY-314) Include artifactId in messages of DeployMojo#processProject
[
https://issues.apache.org/jira/browse/MDEPLOY-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840460#comment-17840460
]
ASF GitHub Bot commented on MDEPLOY-314:
cstamas commented on PR #45:
URL:
https://github.com/apache/maven-deploy-plugin/pull/45#issuecomment-2075072568
merged w/ tweaks as b9c1c8bc486c7defb92171e1ea9169075b76695c
> Include artifactId in messages of DeployMojo#processProject
> ---
>
> Key: MDEPLOY-314
> URL: https://issues.apache.org/jira/browse/MDEPLOY-314
> Project: Maven Deploy Plugin
> Issue Type: Improvement
> Components: deploy:deploy
>Affects Versions: 3.1.1
>Reporter: András Péteri
>Assignee: Tamas Cservenak
>Priority: Minor
> Fix For: 3.1.2
>
>
> In "deploy all at once" mode a single project does the heavy lifting for all
> reactor projects once it is determined that others have already been marked
> with an instance of the {{State}} enum earlier.
> As mentioned in a
> [comment|https://github.com/apache/maven-deploy-plugin/pull/39/files/327e65c5dd5e5ed92910858d4cf66ce946e22bbe#r1398970349]
> on PR #39, if a warning is written to the log or an exception is thrown at
> this point, the issue can be falsely attributed to the current project, and
> the real culprit can only be determined by temporarily switching back to
> eager deploy mode.
> It would be nice to display which project is being processed, making this
> investigation easier.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MBUILDCACHE-89) Ability to "run always" some plugin on a per-module level
Réda Housni Alaoui created MBUILDCACHE-89: - Summary: Ability to "run always" some plugin on a per-module level Key: MBUILDCACHE-89 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-89 Project: Maven Build Cache Extension Issue Type: Improvement Reporter: Réda Housni Alaoui -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-89) Ability to "run always" some plugin on a per-module level
[ https://issues.apache.org/jira/browse/MBUILDCACHE-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Réda Housni Alaoui updated MBUILDCACHE-89: -- Description: It'd be nice to have a project property allowing to identity at module level, which plugin should run always. (was: It'd be nice to have a project property allowing to identity at module level, which plugin goal should run always.) > Ability to "run always" some plugin on a per-module level > - > > Key: MBUILDCACHE-89 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-89 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Réda Housni Alaoui >Priority: Major > > It'd be nice to have a project property allowing to identity at module level, > which plugin should run always. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MBUILDCACHE-89) Ability to "run always" some plugin on a per-module level
[ https://issues.apache.org/jira/browse/MBUILDCACHE-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Réda Housni Alaoui updated MBUILDCACHE-89: -- Description: It'd be nice to have a project property allowing to identity at module level, which plugin goal should run always. > Ability to "run always" some plugin on a per-module level > - > > Key: MBUILDCACHE-89 > URL: https://issues.apache.org/jira/browse/MBUILDCACHE-89 > Project: Maven Build Cache Extension > Issue Type: Improvement >Reporter: Réda Housni Alaoui >Priority: Major > > It'd be nice to have a project property allowing to identity at module level, > which plugin goal should run always. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-8106) Maven Metadata corruption if 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:
-
Affects Version/s: 4.0.0-alpha-13
4.0.0-alpha-12
4.0.0-alpha-10
4.0.0-alpha-9
4.0.0-alpha-8
4.0.0-alpha-7
4.0.0-alpha-5
4.0.0-alpha-4
4.0.0-alpha-3
4.0.0-alpha-2
> Maven Metadata corruption if 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 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).
--
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:
-
Summary: Maven Metadata corruption if repository directory role overlaps
(was: Maven Metadata corruption if directory role overlaps)
> 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 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).
--
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:
-
Description:
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).
was:
In case certain directory role 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).
> 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).
--
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:
-
Description:
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.
was:
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).
> 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)
Re: [PR] [MDEP-924] Get rid of maven-artifact-transfer from list-classes goal [maven-dependency-plugin]
cstamas commented on code in PR #382:
URL:
https://github.com/apache/maven-dependency-plugin/pull/382#discussion_r1578024626
##
src/main/java/org/apache/maven/plugins/dependency/utils/ResolverUtil.java:
##
@@ -68,4 +85,152 @@ public Collection
collectDependencies(Dependency root) throws Depend
result.getRoot().accept(nodeListGenerator);
return nodeListGenerator.getDependencies(true);
}
+
+/**
+ * Resolve given artifact
+ *
+ * @param artifact an artifact to resolve
+ * @param repositories remote repositories list
+ * @return resolved artifact
+ * @throws ArtifactResolutionException If the artifact could not be
resolved.
+ */
+public Artifact resolveArtifact(Artifact artifact, List
repositories)
+throws ArtifactResolutionException {
+MavenSession session = mavenSessionProvider.get();
+ArtifactRequest request = new ArtifactRequest(artifact, repositories,
null);
+ArtifactResult result =
repositorySystem.resolveArtifact(session.getRepositorySession(), request);
+return result.getArtifact();
+}
+
+/**
+ * Resolve transitive dependencies for artifact.
+ *
+ * @param artifact an artifact to resolve
+ * @param repositories remote repositories list
+ * @return list of transitive dependencies for artifact
+ * @throws DependencyResolutionException If the dependency tree could not
be built or any dependency artifact could
+ * not be resolved.
+ */
+public List resolveDependencies(Artifact artifact,
List repositories)
+throws DependencyResolutionException {
+MavenSession session = mavenSessionProvider.get();
+
+CollectRequest collectRequest = new CollectRequest(new
Dependency(artifact, null), repositories);
+DependencyRequest request = new DependencyRequest(collectRequest,
null);
+DependencyResult result =
repositorySystem.resolveDependencies(session.getRepositorySession(), request);
+return result.getArtifactResults().stream()
+.map(ArtifactResult::getArtifact)
+.collect(Collectors.toList());
+}
+
+/**
+ * Prepare a remote repositories list for given descriptions.
+ *
+ * @param repositories remote repositories descriptions
+ * @return a list of remote repositories
+ */
+public List remoteRepositories(List
repositories) {
+MavenSession mavenSession = mavenSessionProvider.get();
+List projectRepositories =
+
mavenSession.getCurrentProject().getRemoteProjectRepositories();
+if (repositories == null || repositories.isEmpty()) {
+return projectRepositories;
+}
+
+List repositoriesList =
+
repositories.stream().map(this::prepareRemoteRepository).collect(Collectors.toList());
+repositoriesList =
+
repositorySystem.newResolutionRepositories(mavenSession.getRepositorySession(),
repositoriesList);
+
+List result = new ArrayList<>(projectRepositories);
+result.addAll(repositoriesList);
+return result;
+}
+
+// protected for testing purpose
+protected RemoteRepository prepareRemoteRepository(String repository) {
Review Comment:
if you resolve/deploy with this repo, you must pass it thru RepoSyste
newDeploymentRepository or alike method (to have it mirrors/proxies/auth set).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MDEP-924) Get rid of maven-artifact-transfer from list-classes goal
[
https://issues.apache.org/jira/browse/MDEP-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840470#comment-17840470
]
ASF GitHub Bot commented on MDEP-924:
-
cstamas commented on code in PR #382:
URL:
https://github.com/apache/maven-dependency-plugin/pull/382#discussion_r1578024626
##
src/main/java/org/apache/maven/plugins/dependency/utils/ResolverUtil.java:
##
@@ -68,4 +85,152 @@ public Collection
collectDependencies(Dependency root) throws Depend
result.getRoot().accept(nodeListGenerator);
return nodeListGenerator.getDependencies(true);
}
+
+/**
+ * Resolve given artifact
+ *
+ * @param artifact an artifact to resolve
+ * @param repositories remote repositories list
+ * @return resolved artifact
+ * @throws ArtifactResolutionException If the artifact could not be
resolved.
+ */
+public Artifact resolveArtifact(Artifact artifact, List
repositories)
+throws ArtifactResolutionException {
+MavenSession session = mavenSessionProvider.get();
+ArtifactRequest request = new ArtifactRequest(artifact, repositories,
null);
+ArtifactResult result =
repositorySystem.resolveArtifact(session.getRepositorySession(), request);
+return result.getArtifact();
+}
+
+/**
+ * Resolve transitive dependencies for artifact.
+ *
+ * @param artifact an artifact to resolve
+ * @param repositories remote repositories list
+ * @return list of transitive dependencies for artifact
+ * @throws DependencyResolutionException If the dependency tree could not
be built or any dependency artifact could
+ * not be resolved.
+ */
+public List resolveDependencies(Artifact artifact,
List repositories)
+throws DependencyResolutionException {
+MavenSession session = mavenSessionProvider.get();
+
+CollectRequest collectRequest = new CollectRequest(new
Dependency(artifact, null), repositories);
+DependencyRequest request = new DependencyRequest(collectRequest,
null);
+DependencyResult result =
repositorySystem.resolveDependencies(session.getRepositorySession(), request);
+return result.getArtifactResults().stream()
+.map(ArtifactResult::getArtifact)
+.collect(Collectors.toList());
+}
+
+/**
+ * Prepare a remote repositories list for given descriptions.
+ *
+ * @param repositories remote repositories descriptions
+ * @return a list of remote repositories
+ */
+public List remoteRepositories(List
repositories) {
+MavenSession mavenSession = mavenSessionProvider.get();
+List projectRepositories =
+
mavenSession.getCurrentProject().getRemoteProjectRepositories();
+if (repositories == null || repositories.isEmpty()) {
+return projectRepositories;
+}
+
+List repositoriesList =
+
repositories.stream().map(this::prepareRemoteRepository).collect(Collectors.toList());
+repositoriesList =
+
repositorySystem.newResolutionRepositories(mavenSession.getRepositorySession(),
repositoriesList);
+
+List result = new ArrayList<>(projectRepositories);
+result.addAll(repositoriesList);
+return result;
+}
+
+// protected for testing purpose
+protected RemoteRepository prepareRemoteRepository(String repository) {
Review Comment:
if you resolve/deploy with this repo, you must pass it thru RepoSyste
newDeploymentRepository or alike method (to have it mirrors/proxies/auth set).
> Get rid of maven-artifact-transfer from list-classes goal
> -
>
> Key: MDEP-924
> URL: https://issues.apache.org/jira/browse/MDEP-924
> Project: Maven Dependency Plugin
> Issue Type: Improvement
> Components: list-classes
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
>
> We can use Resolver API
> Done in simple Mojo as preparing for other.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Make Maven 4.0.0 be beta-1 [maven]
CrazyHZM commented on PR #1484: URL: https://github.com/apache/maven/pull/1484#issuecomment-2075189420 @cstamas With the beta version being published, Can some experimental APIs be turned into official APIs? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Make Maven 4.0.0 be beta-1 [maven]
cstamas commented on PR #1484: URL: https://github.com/apache/maven/pull/1484#issuecomment-2075194539 @CrazyHZM I think so, which APIs you mean? @gnodet -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [3.9.x][MNG-8106] Fix metadata merge [maven]
cstamas commented on PR #1480: URL: https://github.com/apache/maven/pull/1480#issuecomment-2075200012 IT https://github.com/apache/maven-integration-testing/pull/337 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MNG-8106] Fix metadata merge [maven]
cstamas commented on PR #1481: URL: https://github.com/apache/maven/pull/1481#issuecomment-2075200539 IT https://github.com/apache/maven-integration-testing/pull/336 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-8106) Maven Metadata corruption if repository directory role overlaps
[
https://issues.apache.org/jira/browse/MNG-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840481#comment-17840481
]
ASF GitHub Bot commented on MNG-8106:
-
cstamas commented on PR #1481:
URL: https://github.com/apache/maven/pull/1481#issuecomment-2075200539
IT https://github.com/apache/maven-integration-testing/pull/336
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=17840480#comment-17840480
]
ASF GitHub Bot commented on MNG-8106:
-
cstamas commented on PR #1480:
URL: https://github.com/apache/maven/pull/1480#issuecomment-2075200012
IT https://github.com/apache/maven-integration-testing/pull/337
> 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)
Re: [PR] Make Maven 4.0.0 be beta-1 [maven]
CrazyHZM commented on PR #1484: URL: https://github.com/apache/maven/pull/1484#issuecomment-2075202883 @cstamas Those with `@Experimental` annotation, such as VersionRange.java. cc @gnodet -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] [MASSEMBLY-1029] Use minimal level for model validation [maven-assembly-plugin]
slachiewicz commented on PR #204: URL: https://github.com/apache/maven-assembly-plugin/pull/204#issuecomment-2075210686 We can drop 11 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MASSEMBLY-1029) Warning "failed to build parent project"
[
https://issues.apache.org/jira/browse/MASSEMBLY-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840484#comment-17840484
]
ASF GitHub Bot commented on MASSEMBLY-1029:
---
slachiewicz commented on PR #204:
URL:
https://github.com/apache/maven-assembly-plugin/pull/204#issuecomment-2075210686
We can drop 11
> Warning "failed to build parent project"
>
>
> Key: MASSEMBLY-1029
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-1029
> Project: Maven Assembly Plugin
> Issue Type: Bug
>Affects Versions: 3.7.1
>Reporter: Guillaume Nodet
>Priority: Major
>
> Here's what happens when building maven core
> (529d80a1697c8fd1d53a0a3842261a1343cc3510) during the assembly:
> {code}
> [WARNING] Failed to build parent project for
> jakarta.inject:jakarta.inject-api:jar:2.0.1
> org.apache.maven.project.ProjectBuildingException: Some problems were
> encountered while processing the POMs
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:338)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initParent(DefaultProjectBuilder.java:849)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.initProject(DefaultProjectBuilder.java:682)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:323)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:382)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:155)
> at
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:148)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:150)
> at
> org.apache.maven.plugins.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:115)
> at
> org.apache.maven.plugins.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:84)
> at
> org.apache.maven.plugins.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:172)
> at
> org.apache.maven.plugins.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:493)
> at
> org.apache.maven.plugins.assembly.mojos.SingleAssemblyMojo.execute(SingleAssemblyMojo.java:54)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:323)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:311)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:178)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:167)
> at
> org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:164)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:107)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:60)
> at
> org.apache.maven.lifecycle.internal.DefaultLifecycleStarter.execute(DefaultLifecycleStarter.java:123)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:311)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:225)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:149)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:958)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:205)
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> at java.lang.reflect.Method.invoke(Method.java:580)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.model.building.ModelBuildingException: 8 problems
> were encountered while building the effective model for
> /Users/gnodet/.m2/repository/org/eclipse/ee4j/project/1.0.6/projec
[jira] [Created] (MRESOLVER-541) S3 Transport
Tamas Cservenak created MRESOLVER-541: - Summary: S3 Transport Key: MRESOLVER-541 URL: https://issues.apache.org/jira/browse/MRESOLVER-541 Project: Maven Resolver Issue Type: New Feature Components: Resolver Reporter: Tamas Cservenak We might want to revisit creating transport for S3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-8084] add di & api-impl [maven]
hboutemy merged PR #1461: URL: https://github.com/apache/maven/pull/1461 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-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:comment-tabpanel&focusedCommentId=17840498#comment-17840498 ] ASF GitHub Bot commented on MNG-8084: - hboutemy merged PR #1461: URL: https://github.com/apache/maven/pull/1461 > 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-beta-1 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] Switch JDK distribution to zulu as default [maven-gh-actions-shared]
slawekjaranowski opened a new pull request, #100: URL: https://github.com/apache/maven-gh-actions-shared/pull/100 temurin doesn't support JDK 8 on macOS 14 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (MBUILDCACHE-90) Configuration option to make mandatory the use of the clean phase in order to cache the build result
Kevin Buntrock created MBUILDCACHE-90: - Summary: Configuration option to make mandatory the use of the clean phase in order to cache the build result Key: MBUILDCACHE-90 URL: https://issues.apache.org/jira/browse/MBUILDCACHE-90 Project: Maven Build Cache Extension Issue Type: New Feature Reporter: Kevin Buntrock Add a configuration option to make mandatory the use of the clean phase in order to cache the build result. The goal is to offer the possibility of denying as much as possible the possibility to cache a faulty build. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MDEP-923] Remove plexus logger from DependencySilentLog [maven-dependency-plugin]
slawekjaranowski merged PR #383: URL: https://github.com/apache/maven-dependency-plugin/pull/383 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MDEP-923) Code cleanups
[
https://issues.apache.org/jira/browse/MDEP-923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17840564#comment-17840564
]
ASF GitHub Bot commented on MDEP-923:
-
slawekjaranowski merged PR #383:
URL: https://github.com/apache/maven-dependency-plugin/pull/383
> Code cleanups
> -
>
> Key: MDEP-923
> URL: https://issues.apache.org/jira/browse/MDEP-923
> Project: Maven Dependency Plugin
> Issue Type: Task
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.7.0
>
>
> * remove usage of deprecated API where possible
> * cleanup pom after update to 42
> * exclude transitive dependencies on org.apache.maven
> * add {{@project.version@}} in ITs
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MBUILDCACHE-90] A "mandatory clean" option to enable the caching functionnality [maven-build-cache-extension]
kbuntrock commented on code in PR #103:
URL:
https://github.com/apache/maven-build-cache-extension/pull/103#discussion_r1578481429
##
src/test/java/org/apache/maven/buildcache/util/LogFileUtils.java:
##
@@ -60,4 +61,32 @@ public static String
findFirstLineContainingTextsInLogs(final Verifier verifier,
return null;
}
+
+/**
+ * Find lines matching all the strings given as parameter in the log file
attached to a verifier
+ * @param verifier the maven verifier instance
+ * @param texts all the matching strings to find
+ * @return a list of matching strings
+ * @throws VerificationException
+ */
+public static List findLinesContainingTextsInLogs(final Verifier
verifier, final String... texts)
+throws VerificationException {
+List lines = verifier.loadFile(verifier.getBasedir(),
verifier.getLogFileName(), false);
+List result = new ArrayList<>();
+Iterator it = lines.iterator();
+
+while (it.hasNext()) {
+String line = verifier.stripAnsi((String) it.next());
+boolean matches = true;
+Iterator toMatchIterator = Arrays.stream(texts).iterator();
Review Comment:
Done. Slightly changed you proposal since the goal is to test the presence
of all strings.
##
src/main/java/org/apache/maven/buildcache/xml/CacheConfigImpl.java:
##
@@ -503,6 +503,11 @@ public String getAlwaysRunPlugins() {
return getProperty(ALWAYS_RUN_PLUGINS, null);
}
+@Override
+public boolean isMandatoryClean() {
+return getConfiguration().isMandatoryClean();
Review Comment:
Done :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
