[jira] [Created] (MPOM-468) Remove or provide option to disable checksum-maven-plugin
Christopher Tubbs created MPOM-468: -- Summary: Remove or provide option to disable checksum-maven-plugin Key: MPOM-468 URL: https://issues.apache.org/jira/browse/MPOM-468 Project: Maven POMs Issue Type: Bug Components: asf Affects Versions: ASF-31 Reporter: Christopher Tubbs Currently, the net.nicoulaj.maven.plugins:checksum-maven-plugin is used to generate .sha512 files for the source-release classifier artifact in the apache-release profile. There are many problems with this plugin that justify removing it or making it easier to disable: 1. Not everybody wants this. It is intended to help construct SHA512 files in the Nexus staging repository, so people can easily have something to copy over into their DIST area in SVN. But, it's expected that people delete these from the staging repository before releasing the staging repo to Maven central after a successful release vote. Well, not everybody uses this pattern. Some people, like those pushing for MPOM-282, generate sha512 files differently (with the filename, so it can be easily verified with standard tooling). It is inconvenient for this plugin to create extra files in the staging repo that we must deal with, leading to more room for user error during the release process. 2. In the case where users actually don't want to modify the staging repo, but actually release the repo with the source-release artifact (there are many use cases for that), this creates more work, because those people only have to remove stuff from the staging repo *because* of this plugin. It doesn't make it more convenient... it makes it less convenient... to do a release. 3. It doesn't just generate .sha512 files. It also results in .sha512.md1 and .sha512.sha1 files, which are just excessive to deal with. 4. The plugin has not been maintained in 2 years. 5. The plugin's website with all of its generated plugin documentation is no longer functional. 6. The plugin doesn't appear to have a standard "-DmyPluginPrefix.skip" method of disabling the plugin to bypass it. So, one must specifically override the plugin by duplicating the apache-release profile, and creating an execution with the same ID, but with different config to force it to be overridden. 7. None (or very few) of the configuration properties seem to have user properties to set them as a system property or in the POM's properties section. So, that makes it cumbersome to modify the configuration. 8. Because of number 7, this ASF parent POM, must set everything in the XML, and since it hasn't created proxy properties to set things indirectly, the only way to override it is to create a local apache-release profile containing the same plugin, with the same execution id, but with different configuration. For all of these reasons, and probably more, I think this plugin should be removed from the ASF parent POM. If not that, then it should at least be moved to a different profile and disabled by default. If not that, then it should at least be moved to a different profile so it can be easily disabled by choice. If not that, then at the very least, create a proxy property to set the includeClassifiers (and other important options) as properties, so we don't have to jump through hoops to try to override and disable this plugin when a project doesn't want to use it. For reference: https://github.com/nicoulaj/checksum-maven-plugin -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] Bump org.codehaus.plexus:plexus-resources from 1.1.0 to 1.3.0 [maven-checkstyle-plugin]
elharo commented on PR #129: URL: https://github.com/apache/maven-checkstyle-plugin/pull/129#issuecomment-1947752132 @dependabot recreate -- 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.codehaus.plexus:plexus-resources from 1.1.0 to 1.3.0 [maven-checkstyle-plugin]
dependabot[bot] commented on PR #129: URL: https://github.com/apache/maven-checkstyle-plugin/pull/129#issuecomment-1947746466 Looks like this PR is already up-to-date with master! If you'd still like to recreate it from scratch, overwriting any edits, you can request `@dependabot recreate`. -- 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.codehaus.plexus:plexus-resources from 1.1.0 to 1.3.0 [maven-checkstyle-plugin]
elharo commented on PR #129: URL: https://github.com/apache/maven-checkstyle-plugin/pull/129#issuecomment-1947746425 https://github.com/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] please add java 21 support [maven-pmd-plugin]
elharo closed pull request #141: please add java 21 support URL: https://github.com/apache/maven-pmd-plugin/pull/141 -- 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-7868) "Could not acquire lock(s)" error in concurrent maven builds
[
https://issues.apache.org/jira/browse/MNG-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817836#comment-17817836
]
Pino Silvaggio commented on MNG-7868:
-
I have this error, since bumping to 3.9.3
and it's under linux...
!screenshot-1.png!
> "Could not acquire lock(s)" error in concurrent maven builds
>
>
> Key: MNG-7868
> URL: https://issues.apache.org/jira/browse/MNG-7868
> Project: Maven
> Issue Type: Bug
> Environment: windows, maven 3.9.4
>Reporter: Jörg Hohwiller
>Priority: Major
> Attachments: screenshot-1.png
>
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project foo.bar: Execution default-install of goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install failed: Could not
> acquire lock(s) -> [Help 1]
> {code}
> I am using maven 3.9.4 on windows:
> {code}
> $ mvn -v
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: D:\projects\test\software\mvn
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime:
> D:\projects\test\software\java
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> {code}
> I searched for this bug and found issues like MRESOLVER-332 that first look
> identical or similar but do not really seem to be related so I decided to
> create this issue.
> For this bug I made the following observations:
> * it only happens with concurrent builds: {{mvn -T ...}}
> * is seems to be windows related (at least mainly happens on windows)
> * it is in-deterministic and is not so easy to create an isolated and simple
> project and a reproducible scenario that always results in this error.
> However, I get this very often in my current project with many modules (500+).
> * it is not specific to the maven-install-plugin and also happens from other
> spots in maven:
> I also got this stacktrace:
> {code}
> Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire
> write lock for
> 'C:\Users\hohwille\.m2\repository\.locks\artifact~com.caucho~com.springsource.com.caucho~3.2.1.lock'
> in 30 SECONDS
> at
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:202)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:271)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:259)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:352)
> {code}
> See also this related discussion:
> https://github.com/apache/maven-mvnd/issues/836#issuecomment-1702488377
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7868) "Could not acquire lock(s)" error in concurrent maven builds
[
https://issues.apache.org/jira/browse/MNG-7868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pino Silvaggio updated MNG-7868:
Attachment: screenshot-1.png
> "Could not acquire lock(s)" error in concurrent maven builds
>
>
> Key: MNG-7868
> URL: https://issues.apache.org/jira/browse/MNG-7868
> Project: Maven
> Issue Type: Bug
> Environment: windows, maven 3.9.4
>Reporter: Jörg Hohwiller
>Priority: Major
> Attachments: screenshot-1.png
>
>
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install (default-install)
> on project foo.bar: Execution default-install of goal
> org.apache.maven.plugins:maven-install-plugin:3.1.1:install failed: Could not
> acquire lock(s) -> [Help 1]
> {code}
> I am using maven 3.9.4 on windows:
> {code}
> $ mvn -v
> Apache Maven 3.9.4 (dfbb324ad4a7c8fb0bf182e6d91b0ae20e3d2dd9)
> Maven home: D:\projects\test\software\mvn
> Java version: 17.0.5, vendor: Eclipse Adoptium, runtime:
> D:\projects\test\software\java
> Default locale: en_US, platform encoding: UTF-8
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
> {code}
> I searched for this bug and found issues like MRESOLVER-332 that first look
> identical or similar but do not really seem to be related so I decided to
> create this issue.
> For this bug I made the following observations:
> * it only happens with concurrent builds: {{mvn -T ...}}
> * is seems to be windows related (at least mainly happens on windows)
> * it is in-deterministic and is not so easy to create an isolated and simple
> project and a reproducible scenario that always results in this error.
> However, I get this very often in my current project with many modules (500+).
> * it is not specific to the maven-install-plugin and also happens from other
> spots in maven:
> I also got this stacktrace:
> {code}
> Suppressed: java.lang.IllegalStateException: Attempt 1: Could not acquire
> write lock for
> 'C:\Users\hohwille\.m2\repository\.locks\artifact~com.caucho~com.springsource.com.caucho~3.2.1.lock'
> in 30 SECONDS
> at
> org.eclipse.aether.internal.impl.synccontext.named.NamedLockFactoryAdapter$AdaptedLockSyncContext.acquire
> (NamedLockFactoryAdapter.java:202)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:271)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:259)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies
> (DefaultRepositorySystem.java:352)
> {code}
> See also this related discussion:
> https://github.com/apache/maven-mvnd/issues/836#issuecomment-1702488377
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Bump net.sourceforge.plantuml:plantuml from 1.2023.13 to 1.2024.2 [maven-site]
dependabot[bot] closed pull request #492: Bump net.sourceforge.plantuml:plantuml from 1.2023.13 to 1.2024.2 URL: https://github.com/apache/maven-site/pull/492 -- 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 net.sourceforge.plantuml:plantuml from 1.2023.13 to 1.2024.2 [maven-site]
dependabot[bot] commented on PR #492: URL: https://github.com/apache/maven-site/pull/492#issuecomment-1947527203 Superseded by #493. -- 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] Bump net.sourceforge.plantuml:plantuml from 1.2023.13 to 1.2024.3 [maven-site]
dependabot[bot] opened a new pull request, #493: URL: https://github.com/apache/maven-site/pull/493 Bumps [net.sourceforge.plantuml:plantuml](https://github.com/plantuml/plantuml) from 1.2023.13 to 1.2024.3. Commits https://github.com/plantuml/plantuml/commit/c6f150fd4e68997b6a7dd578089e07be2396d3e6";>c6f150f chore: version 1.2024.3 https://github.com/plantuml/plantuml/commit/ad4a1bde571a90492a6b75be79c689714e1dea61";>ad4a1bd feat: adding undocumented support for gzip URL https://github.com/plantuml/plantuml/commit/cfa16d0f609873d3a41874ed8dbc4d1baa05d048";>cfa16d0 chore: version 1.2024.2 https://github.com/plantuml/plantuml/commit/ac8e7853723549c31da4df3be0f345204cfa7d2e";>ac8e785 Merge pull request https://redirect.github.com/plantuml/plantuml/issues/1689";>#1689 from The-Lum/Random https://github.com/plantuml/plantuml/commit/53bcc028cf9423bfd5bd88bbe7144d31bce36f18";>53bcc02 fix: typo on GetAllThemeTest filename https://github.com/plantuml/plantuml/commit/ab09e2ef1f48b0526c11a692345cc2f530c38ee8";>ab09e2e feat: add %get_all_theme builtin function https://github.com/plantuml/plantuml/commit/ab60639f5e9adb03c994a8a0751c775798ba04c1";>ab60639 Merge pull request https://redirect.github.com/plantuml/plantuml/issues/1675";>#1675 from plantuml/dependabot/gradle/org.junit.jupiter-ju... https://github.com/plantuml/plantuml/commit/ababa00835e04a9082690f4eca114b7c6f27d27f";>ababa00 chore(deps): bump org.junit.jupiter:junit-jupiter from 5.10.1 to 5.10.2 https://github.com/plantuml/plantuml/commit/76d1daf5ae224b90c8dbeda278abba1fd7e34bb1";>76d1daf Merge pull request https://redirect.github.com/plantuml/plantuml/issues/1674";>#1674 from plantuml/dependabot/gradle/org.assertj-assertj-... https://github.com/plantuml/plantuml/commit/17d317e53a0e40b443aca68877bb0d0cc4041ea3";>17d317e Merge pull request https://redirect.github.com/plantuml/plantuml/issues/1686";>#1686 from The-Lum/PatchBranch Additional commits viewable in https://github.com/plantuml/plantuml/compare/v1.2023.13...v1.2024.3";>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (MNG-8039) DefaultProjectBuilder should not change given artifact
[
https://issues.apache.org/jira/browse/MNG-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski closed MNG-8039.
Fix Version/s: 4.0.0
4.0.0-alpha-13
Resolution: Fixed
> DefaultProjectBuilder should not change given artifact
> --
>
> Key: MNG-8039
> URL: https://issues.apache.org/jira/browse/MNG-8039
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-12
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-13
>
>
> In {{org.apache.maven.project.DefaultProjectBuilder}} we have a code:
> {code:java}
> File pomFile = pomArtifact.getFile();
> if ("pom".equals(artifact.getType())) {
> artifact.selectVersion(pomArtifact.getVersion());
> artifact.setFile(pomFile);
> artifact.setResolved(true);
> }
> {code}
> Which cause a error for immutable {{TransformedArtifact}}
> Error occurs when plugin try build project for current project attachments,
> like in assembly-m-p
> {noformat}
> Caused by: java.lang.UnsupportedOperationException: transformed artifact file
> cannot be set
> at
> org.apache.maven.internal.transformation.impl.TransformedArtifact.setFile(TransformedArtifact.java:88)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:375)
> 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)
> {noformat}
> In assembly-m-p IT
> {{src/it/projects/dependency-sets/include-project-attachments}} fails.
>
> Introduced in MNG-4791
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8039) DefaultProjectBuilder should not change given artifact
[
https://issues.apache.org/jira/browse/MNG-8039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817796#comment-17817796
]
ASF GitHub Bot commented on MNG-8039:
-
slawekjaranowski merged PR #1408:
URL: https://github.com/apache/maven/pull/1408
> DefaultProjectBuilder should not change given artifact
> --
>
> Key: MNG-8039
> URL: https://issues.apache.org/jira/browse/MNG-8039
> Project: Maven
> Issue Type: Bug
>Affects Versions: 4.0.0-alpha-12
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> In {{org.apache.maven.project.DefaultProjectBuilder}} we have a code:
> {code:java}
> File pomFile = pomArtifact.getFile();
> if ("pom".equals(artifact.getType())) {
> artifact.selectVersion(pomArtifact.getVersion());
> artifact.setFile(pomFile);
> artifact.setResolved(true);
> }
> {code}
> Which cause a error for immutable {{TransformedArtifact}}
> Error occurs when plugin try build project for current project attachments,
> like in assembly-m-p
> {noformat}
> Caused by: java.lang.UnsupportedOperationException: transformed artifact file
> cannot be set
> at
> org.apache.maven.internal.transformation.impl.TransformedArtifact.setFile(TransformedArtifact.java:88)
> at
> org.apache.maven.project.DefaultProjectBuilder$BuildSession.build(DefaultProjectBuilder.java:375)
> 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)
> {noformat}
> In assembly-m-p IT
> {{src/it/projects/dependency-sets/include-project-attachments}} fails.
>
> Introduced in MNG-4791
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Remove old maven.plugin.tools.version property [maven-acr-plugin]
slawekjaranowski merged PR #29: URL: https://github.com/apache/maven-acr-plugin/pull/29 -- 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-8039] Don't change resolved artifact by DefaultProjectBuilder [maven]
slawekjaranowski merged PR #1408: URL: https://github.com/apache/maven/pull/1408 -- 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] Add Dependabot setup [maven-wagon]
rmannibucau commented on PR #96: URL: https://github.com/apache/maven-wagon/pull/96#issuecomment-1947406136 Yeah, this is due to the other project XP and the lack of consensus that I think it may not be worth 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] Add Dependabot setup [maven-wagon]
slachiewicz commented on PR #96: URL: https://github.com/apache/maven-wagon/pull/96#issuecomment-1947404713 Not sure If I understand Your question. Commiters will review if It makes sense, decide if its worth to create Jira and merge it. See other out Maven's projects where we use 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
[jira] [Comment Edited] (MJAR-301) maven jar plugin does not support all cases of ISO 8601 dates for project.build.outputTimestamp
[ https://issues.apache.org/jira/browse/MJAR-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817794#comment-17817794 ] Michael Osipov edited comment on MJAR-301 at 2/15/24 9:54 PM: -- Let's go through: 2022-02-12T15:30:45: Implies local offset, we intentionally require you to provide the offset, the build should be indepent of it otherwise we cannot reliably calcuate back to Zulu 2024-02-15T13:54:59+0100: This input is invalid according to ISO 8601, I can cite from if you want to. 2022-W06 and other with week do not contain any offset, times are local. Leads ot the first issue. 2019-03-26T14:00.9Z: This is valid, but we haven't intentionally implemented a telescoping parsing approach to reduce complexity. Since we have clearly documented the extended ISO datetime format we will parse I consider this more or less as clarified and won't fix. Let me know what you think. [~hboutemy]. was (Author: michael-o): Let's go through: 2022-02-12T15:30:45: Implies local offset, we intentionally require you to provide the offset, the build should be indepent of it otherwise we cannot reliably calcuate back to Zulu 2024-02-15T13:54:59+0100: This input is invalid according to ISO 8601, I can cite from if you want to. 2022-W06 and other with week do not contain any offset, times are local. Leads ot the first issue. 2019-03-26T14:00.9Z: This is valid, but we haven't intentionally implemented a telescoping parsing approach to reduce complexity. [~hboutemy]. Since we have clearly documented the extended ISO datetime format we will parse I consider this more or less as clarified and won't fix. Let me know what you think. > maven jar plugin does not support all cases of ISO 8601 dates for > project.build.outputTimestamp > --- > > Key: MJAR-301 > URL: https://issues.apache.org/jira/browse/MJAR-301 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: S L >Priority: Major > Attachments: git-plugin-timestamp-problem-demo_minimal.zip > > > Originally reported in > [https://github.com/git-commit-id/git-commit-id-maven-plugin/issues/674] by > "Interessierter". > > May or may not be related to https://issues.apache.org/jira/browse/MJAR-300. > > The support for reproducible builds (ISO 8601 date formats) should have been > added to the maven-jar-plugin in version 3.2.X (via > https://issues.apache.org/jira/browse/MJAR-263). > > The documentation of the maven-jar-plugin > ([https://github.com/apache/maven-jar-plugin/blob/63f9c982d49f046519088490d7a8af5a7cd647fb/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java#L144]) > even claims it can process ISO 8601 date formats as input for > project.build.outputTimestamp, however there seems to be some cases that are > unsupported. > > Not supported: > 2022-02-12T15:30:45 > 2024-02-15T13:54:59+0100 (note with an extra ':' like '+01:00' this works) > > Not supported edge cases: > 2022-W06 > 2022-W06-5 > 2022-W06-5T15:30:45 > 2019-03-26T14:00.9Z -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MJAR-301) maven jar plugin does not support all cases of ISO 8601 dates for project.build.outputTimestamp
[ https://issues.apache.org/jira/browse/MJAR-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817794#comment-17817794 ] Michael Osipov commented on MJAR-301: - Let's go through: 2022-02-12T15:30:45: Implies local offset, we intentionally require you to provide the offset, the build should be indepent of it otherwise we cannot reliably calcuate back to Zulu 2024-02-15T13:54:59+0100: This input is invalid according to ISO 8601, I can cite from if you want to. 2022-W06 and other with week do not contain any offset, times are local. Leads ot the first issue. 2019-03-26T14:00.9Z: This is valid, but we haven't intentionally implemented a telescoping parsing approach to reduce complexity. [~hboutemy]. Since we have clearly documented the extended ISO datetime format we will parse I consider this more or less as clarified and won't fix. Let me know what you think. > maven jar plugin does not support all cases of ISO 8601 dates for > project.build.outputTimestamp > --- > > Key: MJAR-301 > URL: https://issues.apache.org/jira/browse/MJAR-301 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: S L >Priority: Major > Attachments: git-plugin-timestamp-problem-demo_minimal.zip > > > Originally reported in > [https://github.com/git-commit-id/git-commit-id-maven-plugin/issues/674] by > "Interessierter". > > May or may not be related to https://issues.apache.org/jira/browse/MJAR-300. > > The support for reproducible builds (ISO 8601 date formats) should have been > added to the maven-jar-plugin in version 3.2.X (via > https://issues.apache.org/jira/browse/MJAR-263). > > The documentation of the maven-jar-plugin > ([https://github.com/apache/maven-jar-plugin/blob/63f9c982d49f046519088490d7a8af5a7cd647fb/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java#L144]) > even claims it can process ISO 8601 date formats as input for > project.build.outputTimestamp, however there seems to be some cases that are > unsupported. > > Not supported: > 2022-02-12T15:30:45 > 2024-02-15T13:54:59+0100 (note with an extra ':' like '+01:00' this works) > > Not supported edge cases: > 2022-W06 > 2022-W06-5 > 2022-W06-5T15:30:45 > 2019-03-26T14:00.9Z -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAR-301) maven jar plugin does not support all cases of ISO 8601 dates for project.build.outputTimestamp
[ https://issues.apache.org/jira/browse/MJAR-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MJAR-301: Description: Originally reported in [https://github.com/git-commit-id/git-commit-id-maven-plugin/issues/674] by "Interessierter". May or may not be related to https://issues.apache.org/jira/browse/MJAR-300. The support for reproducible builds (ISO 8601 date formats) should have been added to the maven-jar-plugin in version 3.2.X (via https://issues.apache.org/jira/browse/MJAR-263). The documentation of the maven-jar-plugin ([https://github.com/apache/maven-jar-plugin/blob/63f9c982d49f046519088490d7a8af5a7cd647fb/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java#L144]) even claims it can process ISO 8601 date formats as input for project.build.outputTimestamp, however there seems to be some cases that are unsupported. Not supported: 2022-02-12T15:30:45 2024-02-15T13:54:59+0100 (note with an extra ':' like '+01:00' this works) Not supported edge cases: 2022-W06 2022-W06-5 2022-W06-5T15:30:45 2019-03-26T14:00.9Z was: Originally reported in [https://github.com/git-commit-id/git-commit-id-maven-plugin/issues/674] by "Interessierter". May or may not be related to https://issues.apache.org/jira/browse/MJAR-300. The support for reproducible builds (ISO8601 date formats) should have been added to the maven-jar-plugin in version 3.2.X (via https://issues.apache.org/jira/browse/MJAR-263). The documentation of the maven-jar-plugin ([https://github.com/apache/maven-jar-plugin/blob/63f9c982d49f046519088490d7a8af5a7cd647fb/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java#L144]) even claims it can process ISO8601 date formats as input for project.build.outputTimestamp, however there seems to be some cases that are unsupported. Not supported: 2022-02-12T15:30:45 2024-02-15T13:54:59+0100 (note with an extra ':' like '+01:00' this works) Not supported edge cases: 2022-W06 2022-W06-5 2022-W06-5T15:30:45 2019-03-26T14:00.9Z Summary: maven jar plugin does not support all cases of ISO 8601 dates for project.build.outputTimestamp (was: maven jar plugin does not support all cases of ISO8601 dates for project.build.outputTimestamp) > maven jar plugin does not support all cases of ISO 8601 dates for > project.build.outputTimestamp > --- > > Key: MJAR-301 > URL: https://issues.apache.org/jira/browse/MJAR-301 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: S L >Priority: Major > Attachments: git-plugin-timestamp-problem-demo_minimal.zip > > > Originally reported in > [https://github.com/git-commit-id/git-commit-id-maven-plugin/issues/674] by > "Interessierter". > > May or may not be related to https://issues.apache.org/jira/browse/MJAR-300. > > The support for reproducible builds (ISO 8601 date formats) should have been > added to the maven-jar-plugin in version 3.2.X (via > https://issues.apache.org/jira/browse/MJAR-263). > > The documentation of the maven-jar-plugin > ([https://github.com/apache/maven-jar-plugin/blob/63f9c982d49f046519088490d7a8af5a7cd647fb/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java#L144]) > even claims it can process ISO 8601 date formats as input for > project.build.outputTimestamp, however there seems to be some cases that are > unsupported. > > Not supported: > 2022-02-12T15:30:45 > 2024-02-15T13:54:59+0100 (note with an extra ':' like '+01:00' this works) > > Not supported edge cases: > 2022-W06 > 2022-W06-5 > 2022-W06-5T15:30:45 > 2019-03-26T14:00.9Z -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SCM-914) InfoItem.lastChangedDate is leaky abstraction
[
https://issues.apache.org/jira/browse/SCM-914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817788#comment-17817788
]
ASF GitHub Bot commented on SCM-914:
michael-o commented on code in PR #193:
URL: https://github.com/apache/maven-scm/pull/193#discussion_r1491006507
##
maven-scm-api/src/main/java/org/apache/maven/scm/command/info/InfoItem.java:
##
@@ -18,7 +18,14 @@
*/
package org.apache.maven.scm.command.info;
+import java.time.OffsetDateTime;
+import java.time.temporal.TemporalAccessor;
+
/**
+ * Encapsulates meta information about one file (or directory) being managed
with an SCM.
Review Comment:
about a
##
maven-scm-api/src/main/java/org/apache/maven/scm/command/info/InfoItem.java:
##
@@ -117,11 +126,31 @@ public void setLastChangedRevision(String
lastChangedRevision) {
this.lastChangedRevision = lastChangedRevision;
}
+/**
+ * @deprecated Use {@link #getLastModifiedDate()} instead
+ */
+@Deprecated
public String getLastChangedDate() {
return lastChangedDate;
}
+/**
+ * @deprecated Use {@link #setLastModifiedDate(TemporalAccessor)} instead
+ */
+@Deprecated
public void setLastChangedDate(String lastChangedDate) {
this.lastChangedDate = lastChangedDate;
}
+
+/**
+ *
+ * @return the date when the file indicated via {@link #getPath()} has
been changed in the SCM for the last time
+ */
+OffsetDateTime getLastModifiedDate() {
+return lastChangedDateTime;
Review Comment:
The name inconsistency is intended?
##
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/info/GitInfoConsumer.java:
##
@@ -18,50 +18,90 @@
*/
package org.apache.maven.scm.provider.git.gitexe.command.info;
-import java.util.ArrayList;
-import java.util.List;
+import java.nio.file.Path;
+import java.time.format.DateTimeFormatter;
import org.apache.commons.lang3.StringUtils;
-import org.apache.maven.scm.ScmFileSet;
import org.apache.maven.scm.command.info.InfoItem;
import org.apache.maven.scm.util.AbstractConsumer;
+import org.codehaus.plexus.util.cli.Arg;
+import org.codehaus.plexus.util.cli.Commandline;
/**
+ * Parses output of {@code git log} with a particular format and populates a
{@link InfoItem}.
+ *
* @author Olivier Lamy
* @since 1.5
+ * @see https://git-scm.com/docs/git-log#_pretty_formats";>Pretty
Formats
*/
public class GitInfoConsumer extends AbstractConsumer {
-// $ git show
-// commit cd3c0dfacb65955e6fbb35c56cc5b1bf8ce4f767
+private final InfoItem infoItem;
+private final int revisionLength;
+
+public GitInfoConsumer(Path path, int revisionLength) {
+infoItem = new InfoItem();
+infoItem.setPath(path.toString());
+infoItem.setURL(path.toUri().toASCIIString());
+this.revisionLength = revisionLength;
+}
+
+enum LineParts {
+HASH(0),
+AUTHOR_NAME(3),
+AUTHOR_EMAIL(2),
+AUTHOR_LAST_MODIFIED(1);
-private final List infoItems = new ArrayList<>(1);
+private final int index;
-private final ScmFileSet scmFileSet;
+LineParts(int index) {
+this.index = index;
+}
-public GitInfoConsumer(ScmFileSet scmFileSet) {
-this.scmFileSet = scmFileSet;
+public int getIndex() {
+return index;
+}
}
/**
+ * @param line the line which is supposed to have the format as specified
by {@link #getFormatArgument()}.
* @see
org.codehaus.plexus.util.cli.StreamConsumer#consumeLine(java.lang.String)
*/
public void consumeLine(String line) {
if (logger.isDebugEnabled()) {
logger.debug("consume line " + line);
}
-if (infoItems.isEmpty()) {
-if (!(line == null || line.isEmpty())) {
-InfoItem infoItem = new InfoItem();
-infoItem.setRevision(StringUtils.trim(line));
-
infoItem.setURL(scmFileSet.getBasedir().toPath().toUri().toASCIIString());
-infoItems.add(infoItem);
-}
+// name must be last token as it may contain separators
+String[] parts = line.split("\\s", 4);
+if (parts.length != 4) {
+throw new IllegalArgumentException(
+"Unexpected line: expecting 4 tokens separated by
whitespace but got " + line);
}
+infoItem.setLastChangedAuthor(
+parts[LineParts.AUTHOR_NAME.getIndex()] + " <" +
parts[LineParts.AUTHOR_EMAIL.getIndex()] + ">");
+String revision = parts[LineParts.HASH.getIndex()];
+if (revisionLength > -1) {
+// do not truncate below 4 characters
+revision = StringUtils.truncate(revision, Integer.max(4,
revision
Re: [PR] [SCM-914] Introduce properly typed last modified date [maven-scm]
michael-o commented on code in PR #193:
URL: https://github.com/apache/maven-scm/pull/193#discussion_r1491006507
##
maven-scm-api/src/main/java/org/apache/maven/scm/command/info/InfoItem.java:
##
@@ -18,7 +18,14 @@
*/
package org.apache.maven.scm.command.info;
+import java.time.OffsetDateTime;
+import java.time.temporal.TemporalAccessor;
+
/**
+ * Encapsulates meta information about one file (or directory) being managed
with an SCM.
Review Comment:
about a
##
maven-scm-api/src/main/java/org/apache/maven/scm/command/info/InfoItem.java:
##
@@ -117,11 +126,31 @@ public void setLastChangedRevision(String
lastChangedRevision) {
this.lastChangedRevision = lastChangedRevision;
}
+/**
+ * @deprecated Use {@link #getLastModifiedDate()} instead
+ */
+@Deprecated
public String getLastChangedDate() {
return lastChangedDate;
}
+/**
+ * @deprecated Use {@link #setLastModifiedDate(TemporalAccessor)} instead
+ */
+@Deprecated
public void setLastChangedDate(String lastChangedDate) {
this.lastChangedDate = lastChangedDate;
}
+
+/**
+ *
+ * @return the date when the file indicated via {@link #getPath()} has
been changed in the SCM for the last time
+ */
+OffsetDateTime getLastModifiedDate() {
+return lastChangedDateTime;
Review Comment:
The name inconsistency is intended?
##
maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/src/main/java/org/apache/maven/scm/provider/git/gitexe/command/info/GitInfoConsumer.java:
##
@@ -18,50 +18,90 @@
*/
package org.apache.maven.scm.provider.git.gitexe.command.info;
-import java.util.ArrayList;
-import java.util.List;
+import java.nio.file.Path;
+import java.time.format.DateTimeFormatter;
import org.apache.commons.lang3.StringUtils;
-import org.apache.maven.scm.ScmFileSet;
import org.apache.maven.scm.command.info.InfoItem;
import org.apache.maven.scm.util.AbstractConsumer;
+import org.codehaus.plexus.util.cli.Arg;
+import org.codehaus.plexus.util.cli.Commandline;
/**
+ * Parses output of {@code git log} with a particular format and populates a
{@link InfoItem}.
+ *
* @author Olivier Lamy
* @since 1.5
+ * @see https://git-scm.com/docs/git-log#_pretty_formats";>Pretty
Formats
*/
public class GitInfoConsumer extends AbstractConsumer {
-// $ git show
-// commit cd3c0dfacb65955e6fbb35c56cc5b1bf8ce4f767
+private final InfoItem infoItem;
+private final int revisionLength;
+
+public GitInfoConsumer(Path path, int revisionLength) {
+infoItem = new InfoItem();
+infoItem.setPath(path.toString());
+infoItem.setURL(path.toUri().toASCIIString());
+this.revisionLength = revisionLength;
+}
+
+enum LineParts {
+HASH(0),
+AUTHOR_NAME(3),
+AUTHOR_EMAIL(2),
+AUTHOR_LAST_MODIFIED(1);
-private final List infoItems = new ArrayList<>(1);
+private final int index;
-private final ScmFileSet scmFileSet;
+LineParts(int index) {
+this.index = index;
+}
-public GitInfoConsumer(ScmFileSet scmFileSet) {
-this.scmFileSet = scmFileSet;
+public int getIndex() {
+return index;
+}
}
/**
+ * @param line the line which is supposed to have the format as specified
by {@link #getFormatArgument()}.
* @see
org.codehaus.plexus.util.cli.StreamConsumer#consumeLine(java.lang.String)
*/
public void consumeLine(String line) {
if (logger.isDebugEnabled()) {
logger.debug("consume line " + line);
}
-if (infoItems.isEmpty()) {
-if (!(line == null || line.isEmpty())) {
-InfoItem infoItem = new InfoItem();
-infoItem.setRevision(StringUtils.trim(line));
-
infoItem.setURL(scmFileSet.getBasedir().toPath().toUri().toASCIIString());
-infoItems.add(infoItem);
-}
+// name must be last token as it may contain separators
+String[] parts = line.split("\\s", 4);
+if (parts.length != 4) {
+throw new IllegalArgumentException(
+"Unexpected line: expecting 4 tokens separated by
whitespace but got " + line);
}
+infoItem.setLastChangedAuthor(
+parts[LineParts.AUTHOR_NAME.getIndex()] + " <" +
parts[LineParts.AUTHOR_EMAIL.getIndex()] + ">");
+String revision = parts[LineParts.HASH.getIndex()];
+if (revisionLength > -1) {
+// do not truncate below 4 characters
+revision = StringUtils.truncate(revision, Integer.max(4,
revisionLength));
+}
+infoItem.setRevision(revision);
+infoItem.setLastModifiedDate(
+
DateTimeFormatter.ISO_OFFSET_DATE_TIME.parse(parts[LineParts.AUTHOR_LAST_MODIFIED.getIndex()]));
+}
+
+public InfoItem
[jira] [Updated] (MRESOLVER-497) Investigate possible solutions for build number diffs on deploy
[ https://issues.apache.org/jira/browse/MRESOLVER-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-497: -- Description: The "snapshot freeze" is a common practice during development: simply use a timestamped snapshot as dependency version instead of "-SNAPSHOT" ending one to "freeze" given snapshot deploy. This works for simple cases (one dependency, or "aligned" reactor). But take a look at Resolver itself: it has new-old and added-gone-readded modules, and their build numbers are different. Problem is, that while timestamp is _same_ (deduced from session start), the build number is determined from remote repository (deploy target) state. This makes "snapshot lock down" impossible on long(er) running projects, like Resolver itself is. was: The "snapshot freeze" is a common practice during development: simply use a timestamped snapshot as dependency version instead of "-SNAPSHOT" ending one to "freeze" given snapshot deploy. This works for simple cases (one dependency, or "aligned" reactor). But take a look at Resolver itself: it has new-old and added-gone-readded modules, and their build numbers are different. Problem is, that while timestamp is _same_ (deduced from session start), the build number is determined from remote repository (deploy target) state. > Investigate possible solutions for build number diffs on deploy > --- > > Key: MRESOLVER-497 > URL: https://issues.apache.org/jira/browse/MRESOLVER-497 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > The "snapshot freeze" is a common practice during development: simply use a > timestamped snapshot as dependency version instead of "-SNAPSHOT" ending one > to "freeze" given snapshot deploy. > This works for simple cases (one dependency, or "aligned" reactor). > But take a look at Resolver itself: it has new-old and added-gone-readded > modules, and their build numbers are different. > Problem is, that while timestamp is _same_ (deduced from session start), the > build number is determined from remote repository (deploy target) state. > This makes "snapshot lock down" impossible on long(er) running projects, like > Resolver itself is. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MRESOLVER-497) Investigate possible solutions for build number diffs on deploy
[ https://issues.apache.org/jira/browse/MRESOLVER-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817782#comment-17817782 ] Tamas Cservenak edited comment on MRESOLVER-497 at 2/15/24 9:17 PM: Some solutions: * use "root" POM buildNumber (memoize it), as most probably it is the "oldest" (biggest buildNo) * make possible to pass in via user property the buildNo user wants and use that: it could allow to "align" all the build numbers, if user chooses max + 1. This would align build numbers on subsequent snapshot deploy, and next alignment would become needed only if another structural change in project (module added/removed and readded) happens. was (Author: cstamas): Some solutions: * use "root" POM buildNumber (memoize it), as most probably it is the "oldest" (biggest buildNo) * make possible to pass in via user property the buildNo user wants and use that: it could allow to "align" all the build numbers, if user chooses max + 1 > Investigate possible solutions for build number diffs on deploy > --- > > Key: MRESOLVER-497 > URL: https://issues.apache.org/jira/browse/MRESOLVER-497 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > The "snapshot freeze" is a common practice during development: simply use a > timestamped snapshot as dependency version instead of "-SNAPSHOT" ending one > to "freeze" given snapshot deploy. > This works for simple cases (one dependency, or "aligned" reactor). > But take a look at Resolver itself: it has new-old and added-gone-readded > modules, and their build numbers are different. > Problem is, that while timestamp is _same_ (deduced from session start), the > build number is determined from remote repository (deploy target) state. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MRESOLVER-497) Investigate possible solutions for build number diffs on deploy
[ https://issues.apache.org/jira/browse/MRESOLVER-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817782#comment-17817782 ] Tamas Cservenak commented on MRESOLVER-497: --- Some solutions: * use "root" POM buildNumber (memoize it), as most probably it is the "oldest" (biggest buildNo) * make possible to pass in via user property the buildNo user wants and use that: it could allow to "align" all the build numbers, if user chooses max + 1 > Investigate possible solutions for build number diffs on deploy > --- > > Key: MRESOLVER-497 > URL: https://issues.apache.org/jira/browse/MRESOLVER-497 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > The "snapshot freeze" is a common practice during development: simply use a > timestamped snapshot as dependency version instead of "-SNAPSHOT" ending one > to "freeze" given snapshot deploy. > This works for simple cases (one dependency, or "aligned" reactor). > But take a look at Resolver itself: it has new-old and added-gone-readded > modules, and their build numbers are different. > Problem is, that while timestamp is _same_ (deduced from session start), the > build number is determined from remote repository (deploy target) state. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-497) Investigate possible solutions for build number diffs on deploy
Tamas Cservenak created MRESOLVER-497: - Summary: Investigate possible solutions for build number diffs on deploy Key: MRESOLVER-497 URL: https://issues.apache.org/jira/browse/MRESOLVER-497 Project: Maven Resolver Issue Type: Task Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0 The "snapshot freeze" is a common practice during development: simply use a timestamped snapshot as dependency version instead of "-SNAPSHOT" ending one to "freeze" given snapshot deploy. This works for simple cases (one dependency, or "aligned" reactor). But take a look at Resolver itself: it has new-old and added-gone-readded modules, and their build numbers are different. Problem is, that while timestamp is _same_ (deduced from session start), the build number is determined from remote repository (deploy target) state. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8050) Same repositories IDs in settings.xml and POM are not detected
[
https://issues.apache.org/jira/browse/MNG-8050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817776#comment-17817776
]
ASF GitHub Bot commented on MNG-8050:
-
cstamas commented on PR #1412:
URL: https://github.com/apache/maven/pull/1412#issuecomment-1947200728
@gnodet ?
> Same repositories IDs in settings.xml and POM are not detected
> --
>
> Key: MNG-8050
> URL: https://issues.apache.org/jira/browse/MNG-8050
> Project: Maven
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> When the same repository ID is used in repositories defined in
> # {{settings.xml}} and
> # POM
> the one from the POM is just silently ignored and no ERROR is emitted.
> OTOH when defining repositories with the same ID in POM the following error
> is emitted:
> {code}
> [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'repositories.repository.id' must be unique
> {code}
> A similar error should be emitted for repository ID clashes in
> {{settings.xml}} (both local and global) and POM
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8050] emit warn in case of repo id clashes between settings and POM [maven]
cstamas commented on PR #1412: URL: https://github.com/apache/maven/pull/1412#issuecomment-1947200728 @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
[jira] [Updated] (MRESOLVER-421) Extend NamedLock API to carry more than one name
[ https://issues.apache.org/jira/browse/MRESOLVER-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-421: -- Fix Version/s: 2.0.0 > Extend NamedLock API to carry more than one name > > > Key: MRESOLVER-421 > URL: https://issues.apache.org/jira/browse/MRESOLVER-421 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Currently NamedLock maps as 1:1 to one "name" (that is artifact or metadata). > We should change this, and allow 1..N mapping. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MRESOLVER-404) New strategy may be needed for Hazelcast named locks
[
https://issues.apache.org/jira/browse/MRESOLVER-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-404:
--
Fix Version/s: 2.0.0
> New strategy may be needed for Hazelcast named locks
>
>
> Key: MRESOLVER-404
> URL: https://issues.apache.org/jira/browse/MRESOLVER-404
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Priority: Major
> Fix For: 2.0.0
>
>
> Originally (for today, see below) Hazelcast NamedLock implementation worked
> like this:
> * on lock acquire, an ISemaphore DO with lock name is created (or just get,
> if exists), is refCounted
> * on lock release, if refCount shows 0 = uses, ISemaphore was destroyed
> (releasing HZ cluster resources)
> * if after some time, a new lock acquire happened for same name, ISemaphore
> DO would get re-created.
> Today, HZ NamedLocks implementation works in following way:
> * there is only one Semaphore provider implementation, the
> {{DirectHazelcastSemaphoreProvider}} that maps lock name 1:1 onto ISemaphore
> Distributed Object (DO) name and does not destroys the DO
> Reason for this is historical: originally, named locks precursor code was
> done for Hazelcast 2/3, that used "unreliable" distributed operations, and
> recreating previously destroyed DO was possible (at the cost of
> "unreliability").
> Since Hazelcast 4.x it updated to RAFT consensus algorithm and made things
> reliable, it was at the cost that DOs once created, then destroyed, could not
> be recreated anymore. This change was applied to
> {{DirectHazelcastSemaphoreProvider}} as well, by simply not dropping unused
> ISemaphores (release semaphore is no-op method).
> But, this has an important consequence: a long running Hazelcast cluster will
> have more and more ISemaphore DOs (basically as many as many Artifacts all
> the builds met, that use this cluster to coordinate). Artifacts count
> existing out there is not infinite, but is large enough -- especially if
> cluster shared across many different/unrelated builds -- to grow over sane
> limit.
> So, current recommendation is to have "large enough" dedicated Hazelcast
> cluster and use {{semaphore-hazelcast-client}} (that is a "thin client" that
> connects to cluster), instead of {{semaphore-hazelcast}} (that is "thick
> client", so puts burden onto JVM process running it as node, hence Maven as
> well). But even then, regular reboot of cluster may be needed.
> A proper but somewhat complicated solution would be to introduce some sort of
> indirection: create as many ISemaphore as needed at the moment, and map those
> onto locks names in use at the moment (and reuse unused semaphores). Problem
> is, that mapping would need to be distributed as well (so all clients pick
> them up, or perform new mapping), and this may cause performance penalty. But
> this could be proved by exhaustive perf testing only.
> The benefit would be obvious: today cluster holds as many ISemaphores as many
> Artifacts were met by all the builds, that use given cluster since cluster
> boot. With indirection, the number of DOs would lowered to "maximum
> concurrently used", so if you have a large build farm, that is able to juggle
> with 1000 artifacts at given one moment, your cluster would have 1000
> ISemaphores.
> Still, with proper "segmenting" of the clusters, for example to have them
> split for "related" job groups, hence, the Artifacts coming thru them would
> remain somewhat within limited boundaries, or some automation for "cluster
> regular reboot", or simply just create "huge enough" clusters, may make users
> benefit of never hitting these issues (cluster OOM).
> And current code is most probably the fastest solution, hence, I just created
> this issue to have it documented, but i plan no meritorious work on this
> topic.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MRESOLVER-301) Resolver should handle signatures in same way as checksums
[ https://issues.apache.org/jira/browse/MRESOLVER-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-301: -- Fix Version/s: 2.0.0 > Resolver should handle signatures in same way as checksums > -- > > Key: MRESOLVER-301 > URL: https://issues.apache.org/jira/browse/MRESOLVER-301 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0 > > > Resolver should handle signatures in same way as checksums: with pluggable > providers, with some sane out of the box offer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MJAR-301) maven jar plugin does not support all cases of ISO8601 dates for project.build.outputTimestamp
S L created MJAR-301: Summary: maven jar plugin does not support all cases of ISO8601 dates for project.build.outputTimestamp Key: MJAR-301 URL: https://issues.apache.org/jira/browse/MJAR-301 Project: Maven JAR Plugin Issue Type: Bug Affects Versions: 3.3.0 Reporter: S L Attachments: git-plugin-timestamp-problem-demo_minimal.zip Originally reported in [https://github.com/git-commit-id/git-commit-id-maven-plugin/issues/674] by "Interessierter". May or may not be related to https://issues.apache.org/jira/browse/MJAR-300. The support for reproducible builds (ISO8601 date formats) should have been added to the maven-jar-plugin in version 3.2.X (via https://issues.apache.org/jira/browse/MJAR-263). The documentation of the maven-jar-plugin ([https://github.com/apache/maven-jar-plugin/blob/63f9c982d49f046519088490d7a8af5a7cd647fb/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java#L144]) even claims it can process ISO8601 date formats as input for project.build.outputTimestamp, however there seems to be some cases that are unsupported. Not supported: 2022-02-12T15:30:45 2024-02-15T13:54:59+0100 (note with an extra ':' like '+01:00' this works) Not supported edge cases: 2022-W06 2022-W06-5 2022-W06-5T15:30:45 2019-03-26T14:00.9Z -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MJAR-301) maven jar plugin does not support all cases of ISO8601 dates for project.build.outputTimestamp
[ https://issues.apache.org/jira/browse/MJAR-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] S L updated MJAR-301: - Attachment: git-plugin-timestamp-problem-demo_minimal.zip > maven jar plugin does not support all cases of ISO8601 dates for > project.build.outputTimestamp > -- > > Key: MJAR-301 > URL: https://issues.apache.org/jira/browse/MJAR-301 > Project: Maven JAR Plugin > Issue Type: Bug >Affects Versions: 3.3.0 >Reporter: S L >Priority: Major > Attachments: git-plugin-timestamp-problem-demo_minimal.zip > > > Originally reported in > [https://github.com/git-commit-id/git-commit-id-maven-plugin/issues/674] by > "Interessierter". > > May or may not be related to https://issues.apache.org/jira/browse/MJAR-300. > > The support for reproducible builds (ISO8601 date formats) should have been > added to the maven-jar-plugin in version 3.2.X (via > https://issues.apache.org/jira/browse/MJAR-263). > > The documentation of the maven-jar-plugin > ([https://github.com/apache/maven-jar-plugin/blob/63f9c982d49f046519088490d7a8af5a7cd647fb/src/main/java/org/apache/maven/plugins/jar/AbstractJarMojo.java#L144]) > even claims it can process ISO8601 date formats as input for > project.build.outputTimestamp, however there seems to be some cases that are > unsupported. > > Not supported: > 2022-02-12T15:30:45 > 2024-02-15T13:54:59+0100 (note with an extra ':' like '+01:00' this works) > > Not supported edge cases: > 2022-W06 > 2022-W06-5 > 2022-W06-5T15:30:45 > 2019-03-26T14:00.9Z -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [I] Building docker image with "dockerfile-maven-plugin" does not work with private (company) registry [maven-mvnd]
ppalaga commented on issue #909: URL: https://github.com/apache/maven-mvnd/issues/909#issuecomment-1946576280 Thanks for the investigation @reissseb. Apparently mvnd does not honor .mavenrc. In case of stock Maven it is sourced inside the `mvn` shell script: ``` if [ -f "$HOME/.mavenrc" ] ; then . "$HOME/.mavenrc" fi ``` It is honored by `mvnd.sh` though - using `mvnd.sh` instead of `mvnd` would be the most straightforward workaround for your problem. I do not think `mvnd.properties` is the right place for this. Another possible way of solving this would be to put those local properties into a profile in settings.xml that would be active by default. @gnodet do you think we should support `.mavenrc`? -- 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] (MRESOLVER-493) Support premanaged of optional, exclusions and properties by DependencyGraphDumper
[
https://issues.apache.org/jira/browse/MRESOLVER-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Cservenak updated MRESOLVER-493:
--
Component/s: Resolver
> Support premanaged of optional, exclusions and properties by
> DependencyGraphDumper
> --
>
> Key: MRESOLVER-493
> URL: https://issues.apache.org/jira/browse/MRESOLVER-493
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 2.0.0-alpha-8, 2.0.0
>
>
> Similar like in
> {{org.apache.maven.project.DefaultProjectDependenciesResolver.GraphLogger}}
> In next step {{GraphLogger}} can be removed from Maven Core
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-480) Update "Upgrading Resolver" page
[ https://issues.apache.org/jira/browse/MRESOLVER-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817731#comment-17817731 ] ASF GitHub Bot commented on MRESOLVER-480: -- cstamas merged PR #429: URL: https://github.com/apache/maven-resolver/pull/429 > Update "Upgrading Resolver" page > > > Key: MRESOLVER-480 > URL: https://issues.apache.org/jira/browse/MRESOLVER-480 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0-alpha-8, 2.0.0 > > > This page: > [https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-6/upgrading-resolver.html] > It needs more, especially regarding scope changes at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MRESOLVER-480) Update "Upgrading Resolver" page
[ https://issues.apache.org/jira/browse/MRESOLVER-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-480. - Resolution: Fixed > Update "Upgrading Resolver" page > > > Key: MRESOLVER-480 > URL: https://issues.apache.org/jira/browse/MRESOLVER-480 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0-alpha-8, 2.0.0 > > > This page: > [https://maven.apache.org/resolver-archives/resolver-2.0.0-alpha-6/upgrading-resolver.html] > It needs more, especially regarding scope changes at least. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MRESOLVER-480] Document latest changes [maven-resolver]
cstamas merged PR #429: URL: https://github.com/apache/maven-resolver/pull/429 -- 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] (MRESOLVER-494) LOCAL_PATH Artifact property really belongs to "system" scope (or is at least very related to it)
[ https://issues.apache.org/jira/browse/MRESOLVER-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak closed MRESOLVER-494. - Resolution: Fixed > LOCAL_PATH Artifact property really belongs to "system" scope (or is at least > very related to it) > - > > Key: MRESOLVER-494 > URL: https://issues.apache.org/jira/browse/MRESOLVER-494 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0-alpha-8, 2.0.0 > > > LOCAL_PATH Artifact property really belongs to "system" scope (or is at least > very related to it). > It may need to be removed as well? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MRESOLVER-496) Move Resolver off java.io.File to NIO2 Paths
[ https://issues.apache.org/jira/browse/MRESOLVER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak reassigned MRESOLVER-496: - Assignee: Tamas Cservenak > Move Resolver off java.io.File to NIO2 Paths > > > Key: MRESOLVER-496 > URL: https://issues.apache.org/jira/browse/MRESOLVER-496 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 2.0.0-alpha-8, 2.0.0 > > > Internally, stop using java.io.File and use NIO2 Paths instead. From outside, > this should not make a lot of difference. > But, as a consequence: if Resolver used on FileSystem like Google JIMFS, > whatever code touches File method (that will do Path.toFile() under the > hood), it will explode. Hence, we need to make sure this call never happens > internally, and leave it to consumer projects. Resolver alone should never > invoke it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MNG-7038) Introduce public properties to point to the root and top directories of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817700#comment-17817700
]
Guillaume Nodet edited comment on MNG-7038 at 2/15/24 3:44 PM:
---
Fwiw, those properties are of type {{java.nio.file.Path}} which may not play
well with maven 3 plugins or alike which only supports {{{}File{}}}. A
workaround is to use {{[the-prop].file}} instead.
!image-2024-02-15-16-44-28-176.png!
was (Author: gnt):
Fwiw, those properties are of type {{java.nio.file.Path}} which may not play
well with maven 3 plugins or alike which only supports {{{}File{}}}. A
workaround is to use {{[the-prop].file}} instead.
{{[INFO] Scanning for projects...
[INFO]
[INFO] < org.apache.maven:maven
>
[INFO] Building Apache Maven 4.0.0-alpha-13-SNAPSHOT
[INFO] from pom.xml
[INFO] -[ pom
]--
[INFO]
[INFO] --- help:3.4.0:evaluate (default-cli) @ maven ---
[INFO] No artifact parameter specified, using
'org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT' as project.
[INFO]
/Users/gnodet/work/git/mvn4/maven
[INFO] Copying org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT to project
local repository
[INFO] Copying org.apache.maven:maven:pom:consumer:4.0.0-alpha-13-SNAPSHOT to
project local repository
[INFO]
--
[INFO] BUILD SUCCESS
[INFO]
--
[INFO] Total time: 0.477 s
[INFO] Finished at: 2024-02-15T16:42:01+01:00
[INFO]
--
}}
> Introduce public properties to point to the root and top directories of
> (multi-module) project
> --
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-7, 4.0.0
>
> Attachments: image-2024-02-15-16-44-28-176.png
>
>
> This issue introduces three properties:
> * {{project.rootDirectory}}: {_}the project's directory or parent directory
> containing a {{.mvn}} subdirectory or a {{pom.xml}} flagged with the
> {{root="true"}} attribute{_}. If no such directory can be found, accessing
> the rootDirectory property will throw an `IllegalStateException`.
> * {{session.topDirectory}} : {_}the directory of the topmost project being
> built, usually the current directory or the directory pointed at by the
> {{\-f}}/{{\-\-file}} command line argument{_}. The {{topDirectory}} is
> similar to the {{executionRootDirectory}} property available on the session,
> but renamed to make it coherent with the new {{rootDirectory}} and to avoid
> using _root_ in its name. The {{topDirectory}} property is computed by the
> CLI as the directory pointed at by the {{\-f}}/{{\-\-file}} command line
> argument, or the current directory if there's no such argument.
> * {{session.rootDirectory}} : {_}the rootDirectory for the topDirectory
> project{_}.
> The {{topDirectory}} and {{rootDirectory}} properties are made available on
> the {{MavenSession}} / {{Session}} and deprecate the
> {{executionRootDirectory}} and {{multiModuleProjectDirectory}} properties.
> The {{rootDirectory}} should never change for a given project and is thus
> made available for profile activation and model interpolation (without the
> {{project.}} prefix, similar to {{basedir}}). The goal is also to make the
> {{rootDirectory}} property also available during [command line arguments
> interpolation|https://issues.apache.org/jira/browse/MNG-6303].
> A {{root}} boolean attribute is also added to the model to indicate that the
> project is the root project. This attribute is only supported if the
> _buildconsumer_ feature is active and removed before the pom is installed or
> deployed. It can be used as an alternative mechanism to the {{.mvn}}
> directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7038) Introduce public properties to point to the root and top directories of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817700#comment-17817700
]
Guillaume Nodet edited comment on MNG-7038 at 2/15/24 3:43 PM:
---
Fwiw, those properties are of type {{java.nio.file.Path}} which may not play
well with maven 3 plugins or alike which only supports {{{}File{}}}. A
workaround is to use {{[the-prop].file}} instead.
{{[INFO] Scanning for projects...
[INFO]
[INFO] < org.apache.maven:maven
>
[INFO] Building Apache Maven 4.0.0-alpha-13-SNAPSHOT
[INFO] from pom.xml
[INFO] -[ pom
]--
[INFO]
[INFO] --- help:3.4.0:evaluate (default-cli) @ maven ---
[INFO] No artifact parameter specified, using
'org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT' as project.
[INFO]
/Users/gnodet/work/git/mvn4/maven
[INFO] Copying org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT to project
local repository
[INFO] Copying org.apache.maven:maven:pom:consumer:4.0.0-alpha-13-SNAPSHOT to
project local repository
[INFO]
--
[INFO] BUILD SUCCESS
[INFO]
--
[INFO] Total time: 0.477 s
[INFO] Finished at: 2024-02-15T16:42:01+01:00
[INFO]
--
}}
was (Author: gnt):
Fwiw, those properties are of type {{java.nio.file.Path}} which may not play
well with maven 3 plugins or alike which only supports {{{}File{}}}. A
workaround is to use {{[the-prop].file}} instead.
> Introduce public properties to point to the root and top directories of
> (multi-module) project
> --
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-7, 4.0.0
>
>
> This issue introduces three properties:
> * {{project.rootDirectory}}: {_}the project's directory or parent directory
> containing a {{.mvn}} subdirectory or a {{pom.xml}} flagged with the
> {{root="true"}} attribute{_}. If no such directory can be found, accessing
> the rootDirectory property will throw an `IllegalStateException`.
> * {{session.topDirectory}} : {_}the directory of the topmost project being
> built, usually the current directory or the directory pointed at by the
> {{\-f}}/{{\-\-file}} command line argument{_}. The {{topDirectory}} is
> similar to the {{executionRootDirectory}} property available on the session,
> but renamed to make it coherent with the new {{rootDirectory}} and to avoid
> using _root_ in its name. The {{topDirectory}} property is computed by the
> CLI as the directory pointed at by the {{\-f}}/{{\-\-file}} command line
> argument, or the current directory if there's no such argument.
> * {{session.rootDirectory}} : {_}the rootDirectory for the topDirectory
> project{_}.
> The {{topDirectory}} and {{rootDirectory}} properties are made available on
> the {{MavenSession}} / {{Session}} and deprecate the
> {{executionRootDirectory}} and {{multiModuleProjectDirectory}} properties.
> The {{rootDirectory}} should never change for a given project and is thus
> made available for profile activation and model interpolation (without the
> {{project.}} prefix, similar to {{basedir}}). The goal is also to make the
> {{rootDirectory}} property also available during [command line arguments
> interpolation|https://issues.apache.org/jira/browse/MNG-6303].
> A {{root}} boolean attribute is also added to the model to indicate that the
> project is the root project. This attribute is only supported if the
> _buildconsumer_ feature is active and removed before the pom is installed or
> deployed. It can be used as an alternative mechanism to the {{.mvn}}
> directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7038) Introduce public properties to point to the root and top directories of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817700#comment-17817700
]
Guillaume Nodet edited comment on MNG-7038 at 2/15/24 3:40 PM:
---
Fwiw, those properties are of type {{java.nio.file.Path}} which may not play
well with maven 3 plugins or alike which only supports {{{}File{}}}. A
workaround is to use {{[the-prop].file}} instead.
was (Author: gnt):
Fwiw, those properties are of type {{java.nio.file.Path}} which may not play
well with maven 3 plugins or alike which only supports {{{}File{}}}. A
workaround is to use {{[the-prop].file}} instead.
{{➜ maven git:(lifecycle) ✗ ~/.sdkman/candidates/maven/4.0.0-alpha-12/bin/mvn
help:evaluate -Dexpression=session.rootDirectory.file -N}}
{{[INFO] Scanning for projects...}}
{{[INFO] }}
{{[INFO] --{-}{{-}}<
org.apache.maven:maven >{{-}}{-}--}}
{{[INFO] Building Apache Maven 4.0.0-alpha-13-SNAPSHOT}}
{{[INFO] from pom.xml}}
{{[INFO] ---{-}{{-}}[ pom
]{{-}}{-}}}
{{[INFO] }}
{{[INFO] — help:3.4.0:evaluate (default-cli) @ maven —}}
{{[INFO] No artifact parameter specified, using
'org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT' as project.}}
{{[INFO] }}
{{/Users/gnodet/work/git/mvn4/maven}}
{{[INFO] Copying org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT to project
local repository}}
{{[INFO] Copying org.apache.maven:maven:pom:consumer:4.0.0-alpha-13-SNAPSHOT to
project local repository}}
{{[INFO]
--}}
{{[INFO] BUILD SUCCESS}}
{{[INFO]
--}}
{{[INFO] Total time: 0.405 s}}
{{[INFO] Finished at: 2024-02-15T15:53:40+01:00}}
{{[INFO]
--}}
> Introduce public properties to point to the root and top directories of
> (multi-module) project
> --
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-7, 4.0.0
>
>
> This issue introduces three properties:
> * {{project.rootDirectory}}: {_}the project's directory or parent directory
> containing a {{.mvn}} subdirectory or a {{pom.xml}} flagged with the
> {{root="true"}} attribute{_}. If no such directory can be found, accessing
> the rootDirectory property will throw an `IllegalStateException`.
> * {{session.topDirectory}} : {_}the directory of the topmost project being
> built, usually the current directory or the directory pointed at by the
> {{\-f}}/{{\-\-file}} command line argument{_}. The {{topDirectory}} is
> similar to the {{executionRootDirectory}} property available on the session,
> but renamed to make it coherent with the new {{rootDirectory}} and to avoid
> using _root_ in its name. The {{topDirectory}} property is computed by the
> CLI as the directory pointed at by the {{\-f}}/{{\-\-file}} command line
> argument, or the current directory if there's no such argument.
> * {{session.rootDirectory}} : {_}the rootDirectory for the topDirectory
> project{_}.
> The {{topDirectory}} and {{rootDirectory}} properties are made available on
> the {{MavenSession}} / {{Session}} and deprecate the
> {{executionRootDirectory}} and {{multiModuleProjectDirectory}} properties.
> The {{rootDirectory}} should never change for a given project and is thus
> made available for profile activation and model interpolation (without the
> {{project.}} prefix, similar to {{basedir}}). The goal is also to make the
> {{rootDirectory}} property also available during [command line arguments
> interpolation|https://issues.apache.org/jira/browse/MNG-6303].
> A {{root}} boolean attribute is also added to the model to indicate that the
> project is the root project. This attribute is only supported if the
> _buildconsumer_ feature is active and removed before the pom is installed or
> deployed. It can be used as an alternative mechanism to the {{.mvn}}
> directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7038) Introduce public properties to point to the root and top directories of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817700#comment-17817700
]
Guillaume Nodet edited comment on MNG-7038 at 2/15/24 3:39 PM:
---
Fwiw, those properties are of type {{java.nio.file.Path}} which may not play
well with maven 3 plugins or alike which only supports {{{}File{}}}. A
workaround is to use {{[the-prop].file}} instead.
{{➜ maven git:(lifecycle) ✗ ~/.sdkman/candidates/maven/4.0.0-alpha-12/bin/mvn
help:evaluate -Dexpression=session.rootDirectory.file -N}}
{{[INFO] Scanning for projects...}}
{{[INFO] }}
{{[INFO] --{-}{{-}}<
org.apache.maven:maven >{{-}}{-}--}}
{{[INFO] Building Apache Maven 4.0.0-alpha-13-SNAPSHOT}}
{{[INFO] from pom.xml}}
{{[INFO] ---{-}{{-}}[ pom
]{{-}}{-}}}
{{[INFO] }}
{{[INFO] — help:3.4.0:evaluate (default-cli) @ maven —}}
{{[INFO] No artifact parameter specified, using
'org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT' as project.}}
{{[INFO] }}
{{/Users/gnodet/work/git/mvn4/maven}}
{{[INFO] Copying org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT to project
local repository}}
{{[INFO] Copying org.apache.maven:maven:pom:consumer:4.0.0-alpha-13-SNAPSHOT to
project local repository}}
{{[INFO]
--}}
{{[INFO] BUILD SUCCESS}}
{{[INFO]
--}}
{{[INFO] Total time: 0.405 s}}
{{[INFO] Finished at: 2024-02-15T15:53:40+01:00}}
{{[INFO]
--}}
was (Author: gnt):
{{➜ maven git:(lifecycle) ✗ ~/.sdkman/candidates/maven/4.0.0-alpha-12/bin/mvn
help:evaluate -Dexpression=session.rootDirectory.file -N}}
{{[INFO] Scanning for projects...}}
{{[INFO] }}
{{[INFO] ---{-}<
org.apache.maven:maven >{-}---}}
{{[INFO] Building Apache Maven 4.0.0-alpha-13-SNAPSHOT}}
{{[INFO] from pom.xml}}
{{[INFO] {-}[ pom
]{-}-}}
{{[INFO] }}
{{[INFO] — help:3.4.0:evaluate (default-cli) @ maven —}}
{{[INFO] No artifact parameter specified, using
'org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT' as project.}}
{{[INFO] }}
{{/Users/gnodet/work/git/mvn4/maven}}
{{[INFO] Copying org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT to project
local repository}}
{{[INFO] Copying org.apache.maven:maven:pom:consumer:4.0.0-alpha-13-SNAPSHOT to
project local repository}}
{{[INFO]
--}}
{{[INFO] BUILD SUCCESS}}
{{[INFO]
--}}
{{[INFO] Total time: 0.405 s}}
{{[INFO] Finished at: 2024-02-15T15:53:40+01:00}}
{{[INFO]
--}}
> Introduce public properties to point to the root and top directories of
> (multi-module) project
> --
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-7, 4.0.0
>
>
> This issue introduces three properties:
> * {{project.rootDirectory}}: {_}the project's directory or parent directory
> containing a {{.mvn}} subdirectory or a {{pom.xml}} flagged with the
> {{root="true"}} attribute{_}. If no such directory can be found, accessing
> the rootDirectory property will throw an `IllegalStateException`.
> * {{session.topDirectory}} : {_}the directory of the topmost project being
> built, usually the current directory or the directory pointed at by the
> {{\-f}}/{{\-\-file}} command line argument{_}. The {{topDirectory}} is
> similar to the {{executionRootDirectory}} property available on the session,
> but renamed to make it coherent with the new {{rootDirectory}} and to avoid
> using _root_ in its name. The {{topDirectory}} property is computed by the
> CLI as the directory pointed at by the {{\-f}}/{{\-\-file}} command line
> argument, or the current directory if there's no such argume
[jira] [Comment Edited] (MNG-7038) Introduce public properties to point to the root and top directories of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817700#comment-17817700
]
Guillaume Nodet edited comment on MNG-7038 at 2/15/24 3:37 PM:
---
{{➜ maven git:(lifecycle) ✗ ~/.sdkman/candidates/maven/4.0.0-alpha-12/bin/mvn
help:evaluate -Dexpression=session.rootDirectory.file -N}}
{{[INFO] Scanning for projects...}}
{{[INFO] }}
{{[INFO] ---{-}<
org.apache.maven:maven >{-}---}}
{{[INFO] Building Apache Maven 4.0.0-alpha-13-SNAPSHOT}}
{{[INFO] from pom.xml}}
{{[INFO] {-}[ pom
]{-}-}}
{{[INFO] }}
{{[INFO] — help:3.4.0:evaluate (default-cli) @ maven —}}
{{[INFO] No artifact parameter specified, using
'org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT' as project.}}
{{[INFO] }}
{{/Users/gnodet/work/git/mvn4/maven}}
{{[INFO] Copying org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT to project
local repository}}
{{[INFO] Copying org.apache.maven:maven:pom:consumer:4.0.0-alpha-13-SNAPSHOT to
project local repository}}
{{[INFO]
--}}
{{[INFO] BUILD SUCCESS}}
{{[INFO]
--}}
{{[INFO] Total time: 0.405 s}}
{{[INFO] Finished at: 2024-02-15T15:53:40+01:00}}
{{[INFO]
--}}
was (Author: gnt):
{{code}}
➜ maven git:(lifecycle) ✗ ~/.sdkman/candidates/maven/4.0.0-alpha-12/bin/mvn
help:evaluate -Dexpression=session.rootDirectory.file -N
[INFO] Scanning for projects...
[INFO]
[INFO] < org.apache.maven:maven
>
[INFO] Building Apache Maven 4.0.0-alpha-13-SNAPSHOT
[INFO] from pom.xml
[INFO] -[ pom
]--
[INFO]
[INFO] --- help:3.4.0:evaluate (default-cli) @ maven ---
[INFO] No artifact parameter specified, using
'org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT' as project.
[INFO]
/Users/gnodet/work/git/mvn4/maven
[INFO] Copying org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT to project
local repository
[INFO] Copying org.apache.maven:maven:pom:consumer:4.0.0-alpha-13-SNAPSHOT to
project local repository
[INFO]
--
[INFO] BUILD SUCCESS
[INFO]
--
[INFO] Total time: 0.405 s
[INFO] Finished at: 2024-02-15T15:53:40+01:00
[INFO]
--
{{code}}
> Introduce public properties to point to the root and top directories of
> (multi-module) project
> --
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-7, 4.0.0
>
>
> This issue introduces three properties:
> * {{project.rootDirectory}}: {_}the project's directory or parent directory
> containing a {{.mvn}} subdirectory or a {{pom.xml}} flagged with the
> {{root="true"}} attribute{_}. If no such directory can be found, accessing
> the rootDirectory property will throw an `IllegalStateException`.
> * {{session.topDirectory}} : {_}the directory of the topmost project being
> built, usually the current directory or the directory pointed at by the
> {{\-f}}/{{\-\-file}} command line argument{_}. The {{topDirectory}} is
> similar to the {{executionRootDirectory}} property available on the session,
> but renamed to make it coherent with the new {{rootDirectory}} and to avoid
> using _root_ in its name. The {{topDirectory}} property is computed by the
> CLI as the directory pointed at by the {{\-f}}/{{\-\-file}} command line
> argument, or the current directory if there's no such argument.
> * {{session.rootDirectory}} : {_}the rootDirectory for the topDirectory
> project{_}.
> The {{topDirectory}} and {{rootDirectory}} properties are made available on
> the {{MavenSession}} / {{Session}} and deprecate the
> {{executionRootDirectory}} and {{multiModuleProj
[jira] [Commented] (MNG-7038) Introduce public properties to point to the root and top directories of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817700#comment-17817700
]
Guillaume Nodet commented on MNG-7038:
--
{{code}}
➜ maven git:(lifecycle) ✗ ~/.sdkman/candidates/maven/4.0.0-alpha-12/bin/mvn
help:evaluate -Dexpression=session.rootDirectory.file -N
[INFO] Scanning for projects...
[INFO]
[INFO] < org.apache.maven:maven
>
[INFO] Building Apache Maven 4.0.0-alpha-13-SNAPSHOT
[INFO] from pom.xml
[INFO] -[ pom
]--
[INFO]
[INFO] --- help:3.4.0:evaluate (default-cli) @ maven ---
[INFO] No artifact parameter specified, using
'org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT' as project.
[INFO]
/Users/gnodet/work/git/mvn4/maven
[INFO] Copying org.apache.maven:maven:pom:4.0.0-alpha-13-SNAPSHOT to project
local repository
[INFO] Copying org.apache.maven:maven:pom:consumer:4.0.0-alpha-13-SNAPSHOT to
project local repository
[INFO]
--
[INFO] BUILD SUCCESS
[INFO]
--
[INFO] Total time: 0.405 s
[INFO] Finished at: 2024-02-15T15:53:40+01:00
[INFO]
--
{{code}}
> Introduce public properties to point to the root and top directories of
> (multi-module) project
> --
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-7, 4.0.0
>
>
> This issue introduces three properties:
> * {{project.rootDirectory}}: {_}the project's directory or parent directory
> containing a {{.mvn}} subdirectory or a {{pom.xml}} flagged with the
> {{root="true"}} attribute{_}. If no such directory can be found, accessing
> the rootDirectory property will throw an `IllegalStateException`.
> * {{session.topDirectory}} : {_}the directory of the topmost project being
> built, usually the current directory or the directory pointed at by the
> {{\-f}}/{{\-\-file}} command line argument{_}. The {{topDirectory}} is
> similar to the {{executionRootDirectory}} property available on the session,
> but renamed to make it coherent with the new {{rootDirectory}} and to avoid
> using _root_ in its name. The {{topDirectory}} property is computed by the
> CLI as the directory pointed at by the {{\-f}}/{{\-\-file}} command line
> argument, or the current directory if there's no such argument.
> * {{session.rootDirectory}} : {_}the rootDirectory for the topDirectory
> project{_}.
> The {{topDirectory}} and {{rootDirectory}} properties are made available on
> the {{MavenSession}} / {{Session}} and deprecate the
> {{executionRootDirectory}} and {{multiModuleProjectDirectory}} properties.
> The {{rootDirectory}} should never change for a given project and is thus
> made available for profile activation and model interpolation (without the
> {{project.}} prefix, similar to {{basedir}}). The goal is also to make the
> {{rootDirectory}} property also available during [command line arguments
> interpolation|https://issues.apache.org/jira/browse/MNG-6303].
> A {{root}} boolean attribute is also added to the model to indicate that the
> project is the root project. This attribute is only supported if the
> _buildconsumer_ feature is active and removed before the pom is installed or
> deployed. It can be used as an alternative mechanism to the {{.mvn}}
> directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7038) Introduce public properties to point to the root and top directories of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817677#comment-17817677
]
Envious Guest edited comment on MNG-7038 at 2/15/24 1:37 PM:
-
[~gnodet] hi Guillaume, i see this ticket is marked as resolved, but I'm
absolutely unsure what the actual fix is, given that project.topdir PR has
never been merged?
Just in case, in 4.0.0-alpha-12 I don't see this property working.
was (Author: anenviousguest):
[~gnodet] hi Guillaume, i see this ticket is marked as resolved, but I'm
absolutely unsure what the actual fix is, given that project.topdir PR has
never been merged?
> Introduce public properties to point to the root and top directories of
> (multi-module) project
> --
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-7, 4.0.0
>
>
> This issue introduces three properties:
> * {{project.rootDirectory}}: {_}the project's directory or parent directory
> containing a {{.mvn}} subdirectory or a {{pom.xml}} flagged with the
> {{root="true"}} attribute{_}. If no such directory can be found, accessing
> the rootDirectory property will throw an `IllegalStateException`.
> * {{session.topDirectory}} : {_}the directory of the topmost project being
> built, usually the current directory or the directory pointed at by the
> {{\-f}}/{{\-\-file}} command line argument{_}. The {{topDirectory}} is
> similar to the {{executionRootDirectory}} property available on the session,
> but renamed to make it coherent with the new {{rootDirectory}} and to avoid
> using _root_ in its name. The {{topDirectory}} property is computed by the
> CLI as the directory pointed at by the {{\-f}}/{{\-\-file}} command line
> argument, or the current directory if there's no such argument.
> * {{session.rootDirectory}} : {_}the rootDirectory for the topDirectory
> project{_}.
> The {{topDirectory}} and {{rootDirectory}} properties are made available on
> the {{MavenSession}} / {{Session}} and deprecate the
> {{executionRootDirectory}} and {{multiModuleProjectDirectory}} properties.
> The {{rootDirectory}} should never change for a given project and is thus
> made available for profile activation and model interpolation (without the
> {{project.}} prefix, similar to {{basedir}}). The goal is also to make the
> {{rootDirectory}} property also available during [command line arguments
> interpolation|https://issues.apache.org/jira/browse/MNG-6303].
> A {{root}} boolean attribute is also added to the model to indicate that the
> project is the root project. This attribute is only supported if the
> _buildconsumer_ feature is active and removed before the pom is installed or
> deployed. It can be used as an alternative mechanism to the {{.mvn}}
> directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7038) Introduce public properties to point to the root and top directories of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817677#comment-17817677
]
Envious Guest edited comment on MNG-7038 at 2/15/24 1:37 PM:
-
[~gnodet] hi Guillaume, i see this ticket is marked as resolved, but I'm
absolutely unsure what the actual fix is, given that project.topdir PR has
never been merged?
was (Author: anenviousguest):
[~gnodet] hi Guillaume, i see this ticket is marked as resolved, but I'm
absolute unsure what the actual fix is, given that project.topdir PR has never
been merged?
> Introduce public properties to point to the root and top directories of
> (multi-module) project
> --
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-7, 4.0.0
>
>
> This issue introduces three properties:
> * {{project.rootDirectory}}: {_}the project's directory or parent directory
> containing a {{.mvn}} subdirectory or a {{pom.xml}} flagged with the
> {{root="true"}} attribute{_}. If no such directory can be found, accessing
> the rootDirectory property will throw an `IllegalStateException`.
> * {{session.topDirectory}} : {_}the directory of the topmost project being
> built, usually the current directory or the directory pointed at by the
> {{\-f}}/{{\-\-file}} command line argument{_}. The {{topDirectory}} is
> similar to the {{executionRootDirectory}} property available on the session,
> but renamed to make it coherent with the new {{rootDirectory}} and to avoid
> using _root_ in its name. The {{topDirectory}} property is computed by the
> CLI as the directory pointed at by the {{\-f}}/{{\-\-file}} command line
> argument, or the current directory if there's no such argument.
> * {{session.rootDirectory}} : {_}the rootDirectory for the topDirectory
> project{_}.
> The {{topDirectory}} and {{rootDirectory}} properties are made available on
> the {{MavenSession}} / {{Session}} and deprecate the
> {{executionRootDirectory}} and {{multiModuleProjectDirectory}} properties.
> The {{rootDirectory}} should never change for a given project and is thus
> made available for profile activation and model interpolation (without the
> {{project.}} prefix, similar to {{basedir}}). The goal is also to make the
> {{rootDirectory}} property also available during [command line arguments
> interpolation|https://issues.apache.org/jira/browse/MNG-6303].
> A {{root}} boolean attribute is also added to the model to indicate that the
> project is the root project. This attribute is only supported if the
> _buildconsumer_ feature is active and removed before the pom is installed or
> deployed. It can be used as an alternative mechanism to the {{.mvn}}
> directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7038) Introduce public properties to point to the root and top directories of (multi-module) project
[
https://issues.apache.org/jira/browse/MNG-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817677#comment-17817677
]
Envious Guest commented on MNG-7038:
[~gnodet] hi Guillaume, i see this ticket is marked as resolved, but I'm
absolute unsure what the actual fix is, given that project.topdir PR has never
been merged?
> Introduce public properties to point to the root and top directories of
> (multi-module) project
> --
>
> Key: MNG-7038
> URL: https://issues.apache.org/jira/browse/MNG-7038
> Project: Maven
> Issue Type: Improvement
>Reporter: Envious Guest
>Assignee: Guillaume Nodet
>Priority: Major
> Fix For: 4.0.0-alpha-7, 4.0.0
>
>
> This issue introduces three properties:
> * {{project.rootDirectory}}: {_}the project's directory or parent directory
> containing a {{.mvn}} subdirectory or a {{pom.xml}} flagged with the
> {{root="true"}} attribute{_}. If no such directory can be found, accessing
> the rootDirectory property will throw an `IllegalStateException`.
> * {{session.topDirectory}} : {_}the directory of the topmost project being
> built, usually the current directory or the directory pointed at by the
> {{\-f}}/{{\-\-file}} command line argument{_}. The {{topDirectory}} is
> similar to the {{executionRootDirectory}} property available on the session,
> but renamed to make it coherent with the new {{rootDirectory}} and to avoid
> using _root_ in its name. The {{topDirectory}} property is computed by the
> CLI as the directory pointed at by the {{\-f}}/{{\-\-file}} command line
> argument, or the current directory if there's no such argument.
> * {{session.rootDirectory}} : {_}the rootDirectory for the topDirectory
> project{_}.
> The {{topDirectory}} and {{rootDirectory}} properties are made available on
> the {{MavenSession}} / {{Session}} and deprecate the
> {{executionRootDirectory}} and {{multiModuleProjectDirectory}} properties.
> The {{rootDirectory}} should never change for a given project and is thus
> made available for profile activation and model interpolation (without the
> {{project.}} prefix, similar to {{basedir}}). The goal is also to make the
> {{rootDirectory}} property also available during [command line arguments
> interpolation|https://issues.apache.org/jira/browse/MNG-6303].
> A {{root}} boolean attribute is also added to the model to indicate that the
> project is the root project. This attribute is only supported if the
> _buildconsumer_ feature is active and removed before the pom is installed or
> deployed. It can be used as an alternative mechanism to the {{.mvn}}
> directory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-8015) Control the type of path where each dependency can be placed
[
https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817653#comment-17817653
]
ASF GitHub Bot commented on MNG-8015:
-
rmannibucau commented on PR #1401:
URL: https://github.com/apache/maven/pull/1401#issuecomment-1945992269
Ok, so no action needed.
side note: it is not random but an heuristic so does not always work indeed
- don't ask me why default is not 100% the classpath, it is statically saner
for 3rd parties even if it enforces more work for jpms apps, but we see the
light so we'll drop it soon :crossed_fingers: .
> Control the type of path where each dependency can be placed
>
>
> Key: MNG-8015
> URL: https://issues.apache.org/jira/browse/MNG-8015
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 4.0.0-alpha-12
>Reporter: Martin Desruisseaux
>Priority: Major
>
> Make possible to declare where each dependency can be placed: on the
> module-path, class-path, agent path, doclet path, taglet path, annotation
> processing path, _etc._ The proposed improvement consists in adding a new
> {{PATH_TYPES}} property that can be associated to dependencies. The property
> value is an array of {{PathType}}, a new enumeration-like class with values
> such as {{CLASSES}}, {{MODULES}}, {{DOCLET}}, _etc._ Contrarily to real Java
> enumerations, this enumeration-like class is extensible: plugins can add
> their own enumeration values. This is required at least for the
> {{--patch-module}} option, where a new {{PathType}} enumeration value need to
> be created for each module to patch.
> Users can control indirectly the {{PathType}} of a dependency by specifying
> the dependency type. Note that there is no direct mapping between the
> dependency type and where the dependency will be placed, but only an indirect
> mapping caused by the fact that using a dependency type implies implicit
> values of some properties such as classifier, and (with this proposal) path
> types:
> * {{jar}} implies {{PathType.CLASSES}} and {{PathType.MODULES}}.
> * {{modular-jar}} implies {{PathType.MODULES}} only.
> * {{classpath-jar}} implies {{PathType.CLASSES}} only.
> * _etc._
> When a plugin requests the paths of dependencies, the plugin specifies the
> types of path it is interested in. For example, a Java compiler plugin can
> specify that it is interested in {{PathType.CLASSES}} and
> {{PathType.MODULES}}, but not {{PathType.DOCLET}}. If a dependency declared
> that it can be placed on the class-path or the doclet-path, only the
> class-path is left after intersection with plugin's request. This is
> important for the next step.
> If, after all filtering such as above paragraph are applied, a dependency has
> only one {{PathType}} left, then there is no ambiguity and we are done.
> Combined with above-cited dependency types like {{modular-jar}} or
> {{classpath-jar}}, this rule allows users to control where the dependency
> will be placed. But if there are two or more {{PathType}} left after
> filtering, then a choice needs to be done. For example if there are both
> {{PathType.CLASSES}} and {{PathType.MODULES}} (which may happen when
> {{jar}} is used), then an heuristic rule similar to Maven 3 can
> be applied: check if a {{module-info.class}} file or an {{Automatic-Name}}
> manifest attribute is present, and base the decision on that.
> This proposal aims to fix MNG-7855.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8015] Control the type of path where each dependency can be placed [maven]
rmannibucau commented on PR #1401: URL: https://github.com/apache/maven/pull/1401#issuecomment-1945992269 Ok, so no action needed. side note: it is not random but an heuristic so does not always work indeed - don't ask me why default is not 100% the classpath, it is statically saner for 3rd parties even if it enforces more work for jpms apps, but we see the light so we'll drop it soon :crossed_fingers: . -- 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-8015) Control the type of path where each dependency can be placed
[
https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817651#comment-17817651
]
ASF GitHub Bot commented on MNG-8015:
-
desruisseaux commented on PR #1401:
URL: https://github.com/apache/maven/pull/1401#issuecomment-1945986433
The workaround is not needed per Java. It is needed because Maven 3 mixes
class-path and module-path in an apparently random way. It is an example of
case where putting the JAR on the class-path breaks the application. Just
putting the `junit-jupiter-engine.jar` on the module-path, as it should be,
fixes the issue and removes completely the need for the workaround.
This problem should indeed by solved by the path work. I reported this story
as a real use case for testing that the proposal works. The criterion for
considering that test as successful is to be able to remove any hacks in
above-cited `pom.xml` file.
> Control the type of path where each dependency can be placed
>
>
> Key: MNG-8015
> URL: https://issues.apache.org/jira/browse/MNG-8015
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 4.0.0-alpha-12
>Reporter: Martin Desruisseaux
>Priority: Major
>
> Make possible to declare where each dependency can be placed: on the
> module-path, class-path, agent path, doclet path, taglet path, annotation
> processing path, _etc._ The proposed improvement consists in adding a new
> {{PATH_TYPES}} property that can be associated to dependencies. The property
> value is an array of {{PathType}}, a new enumeration-like class with values
> such as {{CLASSES}}, {{MODULES}}, {{DOCLET}}, _etc._ Contrarily to real Java
> enumerations, this enumeration-like class is extensible: plugins can add
> their own enumeration values. This is required at least for the
> {{--patch-module}} option, where a new {{PathType}} enumeration value need to
> be created for each module to patch.
> Users can control indirectly the {{PathType}} of a dependency by specifying
> the dependency type. Note that there is no direct mapping between the
> dependency type and where the dependency will be placed, but only an indirect
> mapping caused by the fact that using a dependency type implies implicit
> values of some properties such as classifier, and (with this proposal) path
> types:
> * {{jar}} implies {{PathType.CLASSES}} and {{PathType.MODULES}}.
> * {{modular-jar}} implies {{PathType.MODULES}} only.
> * {{classpath-jar}} implies {{PathType.CLASSES}} only.
> * _etc._
> When a plugin requests the paths of dependencies, the plugin specifies the
> types of path it is interested in. For example, a Java compiler plugin can
> specify that it is interested in {{PathType.CLASSES}} and
> {{PathType.MODULES}}, but not {{PathType.DOCLET}}. If a dependency declared
> that it can be placed on the class-path or the doclet-path, only the
> class-path is left after intersection with plugin's request. This is
> important for the next step.
> If, after all filtering such as above paragraph are applied, a dependency has
> only one {{PathType}} left, then there is no ambiguity and we are done.
> Combined with above-cited dependency types like {{modular-jar}} or
> {{classpath-jar}}, this rule allows users to control where the dependency
> will be placed. But if there are two or more {{PathType}} left after
> filtering, then a choice needs to be done. For example if there are both
> {{PathType.CLASSES}} and {{PathType.MODULES}} (which may happen when
> {{jar}} is used), then an heuristic rule similar to Maven 3 can
> be applied: check if a {{module-info.class}} file or an {{Automatic-Name}}
> manifest attribute is present, and base the decision on that.
> This proposal aims to fix MNG-7855.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8015] Control the type of path where each dependency can be placed [maven]
desruisseaux commented on PR #1401: URL: https://github.com/apache/maven/pull/1401#issuecomment-1945986433 The workaround is not needed per Java. It is needed because Maven 3 mixes class-path and module-path in an apparently random way. It is an example of case where putting the JAR on the class-path breaks the application. Just putting the `junit-jupiter-engine.jar` on the module-path, as it should be, fixes the issue and removes completely the need for the workaround. This problem should indeed by solved by the path work. I reported this story as a real use case for testing that the proposal works. The criterion for considering that test as successful is to be able to remove any hacks in above-cited `pom.xml` file. -- 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-8015) Control the type of path where each dependency can be placed
[
https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817646#comment-17817646
]
ASF GitHub Bot commented on MNG-8015:
-
rmannibucau commented on PR #1401:
URL: https://github.com/apache/maven/pull/1401#issuecomment-1945954174
@desruisseaux I'm not sure I understand the proposal, the "workaround" is
needed per java, do you want surefire to do it implicitly or just use the right
path? Isn't it solved by the type work you did and Guillaume reuses in maven 4?
(trying to convert the statement in actions)
> Control the type of path where each dependency can be placed
>
>
> Key: MNG-8015
> URL: https://issues.apache.org/jira/browse/MNG-8015
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 4.0.0-alpha-12
>Reporter: Martin Desruisseaux
>Priority: Major
>
> Make possible to declare where each dependency can be placed: on the
> module-path, class-path, agent path, doclet path, taglet path, annotation
> processing path, _etc._ The proposed improvement consists in adding a new
> {{PATH_TYPES}} property that can be associated to dependencies. The property
> value is an array of {{PathType}}, a new enumeration-like class with values
> such as {{CLASSES}}, {{MODULES}}, {{DOCLET}}, _etc._ Contrarily to real Java
> enumerations, this enumeration-like class is extensible: plugins can add
> their own enumeration values. This is required at least for the
> {{--patch-module}} option, where a new {{PathType}} enumeration value need to
> be created for each module to patch.
> Users can control indirectly the {{PathType}} of a dependency by specifying
> the dependency type. Note that there is no direct mapping between the
> dependency type and where the dependency will be placed, but only an indirect
> mapping caused by the fact that using a dependency type implies implicit
> values of some properties such as classifier, and (with this proposal) path
> types:
> * {{jar}} implies {{PathType.CLASSES}} and {{PathType.MODULES}}.
> * {{modular-jar}} implies {{PathType.MODULES}} only.
> * {{classpath-jar}} implies {{PathType.CLASSES}} only.
> * _etc._
> When a plugin requests the paths of dependencies, the plugin specifies the
> types of path it is interested in. For example, a Java compiler plugin can
> specify that it is interested in {{PathType.CLASSES}} and
> {{PathType.MODULES}}, but not {{PathType.DOCLET}}. If a dependency declared
> that it can be placed on the class-path or the doclet-path, only the
> class-path is left after intersection with plugin's request. This is
> important for the next step.
> If, after all filtering such as above paragraph are applied, a dependency has
> only one {{PathType}} left, then there is no ambiguity and we are done.
> Combined with above-cited dependency types like {{modular-jar}} or
> {{classpath-jar}}, this rule allows users to control where the dependency
> will be placed. But if there are two or more {{PathType}} left after
> filtering, then a choice needs to be done. For example if there are both
> {{PathType.CLASSES}} and {{PathType.MODULES}} (which may happen when
> {{jar}} is used), then an heuristic rule similar to Maven 3 can
> be applied: check if a {{module-info.class}} file or an {{Automatic-Name}}
> manifest attribute is present, and base the decision on that.
> This proposal aims to fix MNG-7855.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] [MNG-8015] Control the type of path where each dependency can be placed [maven]
rmannibucau commented on PR #1401: URL: https://github.com/apache/maven/pull/1401#issuecomment-1945954174 @desruisseaux I'm not sure I understand the proposal, the "workaround" is needed per java, do you want surefire to do it implicitly or just use the right path? Isn't it solved by the type work you did and Guillaume reuses in maven 4? (trying to convert the statement in actions) -- 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-8015) Control the type of path where each dependency can be placed
[
https://issues.apache.org/jira/browse/MNG-8015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817641#comment-17817641
]
ASF GitHub Bot commented on MNG-8015:
-
desruisseaux commented on PR #1401:
URL: https://github.com/apache/maven/pull/1401#issuecomment-1945902723
As a real world use case for testing the Maven improvements, there is the
following scenario: a project depends on JUnit 5 with `compile` scope (because
the project is a conformance test kit). Everything is JPMS: the project, JUnit
5 and their dependencies. JUnit 5 is itself splitted in many modules, including
the `junit-jupiter-api`, `junit-jupiter-engine` and `junit-platform-commons`
modules.
For a mysterious reason, Maven 3 places `junit-platform-commons` dependency
on the module path, but `junit-jupiter-engine` on the class-path (verified with
`mvn test --debug`). The consequence is that JUnit 5 cannot be launch. The JVM
refuses to start with the following error message: _"class
org.junit.platform.engine.discovery.DiscoverySelectors (in unnamed module
@0x3b2c72c2) cannot access class org.junit.platform.commons.util.Preconditions
(in module org.junit.platform.commons) because module
org.junit.platform.commons does not export org.junit.platform.commons.util to
unnamed module @0x3b2c72c2"_. Translation: **JUnit 5 cannot access its own
internal classes!**
The reason why JUnit 5 cannot access its own classes is because
`junit-platform-commons` allows access to its packages only to other JUnit 5
modules. It can be seen with the following command:
```bash
jar --describe-module -f junit-platform-commons-1.10.2.jar
```
Output snippet (reformatted):
```
qualified exports org.junit.platform.commons.util to
org.junit.jupiter.api
org.junit.jupiter.engine
etc...
```
Because Maven puts `junit-platform-commons` on the module-path, access
restrictions to that JAR are enforced. But because Maven puts
`junit-jupiter-engine` on the class-path, that module is unnamed and
consequently not recognized as a module in above list of modules allowed to
access the `junit-platform-commons` internal packages. Thus the failure to
launch JUnit.
A workaround is to add the following lines in Surefire configuration for
breaking module encapsulation:
```xml
--add-exports
org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
--add-exports
org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
```
We should not be forced to apply such workaround. This real use case is
another demonstration of the need to improve JPMS handling compared to what
Maven 3 does. For testing if this pull request achieves that goal in Maven 4,
we can test if it allows us to remove the above hack from [GeoAPI conformance
pom.xml
file](https://github.com/opengeospatial/geoapi/blob/9e4ff919ef56e52e05767cc85c88e5795081c883/geoapi-conformance/pom.xml#L133).
> Control the type of path where each dependency can be placed
>
>
> Key: MNG-8015
> URL: https://issues.apache.org/jira/browse/MNG-8015
> Project: Maven
> Issue Type: Improvement
> Components: Core
>Affects Versions: 4.0.0-alpha-12
>Reporter: Martin Desruisseaux
>Priority: Major
>
> Make possible to declare where each dependency can be placed: on the
> module-path, class-path, agent path, doclet path, taglet path, annotation
> processing path, _etc._ The proposed improvement consists in adding a new
> {{PATH_TYPES}} property that can be associated to dependencies. The property
> value is an array of {{PathType}}, a new enumeration-like class with values
> such as {{CLASSES}}, {{MODULES}}, {{DOCLET}}, _etc._ Contrarily to real Java
> enumerations, this enumeration-like class is extensible: plugins can add
> their own enumeration values. This is required at least for the
> {{--patch-module}} option, where a new {{PathType}} enumeration value need to
> be created for each module to patch.
> Users can control indirectly the {{PathType}} of a dependency by specifying
> the dependency type. Note that there is no direct mapping between the
> dependency type and where the dependency will be placed, but only an indirect
> mapping caused by the fact that using a dependency type implies implicit
> values of some properties such as classifier, and (with this proposal) path
> types:
> * {{jar}} implies {{PathType.CLASSES}} and {{PathType.MODULES}}.
> * {{modular-jar}} implies {{PathType.MODULES}} only.
> * {{classpath-jar}} implies {{PathType.CLASSES}} only.
> * _etc._
> When a plugin requests the paths of dependencies, the plugin specifies the
> types of path it is interested in. For example, a Java compiler plugin can
Re: [PR] [MNG-8015] Control the type of path where each dependency can be placed [maven]
desruisseaux commented on PR #1401: URL: https://github.com/apache/maven/pull/1401#issuecomment-1945902723 As a real world use case for testing the Maven improvements, there is the following scenario: a project depends on JUnit 5 with `compile` scope (because the project is a conformance test kit). Everything is JPMS: the project, JUnit 5 and their dependencies. JUnit 5 is itself splitted in many modules, including the `junit-jupiter-api`, `junit-jupiter-engine` and `junit-platform-commons` modules. For a mysterious reason, Maven 3 places `junit-platform-commons` dependency on the module path, but `junit-jupiter-engine` on the class-path (verified with `mvn test --debug`). The consequence is that JUnit 5 cannot be launch. The JVM refuses to start with the following error message: _"class org.junit.platform.engine.discovery.DiscoverySelectors (in unnamed module @0x3b2c72c2) cannot access class org.junit.platform.commons.util.Preconditions (in module org.junit.platform.commons) because module org.junit.platform.commons does not export org.junit.platform.commons.util to unnamed module @0x3b2c72c2"_. Translation: **JUnit 5 cannot access its own internal classes!** The reason why JUnit 5 cannot access its own classes is because `junit-platform-commons` allows access to its packages only to other JUnit 5 modules. It can be seen with the following command: ```bash jar --describe-module -f junit-platform-commons-1.10.2.jar ``` Output snippet (reformatted): ``` qualified exports org.junit.platform.commons.util to org.junit.jupiter.api org.junit.jupiter.engine etc... ``` Because Maven puts `junit-platform-commons` on the module-path, access restrictions to that JAR are enforced. But because Maven puts `junit-jupiter-engine` on the class-path, that module is unnamed and consequently not recognized as a module in above list of modules allowed to access the `junit-platform-commons` internal packages. Thus the failure to launch JUnit. A workaround is to add the following lines in Surefire configuration for breaking module encapsulation: ```xml --add-exports org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED --add-exports org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED ``` We should not be forced to apply such workaround. This real use case is another demonstration of the need to improve JPMS handling compared to what Maven 3 does. For testing if this pull request achieves that goal in Maven 4, we can test if it allows us to remove the above hack from [GeoAPI conformance pom.xml file](https://github.com/opengeospatial/geoapi/blob/9e4ff919ef56e52e05767cc85c88e5795081c883/geoapi-conformance/pom.xml#L133). -- 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: [I] Building docker image with "dockerfile-maven-plugin" does not work with private (company) registry [maven-mvnd]
reissseb commented on issue #909: URL: https://github.com/apache/maven-mvnd/issues/909#issuecomment-1945779478 The problem is the property `-Ddockerfile.useMavenSettingsForAuth` of the plugin `dockerfile-maven-plugin`. I set it to `true` in my `.mavenrc` file. Setting it as a CLI option does work: ```bash mvnd package -Ddockerfile.useMavenSettingsForAuth=true ``` So does adding it to the `[project-home]/.mvn/jvm.config` like stated in this comment: https://github.com/apache/maven-mvnd/issues/567#issuecomment-1006673652 But it does not work, when I add it to the user property file `~/.m2/mvnd.properties` like this: `mvnd.jvmArgs=-Ddockerfile.useMavenSettingsForAuth\=true` Stated in this comment: https://github.com/apache/maven-mvnd/issues/567#issuecomment-1006712450 How can I achieve that? Is that even possible? _(we set other options like the path to a keystore with `-Djavax.net.ssl.keyStore`). So I would like to set these options in the property file of the user_ -- 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] (MRESOLVER-496) Move Resolver off java.io.File to NIO2 Paths
[ https://issues.apache.org/jira/browse/MRESOLVER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Cservenak updated MRESOLVER-496: -- Description: Internally, stop using java.io.File and use NIO2 Paths instead. From outside, this should not make a lot of difference. But, as a consequence: if Resolver used on FileSystem like Google JIMFS, whatever code touches File method (that will do Path.toFile() under the hood), it will explode. Hence, we need to make sure this call never happens internally, and leave it to consumer projects. Resolver alone should never invoke it. > Move Resolver off java.io.File to NIO2 Paths > > > Key: MRESOLVER-496 > URL: https://issues.apache.org/jira/browse/MRESOLVER-496 > Project: Maven Resolver > Issue Type: Task > Components: Resolver >Reporter: Tamas Cservenak >Priority: Major > Fix For: 2.0.0-alpha-8, 2.0.0 > > > Internally, stop using java.io.File and use NIO2 Paths instead. From outside, > this should not make a lot of difference. > But, as a consequence: if Resolver used on FileSystem like Google JIMFS, > whatever code touches File method (that will do Path.toFile() under the > hood), it will explode. Hence, we need to make sure this call never happens > internally, and leave it to consumer projects. Resolver alone should never > invoke it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MRESOLVER-496) Move Resolver off java.io.File to NIO2 Paths
Tamas Cservenak created MRESOLVER-496: - Summary: Move Resolver off java.io.File to NIO2 Paths Key: MRESOLVER-496 URL: https://issues.apache.org/jira/browse/MRESOLVER-496 Project: Maven Resolver Issue Type: Task Components: Resolver Reporter: Tamas Cservenak Fix For: 2.0.0-alpha-8, 2.0.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-8053) Profile activation by packaging in the POM
[ https://issues.apache.org/jira/browse/MNG-8053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817608#comment-17817608 ] ASF GitHub Bot commented on MNG-8053: - gnodet merged PR #1410: URL: https://github.com/apache/maven/pull/1410 > Profile activation by packaging in the POM > -- > > Key: MNG-8053 > URL: https://issues.apache.org/jira/browse/MNG-8053 > Project: Maven > Issue Type: Improvement > Components: Profiles >Affects Versions: 4.0.0-alpha-3 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-13 > > > Profile activation based on package has been introduced in [MNG-6609], > however, the model was not really extensible at that time. > This issue is about extending the 4.1.0 model to have a specific activation > field for the packaging. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (MNG-8053) Profile activation by packaging in the POM
[ https://issues.apache.org/jira/browse/MNG-8053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet closed MNG-8053. Resolution: Fixed > Profile activation by packaging in the POM > -- > > Key: MNG-8053 > URL: https://issues.apache.org/jira/browse/MNG-8053 > Project: Maven > Issue Type: Improvement > Components: Profiles >Affects Versions: 4.0.0-alpha-3 >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 4.0.0-alpha-13 > > > Profile activation based on package has been introduced in [MNG-6609], > however, the model was not really extensible at that time. > This issue is about extending the 4.1.0 model to have a specific activation > field for the packaging. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MNG-8053] Profile activation by packaging in the POM [maven]
gnodet merged PR #1410: URL: https://github.com/apache/maven/pull/1410 -- 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] (MNG-8053) Profile activation by packaging in the POM
Guillaume Nodet created MNG-8053: Summary: Profile activation by packaging in the POM Key: MNG-8053 URL: https://issues.apache.org/jira/browse/MNG-8053 Project: Maven Issue Type: Improvement Components: Profiles Affects Versions: 4.0.0-alpha-3 Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 4.0.0-alpha-13 Profile activation based on package has been introduced in [MNG-6609], however, the model was not really extensible at that time. This issue is about extending the 4.1.0 model to have a specific activation field for the packaging. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHARED-1351) Confusing message when copying resources from project's baseDir
[ https://issues.apache.org/jira/browse/MSHARED-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817606#comment-17817606 ] ASF GitHub Bot commented on MSHARED-1351: - abelsromero commented on PR #93: URL: https://github.com/apache/maven-filtering/pull/93#issuecomment-1945593859 Hi, all seems green in CI, except for 1 job that was mysteriously canceled. 🤷 Is there anything else that needs my attention in the PR? Thanks > Confusing message when copying resources from project's baseDir > --- > > Key: MSHARED-1351 > URL: https://issues.apache.org/jira/browse/MSHARED-1351 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-filtering >Affects Versions: maven-filtering-3.3.1 >Reporter: Abel Salgado Romero >Priority: Minor > Fix For: maven-filtering-3.3.2 > > > When the project base dir is used as the origin path, the relativize in > https://github.com/apache/maven-filtering/blob/dce786df4301dab6d51d1eab6bbb79e510327086/src/main/java/org/apache/maven/shared/filtering/DefaultMavenResourcesFiltering.java#L259 > resolves to empty string, resulting in nothing being displayed path after > "from" in the console: > ``` > Copying 118 resources from to target/generated-docs > ``` -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] [MSHARED-1351] Fix console message when origin is baseDir [maven-filtering]
abelsromero commented on PR #93: URL: https://github.com/apache/maven-filtering/pull/93#issuecomment-1945593859 Hi, all seems green in CI, except for 1 job that was mysteriously canceled. 🤷 Is there anything else that needs my attention in the PR? Thanks -- 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] (SUREFIRE-2235) Manage of junit-vintage-engine is inconsistent
[
https://issues.apache.org/jira/browse/SUREFIRE-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski updated SUREFIRE-2235:
--
Description:
We have such situation
{noformat}
if junit-platform-engine present on plugin dependencies - nothing is changed
else
if junit-jupiter-api present and junit-jupiter-engine not preset on test
dependencies
then
add junit-jupiter-engine
and
if {{junit}} present on test dependencies then add junit-vintage-engine
{noformat}
{{junit-vintage-engine}} should be alweys added to runtime dependencies if
JUnit 4 is present
In other case when we start moving or create one test with {{JUnit5}} in
module, all old tests in {{JUnit4}} are silently skipped when we forgot to
explicit add {{junit-vintage-engine}}
artifact {{junit-jupiter}} has a transitive dependencies to
junit-jupiter-engine and junit-platform-engine
but {{junit-jupiter-api}} has no transitive dependencies
so when we use only {{junit-jupiter-api}} - {{junit-vintage-engine}} is added.
was:
We have such situation
{noformat}
if junit-platform-engine present on plugin dependencies - nothing is changed
else
if junit-jupiter-api present on test dependencies then add
junit-jupiter-engine
if {{junit}} present on test dependencies then add junit-vintage-engine
{noformat}
{{junit-vintage-engine}} should be alweys added to runtime dependencies if
JUnit 4 is present
In other case when we start moving or create one test with {{JUnit5}} in
module, all old tests in {{JUnit4}} are silently skipped when we forgot to
explicit add {{junit-vintage-engine}}
artifact {{junit-jupiter}} has a transitive dependencies to
junit-jupiter-engine and junit-platform-engine
but {{junit-jupiter-api}} has no transitive dependencies
so when we use only {{junit-jupiter-api}} - {{junit-vintage-engine}} is added.
> Manage of junit-vintage-engine is inconsistent
> --
>
> Key: SUREFIRE-2235
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2235
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Slawomir Jaranowski
>Priority: Major
>
> We have such situation
> {noformat}
> if junit-platform-engine present on plugin dependencies - nothing is changed
> else
>if junit-jupiter-api present and junit-jupiter-engine not preset on test
> dependencies
>then
> add junit-jupiter-engine
> and
> if {{junit}} present on test dependencies then add junit-vintage-engine
> {noformat}
> {{junit-vintage-engine}} should be alweys added to runtime dependencies if
> JUnit 4 is present
> In other case when we start moving or create one test with {{JUnit5}} in
> module, all old tests in {{JUnit4}} are silently skipped when we forgot to
> explicit add {{junit-vintage-engine}}
> artifact {{junit-jupiter}} has a transitive dependencies to
> junit-jupiter-engine and junit-platform-engine
> but {{junit-jupiter-api}} has no transitive dependencies
> so when we use only {{junit-jupiter-api}} - {{junit-vintage-engine}} is
> added.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
