[GitHub] [maven-enforcer] ajarmoniuk commented on pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
ajarmoniuk commented on PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#issuecomment-1356110388 I'd also gladly use a DependencySelector to exclude artifacts already at the dependency node retrieval level, but if you say everything is public API, I'm not sure whether I am allowed to modify any class. @slawekjaranowski could you please help out? -- 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] (MENFORCER-435) Get rid of maven-dependency-tree dependency
[
https://issues.apache.org/jira/browse/MENFORCER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648871#comment-17648871
]
Andrzej Jarmoniuk commented on MENFORCER-435:
-
Looks like this PR also resolves MENFORCER-434.
> Get rid of maven-dependency-tree dependency
> ---
>
> Key: MENFORCER-435
> URL: https://issues.apache.org/jira/browse/MENFORCER-435
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> As the m-enforcer-p depends on Maven 3.2.5 (since MENFORCER-419) all
> dependency resolutions should be done with Aether API directly instead of
> leveraging https://maven.apache.org/shared/maven-dependency-tree/. At the
> same time the error message should print the full path to the affected
> dependency instead of forcing users to use a dedicated call of {{mvn
> dependency:tree}} to locate the dependency
> (https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-enforcer] ajarmoniuk commented on pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
ajarmoniuk commented on PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#issuecomment-1356090919 Also resolves [MENFORCER-434] -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] ajarmoniuk commented on pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
ajarmoniuk commented on PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#issuecomment-1356057706 @olamy could you have a look as well? 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] (MGPG-93) .asc files are written to a non-existent output directory
[
https://issues.apache.org/jira/browse/MGPG-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pawel Veselov updated MGPG-93:
--
Description:
I think this is an instance of MGPG-44, but for a different assembly.
Attempting to sign .war files created in non-standard location causes build to
fail:
{noformat}
$ mvn package gpg:sign
[INFO] --- maven-gpg-plugin:3.0.1:sign (default-cli) @ b ---
gpg: using "856916A457583513" as default secret key for signing
gpg: can't create
'/home/vps/tmp/gpg-test/mod/target/gpg/../artifacts/b-1-SNAPSHOT.war.asc': No
such file or directory
gpg: signing failed: No such file or directory
{noformat}
Structure to reproduce: [^gpg-test.tar.gz]
This can be worked around with using {{ascDirectory}}, but I figured it should
work without it.
was:
I think this is an instance of MGPG-44, but for a different assembly.
Attempting to sign .war files created in non-standard location causes build to
fail:
{noformat}
$ mvn package gpg:sign
[INFO] --- maven-gpg-plugin:3.0.1:sign (default-cli) @ b ---
gpg: using "856916A457583513" as default secret key for signing
gpg: can't create
'/home/vps/tmp/gpg-test/mod/target/gpg/../artifacts/b-1-SNAPSHOT.war.asc': No
such file or directory
gpg: signing failed: No such file or directory
{noformat}
Structure to reproduce: [^gpg-test.tar.gz]
This can be worked around with using {{ascDirectory}}, but I figured it should
work it.
> .asc files are written to a non-existent output directory
> -
>
> Key: MGPG-93
> URL: https://issues.apache.org/jira/browse/MGPG-93
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Pawel Veselov
>Priority: Major
> Attachments: gpg-test.tar.gz
>
>
> I think this is an instance of MGPG-44, but for a different assembly.
> Attempting to sign .war files created in non-standard location causes build
> to fail:
> {noformat}
> $ mvn package gpg:sign
> [INFO] --- maven-gpg-plugin:3.0.1:sign (default-cli) @ b ---
> gpg: using "856916A457583513" as default secret key for signing
> gpg: can't create
> '/home/vps/tmp/gpg-test/mod/target/gpg/../artifacts/b-1-SNAPSHOT.war.asc': No
> such file or directory
> gpg: signing failed: No such file or directory
> {noformat}
> Structure to reproduce: [^gpg-test.tar.gz]
> This can be worked around with using {{ascDirectory}}, but I figured it
> should work without it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MGPG-93) .asc files are written to a non-existent output directory
[
https://issues.apache.org/jira/browse/MGPG-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pawel Veselov updated MGPG-93:
--
Description:
I think this is an instance of MGPG-44, but for a different assembly.
Attempting to sign .war files created in non-standard location causes build to
fail:
{noformat}
$ mvn package gpg:sign
[INFO] --- maven-gpg-plugin:3.0.1:sign (default-cli) @ b ---
gpg: using "856916A457583513" as default secret key for signing
gpg: can't create
'/home/vps/tmp/gpg-test/mod/target/gpg/../artifacts/b-1-SNAPSHOT.war.asc': No
such file or directory
gpg: signing failed: No such file or directory
{noformat}
Structure to reproduce: [^gpg-test.tar.gz]
This can be worked around with using {{ascDirectory}}, but I figured it should
work it.
was:
I think this is an instance of MGPG-44, but for a different assembly.
Attempting to sign .war files created in non-standard location causes build to
fail:
{noformat}
$ mvn package gpg:sign
[INFO] --- maven-gpg-plugin:3.0.1:sign (default-cli) @ b ---
gpg: using "856916A457583513" as default secret key for signing
gpg: can't create
'/home/vps/tmp/gpg-test/mod/target/gpg/../artifacts/b-1-SNAPSHOT.war.asc': No
such file or directory
gpg: signing failed: No such file or directory
{noformat}
Structure to reproduce: [^gpg-test.tar.gz]
This can be worked around with using `ascDirectory`, but I figured it should
work it.
> .asc files are written to a non-existent output directory
> -
>
> Key: MGPG-93
> URL: https://issues.apache.org/jira/browse/MGPG-93
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Pawel Veselov
>Priority: Major
> Attachments: gpg-test.tar.gz
>
>
> I think this is an instance of MGPG-44, but for a different assembly.
> Attempting to sign .war files created in non-standard location causes build
> to fail:
> {noformat}
> $ mvn package gpg:sign
> [INFO] --- maven-gpg-plugin:3.0.1:sign (default-cli) @ b ---
> gpg: using "856916A457583513" as default secret key for signing
> gpg: can't create
> '/home/vps/tmp/gpg-test/mod/target/gpg/../artifacts/b-1-SNAPSHOT.war.asc': No
> such file or directory
> gpg: signing failed: No such file or directory
> {noformat}
> Structure to reproduce: [^gpg-test.tar.gz]
> This can be worked around with using {{ascDirectory}}, but I figured it
> should work it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MGPG-93) .asc files are written to a non-existent output directory
[
https://issues.apache.org/jira/browse/MGPG-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pawel Veselov updated MGPG-93:
--
Description:
I think this is an instance of MGPG-44, but for a different assembly.
Attempting to sign .war files created in non-standard location causes build to
fail:
{noformat}
$ mvn package gpg:sign
[INFO] --- maven-gpg-plugin:3.0.1:sign (default-cli) @ b ---
gpg: using "856916A457583513" as default secret key for signing
gpg: can't create
'/home/vps/tmp/gpg-test/mod/target/gpg/../artifacts/b-1-SNAPSHOT.war.asc': No
such file or directory
gpg: signing failed: No such file or directory
{noformat}
Structure to reproduce: [^gpg-test.tar.gz]
This can be worked around with using `ascDirectory`, but I figured it should
work it.
was:
I think this is an instance of MGPG-44, but for a different assembly.
Attempting to sign .war files created in non-standard location causes build to
fail:
{noformat}
$ mvn package gpg:sign
[INFO] --- maven-gpg-plugin:3.0.1:sign (default-cli) @ b ---
gpg: using "856916A457583513" as default secret key for signing
gpg: can't create
'/home/vps/tmp/gpg-test/mod/target/gpg/../artifacts/b-1-SNAPSHOT.war.asc': No
such file or directory
gpg: signing failed: No such file or directory
{noformat}
Structure to reproduce: [^gpg-test.tar.gz]
> .asc files are written to a non-existent output directory
> -
>
> Key: MGPG-93
> URL: https://issues.apache.org/jira/browse/MGPG-93
> Project: Maven GPG Plugin
> Issue Type: Bug
>Affects Versions: 3.0.1
>Reporter: Pawel Veselov
>Priority: Major
> Attachments: gpg-test.tar.gz
>
>
> I think this is an instance of MGPG-44, but for a different assembly.
> Attempting to sign .war files created in non-standard location causes build
> to fail:
> {noformat}
> $ mvn package gpg:sign
> [INFO] --- maven-gpg-plugin:3.0.1:sign (default-cli) @ b ---
> gpg: using "856916A457583513" as default secret key for signing
> gpg: can't create
> '/home/vps/tmp/gpg-test/mod/target/gpg/../artifacts/b-1-SNAPSHOT.war.asc': No
> such file or directory
> gpg: signing failed: No such file or directory
> {noformat}
> Structure to reproduce: [^gpg-test.tar.gz]
> This can be worked around with using `ascDirectory`, but I figured it should
> work it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MNG-7633) Add process-package lifecycle phase
Henning Schmiedehausen created MNG-7633: --- Summary: Add process-package lifecycle phase Key: MNG-7633 URL: https://issues.apache.org/jira/browse/MNG-7633 Project: Maven Issue Type: New Feature Components: Core Affects Versions: 4.0.0-alpha-3, 3.8.6 Reporter: Henning Schmiedehausen There are multiple "post processing" plugins that take a created artifact (such as a jar file) and post-process it. Today, the order of e.g. the jar plugin and the shade plugin is purely determined by the order that they appear in the pom file, making this process brittle. The default maven lifecycle has a number of steps with "pre" and "post" phases, e.g. integration-test has "pre-integration-test" and "post-integration-test" or at least "post" phases (e.g. process-sources, process-classes, process-test-classes etc.). The proposal is to add a new lifecycle phase for either Maven 3.9.x or Maven 4.0 which is called "process-package", analog to the process phases above that slots in after "package" and before "pre-integration-test". Running "mvn package" would execute the lifecycle up to and including this phase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-7563) REGRESSION: User properties now override model properties in dependencies
[
https://issues.apache.org/jira/browse/MNG-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648821#comment-17648821
]
Michael Osipov commented on MNG-7563:
-
[~h...@apteryx.fr], have a look at MavenITmng5840ParentVersionRanges.
> REGRESSION: User properties now override model properties in dependencies
> -
>
> Key: MNG-7563
> URL: https://issues.apache.org/jira/browse/MNG-7563
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, POM
>Affects Versions: 3.8.5, 3.8.6
>Reporter: Hervé Guillemet
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate
>
> Attachments: poms.zip
>
>
> An important change has been introduced in 3.8.5 that breaks some existing
> builds: Java system properties now take precedence over default values of
> user properties in dependency POMs. This look like a bug since it's now easy
> to affect dependency behaviors with system properties, a practice that has
> been discouraged. But maybe do you consider this as a new feature ?
> As an example, 3 poms are attached to this ticket.
> After installing projects b and c, building project a with:
> {{mvn package -Ddep=x}}
> used to succeed until 3.8.4 (-D is ignored) but throws error with 3.8.5 and
> 3.8.6 (-D override the default).
> Note that without the setting of the default value for property {{dep}} in
> project b, the build fails with any version of Maven.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7563) REGRESSION: User properties now override model properties in dependencies
[
https://issues.apache.org/jira/browse/MNG-7563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648821#comment-17648821
]
Michael Osipov edited comment on MNG-7563 at 12/16/22 10:32 PM:
[~h...@apteryx.fr], have a look at {{MavenITmng5840ParentVersionRanges.java}}.
was (Author: michael-o):
[~h...@apteryx.fr], have a look at MavenITmng5840ParentVersionRanges.
> REGRESSION: User properties now override model properties in dependencies
> -
>
> Key: MNG-7563
> URL: https://issues.apache.org/jira/browse/MNG-7563
> Project: Maven
> Issue Type: Bug
> Components: Dependencies, POM
>Affects Versions: 3.8.5, 3.8.6
>Reporter: Hervé Guillemet
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate
>
> Attachments: poms.zip
>
>
> An important change has been introduced in 3.8.5 that breaks some existing
> builds: Java system properties now take precedence over default values of
> user properties in dependency POMs. This look like a bug since it's now easy
> to affect dependency behaviors with system properties, a practice that has
> been discouraged. But maybe do you consider this as a new feature ?
> As an example, 3 poms are attached to this ticket.
> After installing projects b and c, building project a with:
> {{mvn package -Ddep=x}}
> used to succeed until 3.8.4 (-D is ignored) but throws error with 3.8.5 and
> 3.8.6 (-D override the default).
> Note that without the setting of the default value for property {{dep}} in
> project b, the build fails with any version of Maven.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7529) Maven resolver makes bad repository choices when resolving version ranges
[ https://issues.apache.org/jira/browse/MNG-7529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7529: Fix Version/s: 3.8.7 (was: 3.8.x-candidate) > Maven resolver makes bad repository choices when resolving version ranges > - > > Key: MNG-7529 > URL: https://issues.apache.org/jira/browse/MNG-7529 > Project: Maven > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.8.6 >Reporter: Henning Schmiedehausen >Assignee: Tamas Cservenak >Priority: Major > Fix For: 3.9.0, 4.0.0-alpha-2, 4.0.0, 3.8.7 > > > This is the same problem as MRESOLVER-270. The problem is actually in the > maven core, not in the resolver. See the description there. > > This bug is a placeholder for the fix PR. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MNG-6801) MavenXpp3Writer doesn't retain order of properties
[ https://issues.apache.org/jira/browse/MNG-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648816#comment-17648816 ] Michael Osipov commented on MNG-6801: - [~gnodet], do you see a reaonsable way to back port his to 3.x? > MavenXpp3Writer doesn't retain order of properties > -- > > Key: MNG-6801 > URL: https://issues.apache.org/jira/browse/MNG-6801 > Project: Maven > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Liana Lupsa >Assignee: Guillaume Nodet >Priority: Major > Fix For: 3.8.x-candidate, 4.0.0-alpha-2, 4.0.0 > > > Context: > We are using pipeline-utility-steps-plugin which is a jenkins plugin which > uses the following classes: > > [https://github.com/jenkinsci/pipeline-utility-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/pipeline/utility/steps/maven/ReadMavenPomStep.java]. > > [https://github.com/jenkinsci/pipeline-utility-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/pipeline/utility/steps/maven/WriteMavenPomStep.java#L32] > In our Jenkins file we have a stage that overwrites the version in the pom > with the computed version and for this we need pipeline-utility-steps-plugin. > The problem is that the tags in the pom.xml are never retained in the same > order. The elements in the pom file are completelly rearranged. > For consistency reasons and idempotency we need to retain the structure and > simply update one line. > Status: > After evaluating the plugin code we noticed that it uses: > > [https://github.com/jenkinsci/pipeline-utility-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/pipeline/utility/steps/maven/WriteMavenPomStep.java#L32] > and imports: > import org.apache.maven.model.io.xpp3.MavenXpp3Writer; > with > [https://maven.apache.org/ref/3.3.9/maven-model/apidocs/src-html/org/apache/maven/model/io/xpp3/MavenXpp3Writer.html] > which uses > XmlSerializer serializer = new MXSerializer(); > > [https://github.com/sonatype/plexus-utils/blob/master/src/main/java/org/codehaus/plexus/util/xml/pull/MXSerializer.java] > We think that maven XmlSerializer causes this problem. > Example of the pom.xml changes: > first build trigger: > run 1: > > 3.1.0 > 1.10.19 > 2.1 > 6.5.1 > 1.18.6 > 4.12 > > run 2: > > 1.10.19 > 3.1.0 > 2.1 > 6.5.1 > 1.18.6 > 4.12 > > and run 3: > > 3.1.0 > 1.10.19 > 2.1 > 6.5.1 > 1.18.6 > 4.12 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7568) [WARNING] The requested profile "ABCDEF" could not be activated because it does not exist.
[
https://issues.apache.org/jira/browse/MNG-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7568:
Fix Version/s: 3.8.7
(was: 3.8.x-candidate)
> [WARNING] The requested profile "ABCDEF" could not be activated because it
> does not exist.
> --
>
> Key: MNG-7568
> URL: https://issues.apache.org/jira/browse/MNG-7568
> Project: Maven
> Issue Type: Bug
> Components: Core, Profiles
>Affects Versions: 3.8.1, 3.8.6
>Reporter: Piotr Zygielo
>Assignee: Martin Kanters
>Priority: Major
> Fix For: 3.9.0, 3.8.7
>
>
> WARNING comes at end of build log if profile is defined in settings.xml (it
> definitely does exist) and even more, I am deactivating it, not activating...
> {code:bash}
> mvn -P!ABCDEF clean test
> {code}
> in fact, profile is deactivated during build so everything goes as expected,
> except misleading message
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (MNG-7621) Parameter '-f' causes ignoring any 'maven.config' (only on Windows)
[
https://issues.apache.org/jira/browse/MNG-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7621.
---
Fix Version/s: 3.8.7
3.9.0
4.0.0
4.0.0-alpha-4
(was: 4.0.x-candidate)
(was: 3.8.x-candidate)
(was: 3.9.0-candidate)
Resolution: Fixed
Fixed with
[828de7e1a8e44da991f113203400953302b8fed8|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=828de7e1a8e44da991f113203400953302b8fed8],
with
[3492f3ae997ef949d926201fc864c4a207fc7659|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=3492f3ae997ef949d926201fc864c4a207fc7659]
for {{maven-3.9.x}} branch, with
[006ea14902a5e807c2ef76c91b9d32ee3e8b4cfc|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=006ea14902a5e807c2ef76c91b9d32ee3e8b4cfc]
for {{maven-3.8.x}} branch.
> Parameter '-f' causes ignoring any 'maven.config' (only on Windows)
> ---
>
> Key: MNG-7621
> URL: https://issues.apache.org/jira/browse/MNG-7621
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.6.3, 3.8.6
> Environment: Windows 10 64Bit EE
> Cygwin 64Bit
>Reporter: Oliver Glowa
>Assignee: Michael Osipov
>Priority: Minor
> Labels: maven
> Fix For: 3.8.7, 3.9.0, 4.0.0, 4.0.0-alpha-4
>
>
> Hello,
> first of all, I didn't find a ticket, related to the possible bug I found
> (keyword "-f" and "maven.config")
> [https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20text%20~%20maven.config%20AND%20text%20~%20-f]
> h1. Analysis
> Here the problem I found:
> When executing maven with parameter "-f" without a file name (e.g. "pom.xml")
> any ".mvn\maven.config" is ignored.
> {noformat}
> C:\projects\projects_github>mvn -f maven-test clean verify
> [INFO] Scanning for projects...
> [INFO]
> [INFO] < com.glowanet.appl:maven-test
> >
> [INFO] Building maven-test 1.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ maven-test ---
> [INFO] Deleting C:\projects\projects_github\maven-test\target
> [INFO]
> [INFO] --- echo-maven-plugin:1.3.2:echo (echo-plugin) @ maven-test ---
> [INFO] plugin active
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> maven-test ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ maven-test
> ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 1 source file to
> C:\projects\projects_github\maven-test\target\classes
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> maven-test ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> C:\projects\projects_github\maven-test\src\test\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
> maven-test ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ maven-test ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ maven-test ---
> [INFO] Building jar:
> C:\projects\projects_github\maven-test\target\maven-test-1.0-SNAPSHOT.jar
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 2.063 s
> [INFO] Finished at: 2022-12-07T14:21:45+01:00
> [INFO]
>
> {noformat}
>
> When the filename is added, the "maven.config" will be recognized (the
> parameter in "maven.config" will activated the profile "profile1")
> {noformat}
> C:\projects\projects_github>mvn -f maven-test\pom.xml clean verify
> [INFO] Scanning for projects...
> [INFO]
> [INFO] < com.glowanet.appl:maven-test
> >
> [INFO] Building maven-test 1.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ maven-test ---
> [INFO] Deleting C:\projects\projects_github\maven-test\target
> [INFO]
> [INFO] --- maven-help-plugin:3.3.0:active-profiles (default) @ maven-test ---
> [INFO]
> Active Profiles for Project 'com.glowanet.appl:maven-test:jar:1.0-SNAPSHOT':
> The following profiles are active:
> - profile1 (source:
[jira] [Commented] (MNG-7621) Parameter '-f' causes ignoring any 'maven.config' (only on Windows)
[
https://issues.apache.org/jira/browse/MNG-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648813#comment-17648813
]
ASF GitHub Bot commented on MNG-7621:
-
asfgit closed pull request #905: [MNG-7621] Parameter '-f' causes ignoring any
'maven.config' (only on…
URL: https://github.com/apache/maven/pull/905
> Parameter '-f' causes ignoring any 'maven.config' (only on Windows)
> ---
>
> Key: MNG-7621
> URL: https://issues.apache.org/jira/browse/MNG-7621
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.6.3, 3.8.6
> Environment: Windows 10 64Bit EE
> Cygwin 64Bit
>Reporter: Oliver Glowa
>Assignee: Michael Osipov
>Priority: Minor
> Labels: maven
> Fix For: 3.8.x-candidate, 3.9.0-candidate, 4.0.x-candidate
>
>
> Hello,
> first of all, I didn't find a ticket, related to the possible bug I found
> (keyword "-f" and "maven.config")
> [https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20text%20~%20maven.config%20AND%20text%20~%20-f]
> h1. Analysis
> Here the problem I found:
> When executing maven with parameter "-f" without a file name (e.g. "pom.xml")
> any ".mvn\maven.config" is ignored.
> {noformat}
> C:\projects\projects_github>mvn -f maven-test clean verify
> [INFO] Scanning for projects...
> [INFO]
> [INFO] < com.glowanet.appl:maven-test
> >
> [INFO] Building maven-test 1.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ maven-test ---
> [INFO] Deleting C:\projects\projects_github\maven-test\target
> [INFO]
> [INFO] --- echo-maven-plugin:1.3.2:echo (echo-plugin) @ maven-test ---
> [INFO] plugin active
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> maven-test ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ maven-test
> ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 1 source file to
> C:\projects\projects_github\maven-test\target\classes
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> maven-test ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> C:\projects\projects_github\maven-test\src\test\resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
> maven-test ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ maven-test ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ maven-test ---
> [INFO] Building jar:
> C:\projects\projects_github\maven-test\target\maven-test-1.0-SNAPSHOT.jar
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 2.063 s
> [INFO] Finished at: 2022-12-07T14:21:45+01:00
> [INFO]
>
> {noformat}
>
> When the filename is added, the "maven.config" will be recognized (the
> parameter in "maven.config" will activated the profile "profile1")
> {noformat}
> C:\projects\projects_github>mvn -f maven-test\pom.xml clean verify
> [INFO] Scanning for projects...
> [INFO]
> [INFO] < com.glowanet.appl:maven-test
> >
> [INFO] Building maven-test 1.0-SNAPSHOT
> [INFO] [ jar
> ]-
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ maven-test ---
> [INFO] Deleting C:\projects\projects_github\maven-test\target
> [INFO]
> [INFO] --- maven-help-plugin:3.3.0:active-profiles (default) @ maven-test ---
> [INFO]
> Active Profiles for Project 'com.glowanet.appl:maven-test:jar:1.0-SNAPSHOT':
> The following profiles are active:
> - profile1 (source: com.glowanet.appl:maven-test:1.0-SNAPSHOT)
> [INFO]
> [INFO] --- echo-maven-plugin:1.3.2:echo (echo-plugin) @ maven-test ---
> [INFO] plugin active
> [INFO]
> [INFO] --- echo-maven-plugin:1.3.2:echo (echo-profile) @ maven-test ---
> [INFO] profile1 active
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> maven-test ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ maven-test
> ---
> [INFO] Changes detected - recompiling the module!
> [INFO]
[GitHub] [maven] asfgit closed pull request #905: [MNG-7621] Parameter '-f' causes ignoring any 'maven.config' (only on…
asfgit closed pull request #905: [MNG-7621] Parameter '-f' causes ignoring any 'maven.config' (only on… URL: https://github.com/apache/maven/pull/905 -- 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-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648790#comment-17648790
]
Michael Osipov commented on MNG-7631:
-
[~gnodet], I don't think that the change is necessarily bad. Think of
{{outputDirectory}} in the assembly descriptor. Same behavior. I think that if
you provide a value it will be used as-is.
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - MNG-7553 New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
>
> Edit: I also tried with {{{}-f {}}}, so the local repository
> root really is {{{}{}}}, not {{}} (even if
> they are the same usually).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (MGPG-93) .asc files are written to a non-existent output directory
Pawel Veselov created MGPG-93:
-
Summary: .asc files are written to a non-existent output directory
Key: MGPG-93
URL: https://issues.apache.org/jira/browse/MGPG-93
Project: Maven GPG Plugin
Issue Type: Bug
Affects Versions: 3.0.1
Reporter: Pawel Veselov
Attachments: gpg-test.tar.gz
I think this is an instance of MGPG-44, but for a different assembly.
Attempting to sign .war files created in non-standard location causes build to
fail:
{noformat}
$ mvn package gpg:sign
[INFO] --- maven-gpg-plugin:3.0.1:sign (default-cli) @ b ---
gpg: using "856916A457583513" as default secret key for signing
gpg: can't create
'/home/vps/tmp/gpg-test/mod/target/gpg/../artifacts/b-1-SNAPSHOT.war.asc': No
such file or directory
gpg: signing failed: No such file or directory
{noformat}
Structure to reproduce: [^gpg-test.tar.gz]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7627) Sonatype Staging plugin does not plug into deploy lifecycle correctly w/ Maven 4
[ https://issues.apache.org/jira/browse/MNG-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lenny Primak updated MNG-7627: -- Summary: Sonatype Staging plugin does not plug into deploy lifecycle correctly w/ Maven 4 (was: Sonatype Staging plugin does not plug into deploy lifecycle correctly) > Sonatype Staging plugin does not plug into deploy lifecycle correctly w/ > Maven 4 > > > Key: MNG-7627 > URL: https://issues.apache.org/jira/browse/MNG-7627 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-2 >Reporter: Lenny Primak >Priority: Minor > > Maven release plugin not working with 4.0-alpha-2 > 3.x works fine with the same configuration. > Build succeeds but the staging repository on maven central is not uploaded -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MNG-7627) Sonatype Staging plugin does not plug into deploy lifecycle correctly
[ https://issues.apache.org/jira/browse/MNG-7627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lenny Primak updated MNG-7627: -- Summary: Sonatype Staging plugin does not plug into deploy lifecycle correctly (was: Maven release plugin doesn't upload artifacts to maven central (sonatype staging plugin)) > Sonatype Staging plugin does not plug into deploy lifecycle correctly > - > > Key: MNG-7627 > URL: https://issues.apache.org/jira/browse/MNG-7627 > Project: Maven > Issue Type: Bug >Affects Versions: 4.0.0-alpha-2 >Reporter: Lenny Primak >Priority: Minor > > Maven release plugin not working with 4.0-alpha-2 > 3.x works fine with the same configuration. > Build succeeds but the staging repository on maven central is not uploaded -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MNG-7632) Regression: combine.children breaks when combining executions
Lenny Primak created MNG-7632: - Summary: Regression: combine.children breaks when combining executions Key: MNG-7632 URL: https://issues.apache.org/jira/browse/MNG-7632 Project: Maven Issue Type: Bug Components: Core Affects Versions: 4.0.0-alpha-2 Reporter: Lenny Primak When upgrading from 3.x to 4.x, combine.children behaves differently. When it is declared in the parent pom, the child pom do not correctly combines elements: See [https://github.com/flowlogix/flowlogix/commit/301f428a229f4ab51e55a488bd71ec4aec87bce4] for a reproducer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-filtering] tommai78101 commented on pull request #15: [MRESOURCES-268] - Report path of offending file on copy/filter error.
tommai78101 commented on PR #15: URL: https://github.com/apache/maven-filtering/pull/15#issuecomment-133419 I see this pull request being referenced from the Apache Maven Resource Plugins changelog: https://blogs.apache.org/maven/entry/apache-maven-resources-plugin-version1 I would like to know if this fixes the `Input length = 1` error seen in Maven build console logs? Or there was no fix at all? -- 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-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648781#comment-17648781
]
ASF GitHub Bot commented on MNG-7559:
-
elharo commented on PR #845:
URL: https://github.com/apache/maven/pull/845#issuecomment-1355537220
Check on the dev mailing list and see of anyone is planning another 3.9
release.
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Priority: Major
> Fix For: 3.9.0
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] elharo commented on pull request #845: [MNG-7559] Fix versions comparison
elharo commented on PR #845: URL: https://github.com/apache/maven/pull/845#issuecomment-1355537220 Check on the dev mailing list and see of anyone is planning another 3.9 release. -- 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-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648778#comment-17648778
]
ASF GitHub Bot commented on MNG-7559:
-
sultan commented on PR #887:
URL: https://github.com/apache/maven/pull/887#issuecomment-1355520097
this is a backport from maven 4 to maven 3:
* #845
the quoted PR had successful result on CI. any help appreciated on passing
this PR results
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Priority: Major
> Fix For: 3.9.0
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] sultan commented on pull request #887: [MNG-7559] Fix versions comparison, backport to 3.9.x
sultan commented on PR #887: URL: https://github.com/apache/maven/pull/887#issuecomment-1355520097 this is a backport from maven 4 to maven 3: * #845 the quoted PR had successful result on CI. any help appreciated on passing this PR results -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-plugin] pzygielo opened a new pull request, #274: Remove unused local variable
pzygielo opened a new pull request, #274: URL: https://github.com/apache/maven-dependency-plugin/pull/274 - [x] I hereby declare this contribution to be licensed under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) -- 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-7559) ComparableVersion vs versions with custom qualifiers
[
https://issues.apache.org/jira/browse/MNG-7559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648775#comment-17648775
]
ASF GitHub Bot commented on MNG-7559:
-
sultan commented on PR #845:
URL: https://github.com/apache/maven/pull/845#issuecomment-1355512813
@elharo is it wished to port this to 3.9.x branch? if so a PR is available
here:
* PR #887
> ComparableVersion vs versions with custom qualifiers
>
>
> Key: MNG-7559
> URL: https://issues.apache.org/jira/browse/MNG-7559
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.8.3
>Reporter: Andrzej Jarmoniuk
>Priority: Major
> Fix For: 3.9.0
>
> Attachments: image-2022-10-22-18-22-11-591.png
>
>
> Since I know that ComparableVersion was brought to Maven from
> versions-maven-plugin, it turns out the bug described here:
> https://github.com/mojohaus/versions-maven-plugin/issues/744
> also exists in maven, at least in 3.8.3.
> According to the maven version spec, versions containing a qualifier should
> be treated as less major than the same versions without the qualifier.
> Currently it's only the case for a few "standard" qualifiers, e.g. "-rc*",
> "-alpha", etc.
> However, it looks like "2.3-pfd" is deemed less major than "2.3".
> {code:java}
> @Test
> public void testComparableVersionWithCustomQualifier()
> {
> assertThat( new ComparableVersion( "2.3" ).compareTo( new
> ComparableVersion( "2.3-pfd" ) ),
> greaterThan( 0 ) );
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] sultan commented on pull request #845: [MNG-7559] Fix versions comparison
sultan commented on PR #845: URL: https://github.com/apache/maven/pull/845#issuecomment-1355512813 @elharo is it wished to port this to 3.9.x branch? if so a PR is available here: * PR #887 -- 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-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648728#comment-17648728
]
Guillaume Nodet commented on MNG-7631:
--
I agree, this is an unintended regression. We need to pinpoint where it comes
from.
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - MNG-7553 New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
>
> Edit: I also tried with {{{}-f {}}}, so the local repository
> root really is {{{}{}}}, not {{}} (even if
> they are the same usually).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648726#comment-17648726
]
Michael Osipov commented on MNG-7631:
-
I'd like to hear [~gnodet]'s opinion. For me, this feels like an unintentional
cleanup for consistency.
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - MNG-7553 New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
>
> Edit: I also tried with {{{}-f {}}}, so the local repository
> root really is {{{}{}}}, not {{}} (even if
> they are the same usually).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-enforcer] ajarmoniuk commented on a diff in pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
ajarmoniuk commented on code in PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#discussion_r1050911744 ## enforcer-rules/pom.xml: ## @@ -112,22 +112,6 @@ mockito-core test - Review Comment: Ok, will restore; please keep the review comments coming, I'll process them later. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] ajarmoniuk commented on pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
ajarmoniuk commented on PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#issuecomment-1355137055 Closed by mistake... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on a diff in pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
kwin commented on code in PR #198:
URL: https://github.com/apache/maven-enforcer/pull/198#discussion_r1050910244
##
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedDependenciesBase.java:
##
@@ -0,0 +1,195 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.plugins.enforcer;
+
+import com.google.common.base.Strings;
+import java.util.List;
+import org.apache.maven.artifact.Artifact;
+import org.apache.maven.enforcer.rule.api.EnforcerRuleException;
+import org.apache.maven.enforcer.rule.api.EnforcerRuleHelper;
+import org.apache.maven.execution.MavenSession;
+import org.apache.maven.plugins.enforcer.utils.ArtifactUtils;
+import
org.codehaus.plexus.component.configurator.expression.ExpressionEvaluationException;
+import org.eclipse.aether.graph.DependencyNode;
+
+/**
+ * Abstract base class for rules which validate the transitive
+ * dependency tree by traversing all children and validating every
+ * dependency artifact.
+ */
+public abstract class BannedDependenciesBase extends
AbstractNonCacheableEnforcerRule {
Review Comment:
Sorry, just package protected obviously.
--
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] (MENFORCER-435) Get rid of maven-dependency-tree dependency
[ https://issues.apache.org/jira/browse/MENFORCER-435 ]
Andrzej Jarmoniuk deleted comment on MENFORCER-435:
-
was (Author: ajarmoniuk):
https://github.com/apache/maven-enforcer/pull/198
> Get rid of maven-dependency-tree dependency
> ---
>
> Key: MENFORCER-435
> URL: https://issues.apache.org/jira/browse/MENFORCER-435
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> As the m-enforcer-p depends on Maven 3.2.5 (since MENFORCER-419) all
> dependency resolutions should be done with Aether API directly instead of
> leveraging https://maven.apache.org/shared/maven-dependency-tree/. At the
> same time the error message should print the full path to the affected
> dependency instead of forcing users to use a dedicated call of {{mvn
> dependency:tree}} to locate the dependency
> (https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] cpfeiffer commented on a diff in pull request #554: [SUREFIRE-2109] Add suffix derived from current user to Surefire temp directory name and make directory writable for all
cpfeiffer commented on code in PR #554: URL: https://github.com/apache/maven-surefire/pull/554#discussion_r1050900556 ## surefire-api/src/main/java/org/apache/maven/surefire/api/util/TempFileManager.java: ## @@ -180,6 +180,8 @@ public synchronized File createTempFile( String prefix, String suffix ) throw new UncheckedIOException( new IOException( "Unable to create temporary directory " + tempDir.getAbsolutePath() ) ); } +// try to make temp file directory writable for all +tempDir.setWritable( true, false ); Review Comment: Security-wise, I don't think it's a good idea to have a shared directory with other users. Why would you need this? Also, why not use `java.nio.file.Files.createTempDirectory()` and specify 'surefire-' + the username as prefix? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] ajarmoniuk closed pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
ajarmoniuk closed pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver URL: https://github.com/apache/maven-enforcer/pull/198 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] ajarmoniuk commented on a diff in pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
ajarmoniuk commented on code in PR #198:
URL: https://github.com/apache/maven-enforcer/pull/198#discussion_r1050900528
##
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedDependenciesBase.java:
##
@@ -0,0 +1,195 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.plugins.enforcer;
+
+import com.google.common.base.Strings;
+import java.util.List;
+import org.apache.maven.artifact.Artifact;
+import org.apache.maven.enforcer.rule.api.EnforcerRuleException;
+import org.apache.maven.enforcer.rule.api.EnforcerRuleHelper;
+import org.apache.maven.execution.MavenSession;
+import org.apache.maven.plugins.enforcer.utils.ArtifactUtils;
+import
org.codehaus.plexus.component.configurator.expression.ExpressionEvaluationException;
+import org.eclipse.aether.graph.DependencyNode;
+
+/**
+ * Abstract base class for rules which validate the transitive
+ * dependency tree by traversing all children and validating every
+ * dependency artifact.
+ */
+public abstract class BannedDependenciesBase extends
AbstractNonCacheableEnforcerRule {
Review Comment:
A final abstract class?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on a diff in pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
kwin commented on code in PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#discussion_r1050887758 ## enforcer-rules/pom.xml: ## @@ -112,22 +112,6 @@ mockito-core test - Review Comment: you cannot remove that unfortunately without breaking backwards compatibility (maybe add a TODO already that this should be removed with m-enforcer 4.0.0) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on a diff in pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
kwin commented on code in PR #198:
URL: https://github.com/apache/maven-enforcer/pull/198#discussion_r1050886285
##
enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedDependenciesBase.java:
##
@@ -0,0 +1,195 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.maven.plugins.enforcer;
+
+import com.google.common.base.Strings;
+import java.util.List;
+import org.apache.maven.artifact.Artifact;
+import org.apache.maven.enforcer.rule.api.EnforcerRuleException;
+import org.apache.maven.enforcer.rule.api.EnforcerRuleHelper;
+import org.apache.maven.execution.MavenSession;
+import org.apache.maven.plugins.enforcer.utils.ArtifactUtils;
+import
org.codehaus.plexus.component.configurator.expression.ExpressionEvaluationException;
+import org.eclipse.aether.graph.DependencyNode;
+
+/**
+ * Abstract base class for rules which validate the transitive
+ * dependency tree by traversing all children and validating every
+ * dependency artifact.
+ */
+public abstract class BannedDependenciesBase extends
AbstractNonCacheableEnforcerRule {
Review Comment:
Please make this class final (and probably also package protected) to
prevent this from being extended by custom rules. I wouldn't necessarily expose
further classes to custom rules.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on a diff in pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
kwin commented on code in PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#discussion_r1050880475 ## enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java: ## @@ -18,22 +18,15 @@ */ Review Comment: @slawekjaranowski Which classes do you consider so relevant that we need to ensure backwards-compatibility (again all of them are exposed to custom rules unfortunately) -- 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] (MSHADE-265) correct merging of module-info in shades
[
https://issues.apache.org/jira/browse/MSHADE-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648685#comment-17648685
]
Sebastian Stenzel commented on MSHADE-265:
--
Not sure if this is even on the roadmap, but for the record, I want to add
something that needs to be taken care of by when applying package relocations:
The jar tool adds the optional {{ModulePackages}} attribute to the
{{{}module-info.class{}}}. If it is present, it is required to contain an
exhaustive list of the jar's packages, because the class loader uses this as
the single source of truth and ignores any unlisted packages.
I.e. when relocating packages, this attribute needs to be updated _or_ deleted
(so the class loader falls back to scanning the whole jar). Otherwise a shaded
jar will cause {{NoClassDefFoundErrors}} at runtime.
See Alan Bateman's comment on [this StackOverflow
post|https://stackoverflow.com/q/51532510/4014509]:
{quote}Tools or plugins doing this must update the value of the ModulePackages
attribute.
{quote}
> correct merging of module-info in shades
>
>
> Key: MSHADE-265
> URL: https://issues.apache.org/jira/browse/MSHADE-265
> Project: Maven Shade Plugin
> Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>Priority: Trivial
>
> Should work by merging of the encountered module info jut also automatic
> module name in manifest. The hard part being removing the not needed entries
> which are sometimes not simply the ones of the included classes - SPI need it
> still
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-enforcer] ajarmoniuk commented on pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
ajarmoniuk commented on PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#issuecomment-1354975012 I see. I was under the impression that the API for custom rule creators was the `enforcer-api` module. That was at least what I used when I created the custom enforcer rule in `versions-maven-plugin`. Didn't know `AbstractBanDependencies` was intended to be used as API for external rules. Perhaps it should be stated more clearly that it's also part of the API for custom rules. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on a diff in pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
kwin commented on code in PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#discussion_r1050813950 ## enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java: ## @@ -18,22 +18,15 @@ */ Review Comment: See also https://github.com/apache/maven-enforcer/pull/167. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on a diff in pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
kwin commented on code in PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#discussion_r1050795396 ## enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java: ## @@ -18,22 +18,15 @@ */ Review Comment: API here just means it is exported via the class path to all custom rules and can be accessed and extended. It doesn't say anything about design Potentially that affects every rule which is not a final class (because there is no limited visibility) but I wouldn't go that far to say that it is strictly necessary to keep backwards compatibility in those classes but at least for abstract public classes I would say we unfortunately need to be backwards compatible here (so first deprecate and only finally remove in m-enforcer-p 4.0.0) Custom rules also transitively get the dependency towards `maven-dependency-tree` so we must not remove this either! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on a diff in pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
kwin commented on code in PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#discussion_r1050795396 ## enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java: ## @@ -18,22 +18,15 @@ */ Review Comment: API here just means it is exported via the class path to all custom rules and can be accessed and extended. It doesn't say anything about design Potentially that affects every rule which is not a final class (because there is no limited visibility) but I wouldn't go that far to say that it is strictly necessary to keep backwards compatibility in those classes but at least for abstract public classes I would say we unfortunately need to be backwards compatible here (so first deprecate and only finally remove in m-enforcer-p 4.0.0) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on a diff in pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
kwin commented on code in PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#discussion_r1050795396 ## enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java: ## @@ -18,22 +18,15 @@ */ Review Comment: API here just means it is exported via the class path to all custom rules and can be accessed and extended. It doesn't say anything about design Potentially that affects every rule which is not a final class (because there is no limited visibility) but I wouldn't go that far to say that it is strictly necessary to keep backwards compatibility but for abstract public classes I would say yes, we unfortunately need to be backwards compatible here (so first deprecate and only finally remove in m-enforcer-p 4.0.0) -- 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] (SUREFIRE-2134) add support for rerunFailingTestsCount option to TestNG provider
Ian Springer created SUREFIRE-2134: -- Summary: add support for rerunFailingTestsCount option to TestNG provider Key: SUREFIRE-2134 URL: https://issues.apache.org/jira/browse/SUREFIRE-2134 Project: Maven Surefire Issue Type: New Feature Components: TestNG support Affects Versions: 3.0.0-M7 Reporter: Ian Springer It would be great if the rerunFailingTestsCount option was also supported by the TestNG provider. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-enforcer] ajarmoniuk commented on a diff in pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
ajarmoniuk commented on code in PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#discussion_r1050790825 ## enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java: ## @@ -18,22 +18,15 @@ */ Review Comment: Really??? If so, I consider this a bad API. Especially because a collection of artifacts is unsuitable for a general purpose. I might as well simply move the rules out of this class. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-enforcer] kwin commented on a diff in pull request #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
kwin commented on code in PR #198: URL: https://github.com/apache/maven-enforcer/pull/198#discussion_r1050784182 ## enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java: ## @@ -18,22 +18,15 @@ */ Review Comment: I consider this file API (other rules might extend that) so it is backwards-incompatible to remove any non-private methods in there or change their signature. We may want to deprecate things though -- 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] (MENFORCER-435) Get rid of maven-dependency-tree dependency
[
https://issues.apache.org/jira/browse/MENFORCER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648639#comment-17648639
]
Andrzej Jarmoniuk commented on MENFORCER-435:
-
https://github.com/apache/maven-enforcer/pull/198
> Get rid of maven-dependency-tree dependency
> ---
>
> Key: MENFORCER-435
> URL: https://issues.apache.org/jira/browse/MENFORCER-435
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Reporter: Konrad Windszus
>Assignee: Slawomir Jaranowski
>Priority: Major
>
> As the m-enforcer-p depends on Maven 3.2.5 (since MENFORCER-419) all
> dependency resolutions should be done with Aether API directly instead of
> leveraging https://maven.apache.org/shared/maven-dependency-tree/. At the
> same time the error message should print the full path to the affected
> dependency instead of forcing users to use a dedicated call of {{mvn
> dependency:tree}} to locate the dependency
> (https://github.com/apache/maven-enforcer/blob/a06b47ba079b342d69a49d3cbad0fb546000f734/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanDependencies.java#L111)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-enforcer] ajarmoniuk opened a new pull request, #198: [MENFORCER-435] Replacing maven-compat and maven-dependency-tree usage with Resolver
ajarmoniuk opened a new pull request, #198: URL: https://github.com/apache/maven-enforcer/pull/198 See summary; also: dependency:tree is no longer necessary to check parent information of dependencies which triggered validation failures -- path information is included. @slawekjaranowski please review -- 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] (MNG-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648613#comment-17648613
]
Petr Široký edited comment on MNG-7631 at 12/16/22 12:42 PM:
-
Yeah, I do agree with your reasoning.
I am honestly not sure why I did have the empty tag in {{{}settings.xml{}}}. It
definitely is not "standard" to have empty tags like that in there.
This only caught my eye, because of the difference comparing to Maven 3.x
I did ask about this on the DEV list
https://lists.apache.org/thread/ff0m479rlb8z80nv4yk40ms4psftxnk5 and was told
to raise an issue, so I did.
was (Author: psiroky):
Yeah, I do agree with your reasoning.
I am honestly not sure why I did have the empty tag in {{{}settings.xml{}}}. It
definitely is not "standard" to have empty tags like that in there.
This only caught my eye, because of the difference comparing to Maven 3.x
I did ask about this on the DEV list
[https://lists.apache.org/thread/ff0m479rlb8z80nv4yk40ms4psftxnk5|https://lists.apache.org/thread/ff0m479rlb8z80nv4yk40ms4psftxnk5)]
and was told to raise an issue, so I did.
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - MNG-7553 New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
>
> Edit: I also tried with {{{}-f {}}}, so the local repository
> root really is {{{}{}}}, not {{}} (even if
> they are the same usually).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648613#comment-17648613
]
Petr Široký edited comment on MNG-7631 at 12/16/22 12:41 PM:
-
Yeah, I do agree with your reasoning.
I am honestly not sure why I did have the empty tag in {{{}settings.xml{}}}. It
definitely is not "standard" to have empty tags like that in there.
This only caught my eye, because of the difference comparing to Maven 3.x
I did ask about this on the DEV list
[https://lists.apache.org/thread/ff0m479rlb8z80nv4yk40ms4psftxnk5|https://lists.apache.org/thread/ff0m479rlb8z80nv4yk40ms4psftxnk5)]
and was told to raise an issue, so I did.
was (Author: psiroky):
Yeah, I do agree with your reasoning.
I am honestly not sure why I did have the empty tag in {{{}settings.xml{}}}. It
definitely is not "standard" to have empty tags like that in there.
This only caught my eye, because of the difference comparing to Maven 3.x
I did ask about this on the DEV list
([https://lists.apache.org/thread/ff0m479rlb8z80nv4yk40ms4psftxnk5)] and was
told to raise an issue, so I did.
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - MNG-7553 New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
>
> Edit: I also tried with {{{}-f {}}}, so the local repository
> root really is {{{}{}}}, not {{}} (even if
> they are the same usually).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648613#comment-17648613
]
Petr Široký commented on MNG-7631:
--
Yeah, I do agree with your reasoning.
I am honestly not sure why I did have the empty tag in {{{}settings.xml{}}}. It
definitely is not "standard" to have empty tags like that in there.
This only caught my eye, because of the difference comparing to Maven 3.x
I did ask about this on the DEV list
([https://lists.apache.org/thread/ff0m479rlb8z80nv4yk40ms4psftxnk5)] and was
told to raise an issue, so I did.
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - MNG-7553 New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
>
> Edit: I also tried with {{{}-f {}}}, so the local repository
> root really is {{{}{}}}, not {{}} (even if
> they are the same usually).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648607#comment-17648607
]
Michael Osipov commented on MNG-7631:
-
It is all about coercion.
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - MNG-7553 New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
>
> Edit: I also tried with {{{}-f {}}}, so the local repository
> root really is {{{}{}}}, not {{}} (even if
> they are the same usually).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648602#comment-17648602
]
Michael Osipov commented on MNG-7631:
-
The change is huge. I'd like to see the offending hunk. Regardless of this and
the change of behavior, my understand is that absence of the element denotes
{{null}} and use default value. Empty element means empty string ({{""}}) is a
relative target and CWD will be used. If non-empty test for relative or
absolute.
An edge case here. [~psiroky], what you the purpose of having a self closing
tag in the settings?
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - MNG-7553 New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
>
> Edit: I also tried with {{{}-f {}}}, so the local repository
> root really is {{{}{}}}, not {{}} (even if
> they are the same usually).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-jenkins-lib] olamy merged pull request #8: branchesToNofify --> branchesToNotify
olamy merged PR #8: URL: https://github.com/apache/maven-jenkins-lib/pull/8 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-pmd-plugin] dependabot[bot] closed pull request #103: [MPMD-359] - Bump maven-plugins from 37 to 38
dependabot[bot] closed pull request #103: [MPMD-359] - Bump maven-plugins from 37 to 38 URL: https://github.com/apache/maven-pmd-plugin/pull/103 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-pmd-plugin] dependabot[bot] opened a new pull request, #107: Bump maven-plugins from 37 to 39
dependabot[bot] opened a new pull request, #107: URL: https://github.com/apache/maven-pmd-plugin/pull/107 Bumps [maven-plugins](https://github.com/apache/maven-parent) from 37 to 39. Release notes Sourced from https://github.com/apache/maven-parent/releases;>maven-plugins's releases. 39 Bug [https://issues.apache.org/jira/browse/MPOM-371;>MPOM-371] - Fix checkstyle configuration [https://issues.apache.org/jira/browse/MPOM-376;>MPOM-376] - Spotless importOrder should be taken into consideration Improvement [https://issues.apache.org/jira/browse/MPOM-370;>MPOM-370] - Document format profile [https://issues.apache.org/jira/browse/MPOM-373;>MPOM-373] - Execute spotless before rat [https://issues.apache.org/jira/browse/MPOM-377;>MPOM-377] - Add space before close empty elements in poms [https://issues.apache.org/jira/browse/MPOM-384;>MPOM-384] - Allow to override streamLogsOnFailures parameter for m-invoker-p Dependency upgrade [https://issues.apache.org/jira/browse/MPOM-379;>MPOM-379] - Bump spotless-maven-plugin from 2.27.1 to 2.28.0 [https://issues.apache.org/jira/browse/MPOM-385;>MPOM-385] - Upgrade Parent to 29 38 Improvement [https://issues.apache.org/jira/browse/MPOM-340;>MPOM-340] - Remove test-javadoc reports [https://issues.apache.org/jira/browse/MPOM-353;>MPOM-353] - Use standard value for ignoreFailures at m-invoker-p [https://issues.apache.org/jira/browse/MPOM-357;>MPOM-357] - Execute checkstyle after enforcer Task [https://issues.apache.org/jira/browse/MPOM-349;>MPOM-349] - Enable spotless for autoformatting [https://issues.apache.org/jira/browse/MPOM-350;>MPOM-350] - Raise JDK requirement to 1.8 [https://issues.apache.org/jira/browse/MPOM-352;>MPOM-352] - Remove managed dependency on deprecated plexus-component-annotations Dependency upgrade [https://issues.apache.org/jira/browse/MPOM-341;>MPOM-341] - Bump extra-enforcer-rules from 1.6.0 to 1.6.1 [https://issues.apache.org/jira/browse/MPOM-343;>MPOM-343] - Upgrade Maven Checkstyle Plugin to 3.2.0 [https://issues.apache.org/jira/browse/MPOM-348;>MPOM-348] - Remove configuration for Maven Changes Plugin [https://issues.apache.org/jira/browse/MPOM-351;>MPOM-351] - Upgrade plexus-utils to 3.5.0 [https://issues.apache.org/jira/browse/MPOM-355;>MPOM-355] - Bump maven-pmd-plugin from 3.17.0 to 3.19.0 [https://issues.apache.org/jira/browse/MPOM-356;>MPOM-356] - Bump maven-jxr-plugin from 3.2.0 to 3.3.0 Commits See full diff in https://github.com/apache/maven-parent/commits;>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 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
[GitHub] [maven-pmd-plugin] dependabot[bot] commented on pull request #103: [MPMD-359] - Bump maven-plugins from 37 to 38
dependabot[bot] commented on PR #103: URL: https://github.com/apache/maven-pmd-plugin/pull/103#issuecomment-1354567797 Superseded by #107. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet merged pull request #719: Add a mvnd.rawStreams property
gnodet merged PR #719: URL: https://github.com/apache/maven-mvnd/pull/719 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet merged pull request #754: Move signal handling into its own class
gnodet merged PR #754: URL: https://github.com/apache/maven-mvnd/pull/754 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-mvnd] gnodet opened a new pull request, #754: Move signal handling into its own class
gnodet opened a new pull request, #754: URL: https://github.com/apache/maven-mvnd/pull/754 This opens some room to per-jdk implementation -- 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] (MNG-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648246#comment-17648246
]
Petr Široký edited comment on MNG-7631 at 12/16/22 9:06 AM:
*Maven 4.0.0-alpha-3*
* With {{{}mumu{}}}, the local repository
root is located in {{{}/mumu{}}}.
* With {{{}{}}}, the result is the same as
with {{}} – local repository root is directly the working dir.
*Maven 3.8.6 (for comparison)*
* With {{{}mumu{}}}, the local repository
root is located in {{{}/mumu{}}}.
* With {{{}{}}}, the result is the same as
with {{}} – local repository root is the default
{{~/.m2/repository}}
was (Author: psiroky):
*Maven 4.0.0-alpha-3*
* With {{{}mumu{}}}, the local repository
root is located in {{{}/mumu{}}}.
* With {{{}{}}}, the result is the same as
with {{}} – local repository root is directly the working dir.
*Maven 3.8.6 (for comparison)*
* With {{{}mumu{}}}, the local repository
root is located in {{{}/mumu{}}}.
* With {{{}{}}}, the result is the same as
with {{}} – local repository root is the default
{{~./.m2/repository}}
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - MNG-7553 New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
>
> Edit: I also tried with {{{}-f {}}}, so the local repository
> root really is {{{}{}}}, not {{}} (even if
> they are the same usually).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648246#comment-17648246
]
Petr Široký edited comment on MNG-7631 at 12/16/22 9:06 AM:
*Maven 4.0.0-alpha-3*
* With {{{}mumu{}}}, the local repository
root is located in {{{}/mumu{}}}.
* With {{{}{}}}, the result is the same as
with {{}} – local repository root is directly the working dir.
*Maven 3.8.6 (for comparison)*
* With {{{}mumu{}}}, the local repository
root is located in {{{}/mumu{}}}.
* With {{{}{}}}, the result is the same as
with {{}} – local repository root is the default
{{~./.m2/repository}}
was (Author: psiroky):
With {{mumu}}, the local repository root is
located in {{/mumu}}.
With {{}}, the result is the same as with
{{}} -- local repository root is directly the working dir.
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - MNG-7553 New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
>
> Edit: I also tried with {{{}-f {}}}, so the local repository
> root really is {{{}{}}}, not {{}} (even if
> they are the same usually).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (MNG-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Petr Široký updated MNG-7631:
-
Description:
I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and I
am seeing one difference / inconsistency with the behavior of empty
{{}} tag in {{settings.xml}} file, when comparing to Maven
3.8.6.
My {{settings.xml}} file looks like this:
{code:xml}
http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;>
{code}
When I run a build with Maven 3.8.6, everything works as I would expect and by
default the {{~/.m2/repository}} is chosen.
However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
working directory_ as the root directory for the local repository. So I end-up
with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}}, etc., next
to the {{{}pom.xml{}}}.
If I remove the empty element {{}} from the
{{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the same
as in Maven 3.x.
I was doing some quick testing and git bisecting and assuming I did not mess
anything up, the commit causing this behavior is
[https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
- MNG-7553 New clean API with immutable model
([#703|https://github.com/apache/maven/pull/703])
(and it's huge, so I haven't yet looked in detail at the changes).
I am not 100% sure this is a bug, but it is at least a difference in behavior
comparing to Maven 3.x.
Edit: I also tried with {{{}-f {}}}, so the local repository
root really is {{{}{}}}, not {{}} (even if
they are the same usually).
was:
I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and I
am seeing one difference / inconsistency with the behavior of empty
{{}} tag in {{settings.xml}} file, when comparing to Maven
3.8.6.
My {{settings.xml}} file looks like this:
{code:xml}
http://maven.apache.org/SETTINGS/1.0.0;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
http://maven.apache.org/xsd/settings-1.0.0.xsd;>
{code}
When I run a build with Maven 3.8.6, everything works as I would expect and by
default the {{~/.m2/repository}} is chosen.
However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
working directory_ as the root directory for the local repository. So I end-up
with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}}, etc., next
to the {{{}pom.xml{}}}.
If I remove the empty element {{}} from the
{{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the same
as in Maven 3.x.
I was doing some quick testing and git bisecting and assuming I did not mess
anything up, the commit causing this behavior is
[https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
- [MNG-7553] New clean API with immutable model
([#703|https://github.com/apache/maven/pull/703])
(and it's huge, so I haven't yet looked in detail at the changes).
I am not 100% sure this is a bug, but it is at least a difference in behavior
comparing to Maven 3.x.
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty
[jira] [Commented] (MNG-7631) Current working directory is used as local repository (instead of ~/.m2/repository) when settings.xml contains empty element
[
https://issues.apache.org/jira/browse/MNG-7631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17648418#comment-17648418
]
Petr Široký commented on MNG-7631:
--
Ah, sorry, forgot to mention it in the original description. I did try with
{{-f }}, so it really is {{}}, not
{{}}.
> Current working directory is used as local repository (instead of
> ~/.m2/repository) when settings.xml contains empty element
> ---
>
> Key: MNG-7631
> URL: https://issues.apache.org/jira/browse/MNG-7631
> Project: Maven
> Issue Type: Bug
> Components: Settings
>Affects Versions: 4.0.0-alpha-2, 4.0.0-alpha-3
> Environment: Linux x86_64 (Fedora 36)
>Reporter: Petr Široký
>Priority: Minor
>
> I have tried to build a sample project locally using Maven 4.0.0-alpha-3 and
> I am seeing one difference / inconsistency with the behavior of empty
> {{}} tag in {{settings.xml}} file, when comparing to Maven
> 3.8.6.
> My {{settings.xml}} file looks like this:
> {code:xml}
> http://maven.apache.org/SETTINGS/1.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
> http://maven.apache.org/xsd/settings-1.0.0.xsd;>
>
>
> {code}
> When I run a build with Maven 3.8.6, everything works as I would expect and
> by default the {{~/.m2/repository}} is chosen.
> However, if I build with Maven {{{}4.0.0-alpha-3{}}}, it chooses the _current
> working directory_ as the root directory for the local repository. So I
> end-up with directories like {{{}aopalliance{}}}, {{{}avalon-framework{}}},
> etc., next to the {{{}pom.xml{}}}.
> If I remove the empty element {{}} from the
> {{{}settings.xml{}}}, then {{~/.m2/repository}} is chosen and it works the
> same as in Maven 3.x.
> I was doing some quick testing and git bisecting and assuming I did not mess
> anything up, the commit causing this behavior is
> [https://github.com/apache/maven/commit/2a9f39336cec1d8e52d30cc48503d51ed8672536]
> - [MNG-7553] New clean API with immutable model
> ([#703|https://github.com/apache/maven/pull/703])
> (and it's huge, so I haven't yet looked in detail at the changes).
> I am not 100% sure this is a bug, but it is at least a difference in behavior
> comparing to Maven 3.x.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
