[jira] [Commented] (SUREFIRE-1909) Support JUnit 5 reflection access by changing add-exports to add-opens
[
https://issues.apache.org/jira/browse/SUREFIRE-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385980#comment-17385980
]
Tibor Digana commented on SUREFIRE-1909:
I would like to see your "add-opens" with the remaining part, but the most
important is the question why you used module-info.java in src/main/java and
you did not write a new module-info.java in src/test/java. Pls read our
documentation which describes everything you need
https://maven.apache.org/surefire/maven-surefire-plugin/examples/jpms.html
> Support JUnit 5 reflection access by changing add-exports to add-opens
> --
>
> Key: SUREFIRE-1909
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1909
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Christian Kohlschütter
>Priority: Major
> Attachments: surefire-jpms-bug.tar.gz
>
>
> Testing JUnit 5 classes of a JPMS-enabled project with Surefire may fail if a
> test class (or, for example, an abstract test base class) is not declared
> "public". I'm seeing the following error:
>
> {code:java}
> java.lang.reflect.InaccessibleObjectException: Unable to make public static
> void some.package.SomeClass.setupClass() throws java.io.IOException
> accessible: module some.module does not "opens some.package" to unnamed
> module @754ba872{code}
> This could be fixed by adding the recommended "{{opens some.package}}" to the
> project's module-info.java, however that is undesirable since it changes the
> project's behavior beyond just unit testing. Adding a secondary "test-only"
> module-info.java is also counterproductive since not all IDEs support this,
> and these two files would have to be kept in sync, which is non-trivial.
> An easy fix would be to change the "{{--add-exports-}}" VM parameter that
> surefire adds automatically to "{{-}}{{add-opens}}" in
> {{maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ModularClasspathForkConfiguration.java}}
> This bug is particularly bad because PMD now specifically complains about
> junit5 classes marked as public instead of package-private; see
> [https://pmd.github.io/2021/05/29/PMD-6.35.0/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1909) Support JUnit 5 reflection access by changing add-exports to add-opens
[
https://issues.apache.org/jira/browse/SUREFIRE-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17327229#comment-17327229
]
Tibor Digana edited comment on SUREFIRE-1909 at 7/23/21, 5:57 AM:
--
[~c...@newsclub.de]
Pls show us how the CLI would look like if you want to help us. Check it out
with debug logs {{mvn -X test}} and you will see JMPS options we use in the
@file of the CLI.
was (Author: tibor17):
[~c...@newsclub.de]
{{ModularClasspathForkConfiguration.java}} is in the module
{{maven-surefire-common}} and therefore it has nothing to do with the forked
JVM.
You have to show us how the CLI would look like if you want to help us. Check
it out with debug logs {{mvn -X test}} and you will see JMPS options we use in
the @file of the CLI.
> Support JUnit 5 reflection access by changing add-exports to add-opens
> --
>
> Key: SUREFIRE-1909
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1909
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Christian Kohlschütter
>Priority: Major
> Attachments: surefire-jpms-bug.tar.gz
>
>
> Testing JUnit 5 classes of a JPMS-enabled project with Surefire may fail if a
> test class (or, for example, an abstract test base class) is not declared
> "public". I'm seeing the following error:
>
> {code:java}
> java.lang.reflect.InaccessibleObjectException: Unable to make public static
> void some.package.SomeClass.setupClass() throws java.io.IOException
> accessible: module some.module does not "opens some.package" to unnamed
> module @754ba872{code}
> This could be fixed by adding the recommended "{{opens some.package}}" to the
> project's module-info.java, however that is undesirable since it changes the
> project's behavior beyond just unit testing. Adding a secondary "test-only"
> module-info.java is also counterproductive since not all IDEs support this,
> and these two files would have to be kept in sync, which is non-trivial.
> An easy fix would be to change the "{{--add-exports-}}" VM parameter that
> surefire adds automatically to "{{-}}{{add-opens}}" in
> {{maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ModularClasspathForkConfiguration.java}}
> This bug is particularly bad because PMD now specifically complains about
> junit5 classes marked as public instead of package-private; see
> [https://pmd.github.io/2021/05/29/PMD-6.35.0/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1909) Support JUnit 5 reflection access by changing add-exports to add-opens
[
https://issues.apache.org/jira/browse/SUREFIRE-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385840#comment-17385840
]
Christian Kohlschütter commented on SUREFIRE-1909:
--
[~tibordigana] ping
> Support JUnit 5 reflection access by changing add-exports to add-opens
> --
>
> Key: SUREFIRE-1909
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1909
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
>Affects Versions: 3.0.0-M5
>Reporter: Christian Kohlschütter
>Priority: Major
> Attachments: surefire-jpms-bug.tar.gz
>
>
> Testing JUnit 5 classes of a JPMS-enabled project with Surefire may fail if a
> test class (or, for example, an abstract test base class) is not declared
> "public". I'm seeing the following error:
>
> {code:java}
> java.lang.reflect.InaccessibleObjectException: Unable to make public static
> void some.package.SomeClass.setupClass() throws java.io.IOException
> accessible: module some.module does not "opens some.package" to unnamed
> module @754ba872{code}
> This could be fixed by adding the recommended "{{opens some.package}}" to the
> project's module-info.java, however that is undesirable since it changes the
> project's behavior beyond just unit testing. Adding a secondary "test-only"
> module-info.java is also counterproductive since not all IDEs support this,
> and these two files would have to be kept in sync, which is non-trivial.
> An easy fix would be to change the "{{--add-exports-}}" VM parameter that
> surefire adds automatically to "{{-}}{{add-opens}}" in
> {{maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ModularClasspathForkConfiguration.java}}
> This bug is particularly bad because PMD now specifically complains about
> junit5 classes marked as public instead of package-private; see
> [https://pmd.github.io/2021/05/29/PMD-6.35.0/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MENFORCER-298) bannedDependencies can break compilation against a timestamped snapshot
[
https://issues.apache.org/jira/browse/MENFORCER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385837#comment-17385837
]
Jesse Glick commented on MENFORCER-298:
---
I managed to work around that by patching
https://github.com/jenkinsci/pom/commit/f07a17276ba3d943a2b2550b22231b0163d6a9d1
with
{code:xml}
diff --git pom.xml pom.xml
index 56911f6..0afd265 100644
--- pom.xml
+++ pom.xml
@@ -611,36 +611,6 @@
[1.${java.level}.0,]
-
-
- 1.${java.level}
-
-test
-
-
-
-com.google.code.findbugs:annotations
-
-
-
No Snapshots Allowed For Release Versions
true
{code}
({{requireUpperBoundDeps}} also failed here, for a different reason) and then
using the patched parent
{code:xml}
diff --git pom.xml pom.xml
index cbbdc1e0df..68b6889ce1 100644
--- pom.xml
+++ pom.xml
@@ -28,7 +28,7 @@ THE SOFTWARE.
org.jenkins-ci
jenkins
-1.39
+1.39-SNAPSHOT
org.jenkins-ci.main
{code}
With that, the build succeeds, and switching back to {{3.0.0-M1}} for Enforcer
causes it to get a compilation error again, all suggesting that MENFORCER-277
indeed worked.
> bannedDependencies can break compilation against a timestamped snapshot
> ---
>
> Key: MENFORCER-298
> URL: https://issues.apache.org/jira/browse/MENFORCER-298
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M1, 3.0.0-M3
>Reporter: Jesse Glick
>Assignee: Robert Scholte
>Priority: Major
>
> While working heavily with timestamped snapshots across repositories
> (reactors) I found occasional build errors suggesting that
> {{maven-compiler-plugin}} was picking up the wrong version of a dependency.
> To reproduce, using say Maven 3.5.2:
> {code:none}
> git clone https://github.com/jenkinsci/jenkins
> cd jenkins
> git checkout e2c1ae15a3bc6a9e1dcde0bc139b34d2c5812214
> mvn -DskipTests -am -pl core clean install
> {code}
> Compilation will fail with some errors like
> {code:none}
> [ERROR]
> .../jenkins/core/src/main/java/jenkins/security/ClassFilterImpl.java:[77,19]
> error: cannot find symbol
> [ERROR] symbol: method setDefault(ClassFilterImpl)
> [ERROR] location: class ClassFilter
> {code}
> What is going on here is that [the artifact
> repository|http://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15-SNAPSHOT/]
> contains various timestamped snapshots for this base version of
> {{remoting}}. The {{jenkins}} commit requests the {{-3}} snapshot in its
> {{pom.xml}}; the newest currently available is {{-10}}, which represents an
> unrelated branch. The compiler error happens when
> {{jenkins/core/src/main/java/}} is compiled against the {{-10}} artifact.
> Now {{MavenITmng4189UniqueVersionSnapshotTest}} in
> {{maven-integration-testing}} verifies that the compiler classpath in such
> cases is correct, and in fact you can patch the IT to actually run the
> compiler and it will work as expected: Maven will copy the requested
> timestamped snapshot artifacts to the corresponding base versions, then
> return those from {{MavenProject.getCompileClasspathElements}}, as [this
> blog|http://blog.sonatype.com/2009/12/maven-dependency-resolution-a-repository-perspective/]
> says it will (without further explanation). Yet it breaks in {{jenkins}}.
> I managed to narrow this down to the fact that {{jenkins}} used the
> {{bannedDependencies}} Enforcer rule. If it uses only, say,
> {{}}, then there is no error. But running {{bannedDependencies}}
> changes the behavior of compilation (even though the {{enforce}} mojo
> passes): the {{-10}} artifacts ({{pom}} and {{jar}}) are downloaded, and the
> base artifacts (esp. {{remoting-3.15-SNAPSHOT.jar}}) are overwritten with the
> {{-10}} versions, not the {{-3}} versions as expected. By patching
> {{BannedDependencies}} I found that this problem occurs iff
> {{buildDependencyGraph}} is called. By adding
> {code}
> System.setSecurityManager( new SecurityManager()
> {
> @Override
> public void checkWrite( String file )
> {
> if ( file.contains( "remoting" ) )
> {
> System.err.println( file );
> Thread.dumpStack();
> }
> }
> @Override
> public void checkPermission( Permission perm )
> {
> }
> }
> );
> {code}
> I found this stack trace:
> {code:none}
> at java.io.FileOutputStream.(FileOutputStream.java:200)
> at java.io.FileOutputStream.(FileOutputStream.java:162)
> at
[jira] [Commented] (MENFORCER-298) bannedDependencies can break compilation against a timestamped snapshot
[
https://issues.apache.org/jira/browse/MENFORCER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385831#comment-17385831
]
Jesse Glick commented on MENFORCER-298:
---
My original test case still reproduces the bug in Maven 3.8.1 given
{code:xml}
diff --git pom.xml pom.xml
index cbbdc1e0df..f92cdfe724 100644
--- pom.xml
+++ pom.xml
@@ -112,7 +112,7 @@ THE SOFTWARE.
repo.jenkins-ci.org
- http://repo.jenkins-ci.org/public/
+ https://repo.jenkins-ci.org/public/
@@ -120,7 +120,7 @@ THE SOFTWARE.
repo.jenkins-ci.org
- http://repo.jenkins-ci.org/public/
+ https://repo.jenkins-ci.org/public/
{code}
I {{install}}’d a snapshot from
https://github.com/apache/maven-enforcer/commit/ab53fd99607eb36554f2fd3af41847ad9568a5ed
and tried
{code:xml}
@@ -575,6 +575,7 @@ THE SOFTWARE.
org.apache.maven.plugins
maven-enforcer-plugin
+3.0.0-M4-SNAPSHOT
{code}
but this failed with
{code:none}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M4-SNAPSHOT:enforce
(display-info) on project pom: Unable to parse configuration of mojo
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M4-SNAPSHOT:enforce for
parameter enforceBytecodeVersion: Cannot create instance of class
org.apache.maven.plugins.enforcer.EnforceBytecodeVersion:
org/apache/maven/shared/dependency/tree/DependencyTreeBuilderException:
org.apache.maven.shared.dependency.tree.DependencyTreeBuilderException -> [Help
1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M4-SNAPSHOT:enforce
(display-info) on project pom: Unable to parse configuration of mojo
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M4-SNAPSHOT:enforce for
parameter enforceBytecodeVersion: Cannot create instance of class
org.apache.maven.plugins.enforcer.EnforceBytecodeVersion
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
at …
Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to
parse configuration of mojo
org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M4-SNAPSHOT:enforce for
parameter enforceBytecodeVersion: Cannot create instance of class
org.apache.maven.plugins.enforcer.EnforceBytecodeVersion
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields
(DefaultMavenPluginManager.java:665)
at …
Caused by:
org.codehaus.plexus.component.configurator.ComponentConfigurationException:
Cannot create instance of class
org.apache.maven.plugins.enforcer.EnforceBytecodeVersion
at
org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject
(AbstractConfigurationConverter.java:151)
at …
Caused by: java.lang.NoClassDefFoundError:
org/apache/maven/shared/dependency/tree/DependencyTreeBuilderException
at …
at java.lang.Class.newInstance (Class.java:412)
at
org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject
(AbstractConfigurationConverter.java:143)
at …
Caused by: java.lang.ClassNotFoundException:
org.apache.maven.shared.dependency.tree.DependencyTreeBuilderException
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass
(SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass
(ClassRealm.java:271)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass
(ClassRealm.java:247)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass
(ClassRealm.java:239)
at java.lang.Class.getDeclaredConstructors0 (Native Method)
at …
{code}
> bannedDependencies can break compilation against a timestamped snapshot
> ---
>
> Key: MENFORCER-298
> URL: https://issues.apache.org/jira/browse/MENFORCER-298
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M1, 3.0.0-M3
>Reporter: Jesse Glick
>Assignee: Robert Scholte
>Priority: Major
>
> While working heavily with timestamped snapshots across repositories
> (reactors) I found occasional build errors suggesting that
> {{maven-compiler-plugin}} was picking up the wrong version of a dependency.
> To reproduce, using say Maven 3.5.2:
> {code:none}
> git clone https://github.com/jenkinsci/jenkins
> cd jenkins
> git checkout e2c1ae15a3bc6a9e1dcde0bc139b34d2c5812214
> mvn -DskipTests -am -pl core clean install
> {code}
> Compilation will fail with some errors like
> {code:none}
> [ERROR]
> .../jenkins/core/src/main/java/jenkins/security/ClassFilterImpl.java:[77,19]
[jira] [Updated] (MNG-7050) Create M2_REPOSITORY env variable for Local Repository and Wrapper locations
[
https://issues.apache.org/jira/browse/MNG-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7050:
Fix Version/s: waiting-for-feedback
> Create M2_REPOSITORY env variable for Local Repository and Wrapper locations
>
>
> Key: MNG-7050
> URL: https://issues.apache.org/jira/browse/MNG-7050
> Project: Maven
> Issue Type: Improvement
> Components: core, maven wrapper, Settings
>Affects Versions: 3.6.3
>Reporter: Manuel Jordan
>Priority: Minor
> Labels: features
> Fix For: waiting-for-feedback
>
>
> I need do mention about Gradle to understand and find the same solution or
> approach for Maven.
> In Gradle exists the {{GRADLE_HOME}} and {{GRADLE_USER_HOME}} (repository)
> _environment variables_, for Maven the former through {{M2_HOME}} and about
> the _repository_ I use the {{settings.xml}} file to define the
> {{}} location
> For both Maven and Gradle I can define in peace the place about where is
> installed the software, for example other location than {{.m2}} and
> {{.gradle}} to a secondary disk and even with customized directory names.
> Same goal about the repository location, both for a secondary disk (remember
> for Maven through the {{settings.xml}} file)
> *Note*: therefore {{.gradle}} and {{.m2}} are empty and not used.
> In Gradle about the wrapper created, the {{gradle-wrapper.properties}} file
> has:
>
> {code:java}
> distributionBase=GRADLE_USER_HOME
> distributionPath=wrapper/dists
> distributionUrl=https\://services.gradle.org/distributions/gradle-#.#.#-bin.zip
> zipStoreBase=GRADLE_USER_HOME
> zipStorePath=wrapper/dists
> {code}
> Then the final path is: {{GRADLE_USER_HOME/wrapper/dists}}
> Therefore observe how {{GRADLE_USER_HOME}} (custom location - otherwise
> {{.gradle}} by default) is used to define the:
> * Local repository
> * Base path to install the downloaded Gradle through the wrapper
> *New Improvement*: Add for Maven an environment variable named M2_REPOSITORY
> for the _Local Repository_ and _Wrapper Installation_ locations that Maven
> should recognize automatically (*not* using the {{settings.xml}} file).
> It with the purpose to have any Maven wrapper(s) installed according to that
> _environment variable_ value (custom location - otherwise {{.m2}} by default)
> and of course applied for the Local Repository location too.
> *Observation*: If the {{settings.xml}} file exists it should override the
> M2_REPOSITORY value.
> *Therefore*: I need the {{maven-wrapper.properties}} using something like
> {{M2_REPOSITORY}} (custom location - otherwise {{.m2}} by default) according
> the developer/user in its machine.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7050) Create M2_REPOSITORY env variable for Local Repository and Wrapper locations
[
https://issues.apache.org/jira/browse/MNG-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385776#comment-17385776
]
Michael Osipov commented on MNG-7050:
-
Can this be solved with MNG-7193?
> Create M2_REPOSITORY env variable for Local Repository and Wrapper locations
>
>
> Key: MNG-7050
> URL: https://issues.apache.org/jira/browse/MNG-7050
> Project: Maven
> Issue Type: Improvement
> Components: core, maven wrapper, Settings
>Affects Versions: 3.6.3
>Reporter: Manuel Jordan
>Priority: Minor
> Labels: features
>
> I need do mention about Gradle to understand and find the same solution or
> approach for Maven.
> In Gradle exists the {{GRADLE_HOME}} and {{GRADLE_USER_HOME}} (repository)
> _environment variables_, for Maven the former through {{M2_HOME}} and about
> the _repository_ I use the {{settings.xml}} file to define the
> {{}} location
> For both Maven and Gradle I can define in peace the place about where is
> installed the software, for example other location than {{.m2}} and
> {{.gradle}} to a secondary disk and even with customized directory names.
> Same goal about the repository location, both for a secondary disk (remember
> for Maven through the {{settings.xml}} file)
> *Note*: therefore {{.gradle}} and {{.m2}} are empty and not used.
> In Gradle about the wrapper created, the {{gradle-wrapper.properties}} file
> has:
>
> {code:java}
> distributionBase=GRADLE_USER_HOME
> distributionPath=wrapper/dists
> distributionUrl=https\://services.gradle.org/distributions/gradle-#.#.#-bin.zip
> zipStoreBase=GRADLE_USER_HOME
> zipStorePath=wrapper/dists
> {code}
> Then the final path is: {{GRADLE_USER_HOME/wrapper/dists}}
> Therefore observe how {{GRADLE_USER_HOME}} (custom location - otherwise
> {{.gradle}} by default) is used to define the:
> * Local repository
> * Base path to install the downloaded Gradle through the wrapper
> *New Improvement*: Add for Maven an environment variable named M2_REPOSITORY
> for the _Local Repository_ and _Wrapper Installation_ locations that Maven
> should recognize automatically (*not* using the {{settings.xml}} file).
> It with the purpose to have any Maven wrapper(s) installed according to that
> _environment variable_ value (custom location - otherwise {{.m2}} by default)
> and of course applied for the Local Repository location too.
> *Observation*: If the {{settings.xml}} file exists it should override the
> M2_REPOSITORY value.
> *Therefore*: I need the {{maven-wrapper.properties}} using something like
> {{M2_REPOSITORY}} (custom location - otherwise {{.m2}} by default) according
> the developer/user in its machine.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6303) .mvn/jvm.config and .mvn/maven.config should allow to resolve environment variables
[
https://issues.apache.org/jira/browse/MNG-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6303:
Fix Version/s: (was: waiting-for-feedback)
> .mvn/jvm.config and .mvn/maven.config should allow to resolve environment
> variables
> ---
>
> Key: MNG-6303
> URL: https://issues.apache.org/jira/browse/MNG-6303
> Project: Maven
> Issue Type: New Feature
> Components: Bootstrap & Build
>Affects Versions: 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> With the mechanism of having project-specific maven options being specified
> in {{.mvn/maven.config}} and {{.mvn/jvm.config}} (MNG-6267) it is often handy
> to share those settings among multiple developers (i.e. via maintaining it
> via the SCM). Unfortunately the mechanism does not support resolving
> environment variables, which makes it hard to deal with user-specific
> directories or settings. Please support resolving environment variables
> through a special pattern like {{$ENV_NAME}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6606) Allow installation-wide parameter customization
[
https://issues.apache.org/jira/browse/MNG-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385775#comment-17385775
]
Michael Osipov commented on MNG-6606:
-
Can this be solved with MNG-7193?
> Allow installation-wide parameter customization
> ---
>
> Key: MNG-6606
> URL: https://issues.apache.org/jira/browse/MNG-6606
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.1.1
>Reporter: Paul Benedict
>Priority: Major
>
> In my use case, I would like to always print the version of Maven at every
> execution. I am not interested in a per-project case basis; nor interested in
> modifying the startup batch scripts. I want to drop in a standard
> configuration file to control all my Maven installations in the same manner.
> My request is to make {{/.mvn/maven.config}} and {{./mvn/}}{{mavenrc}} to
> also be recognized in the Maven installation root. I am not explicitly asking
> for {{${maven.root}/.mvn}} to be *the* solution, but it's the right place to
> start the problem solving.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6606) Allow installation-wide parameter customization
[
https://issues.apache.org/jira/browse/MNG-6606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6606:
Fix Version/s: waiting-for-feedback
> Allow installation-wide parameter customization
> ---
>
> Key: MNG-6606
> URL: https://issues.apache.org/jira/browse/MNG-6606
> Project: Maven
> Issue Type: Improvement
> Components: core
>Affects Versions: 3.1.1
>Reporter: Paul Benedict
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> In my use case, I would like to always print the version of Maven at every
> execution. I am not interested in a per-project case basis; nor interested in
> modifying the startup batch scripts. I want to drop in a standard
> configuration file to control all my Maven installations in the same manner.
> My request is to make {{/.mvn/maven.config}} and {{./mvn/}}{{mavenrc}} to
> also be recognized in the Maven installation root. I am not explicitly asking
> for {{${maven.root}/.mvn}} to be *the* solution, but it's the right place to
> start the problem solving.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7010) omit "NB: JAVA_HOME should point to a JDK not a JRE" except when that is the problem.
[
https://issues.apache.org/jira/browse/MNG-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385771#comment-17385771
]
Michael Osipov commented on MNG-7010:
-
Makes sense..
Do you agree with the testing for {{javac}}?
> omit "NB: JAVA_HOME should point to a JDK not a JRE" except when that is the
> problem.
> -
>
> Key: MNG-7010
> URL: https://issues.apache.org/jira/browse/MNG-7010
> Project: Maven
> Issue Type: Improvement
>Reporter: Elliotte Rusty Harold
>Priority: Minor
>
> Got this message a bunch today:
>
> $ mvn verify
> The JAVA_HOME environment variable is not defined correctly
> This environment variable is needed to run this program
> NB: JAVA_HOME should point to a JDK not a JRE
>
> fair enough. My JAVA_HOME is broken, for reasons. However the problem is
> **not** that it points to a JDK instead of a JRE. Maven should omit "NB:
> JAVA_HOME should point to a JDK not a JRE" except when that is the problem.
> Also, I have no idea what NB means here. Nota bene perhaps?
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-5859) Apply filter to .mvn/maven.config
[
https://issues.apache.org/jira/browse/MNG-5859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5859.
---
Resolution: Duplicate
> Apply filter to .mvn/maven.config
> -
>
> Key: MNG-5859
> URL: https://issues.apache.org/jira/browse/MNG-5859
> Project: Maven
> Issue Type: New Feature
>Reporter: Dave Syer
>Priority: Major
>
> Any command line argument that requires a file location (like "-s") is
> awkward or impossible to use in maven.config because the file location would
> have to be absolute in order to support building from a child module (which
> makes it impossible to check it into source control). Interpolation of things
> like {{$MAVEN_PROJECTBASEDIR}} would be helpful.
> See https://issues.apache.org/jira/browse/MNG-5790 for original request.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-5930) .mvn/maven.config does not expand environmental variables
[ https://issues.apache.org/jira/browse/MNG-5930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-5930. --- Resolution: Duplicate > .mvn/maven.config does not expand environmental variables > - > > Key: MNG-5930 > URL: https://issues.apache.org/jira/browse/MNG-5930 > Project: Maven > Issue Type: New Feature >Affects Versions: 3.3.3 > Environment: Linux mint 17.2 > java version "1.8.0_66" > Java(TM) SE Runtime Environment (build 1.8.0_66-b17) > Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode) >Reporter: William Buss >Priority: Minor > > environmental variables used in .mvn/maven.config are not expanded out. > running > mvn clean install -Dmaven.repo.local=$HOME/.m2/otherRepo > correctly creates and uses the local repo in /home/user/.m2/otherRepo > if the argument -Dmaven.repo.local=$HOME/.m2/otherRepo, is placed in the > .mvn/maven.config file, then the local repo used is > current working directory/$HOME/.m2/otherRepo -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-6303) .mvn/jvm.config and .mvn/maven.config should allow to resolve environment variables
[
https://issues.apache.org/jira/browse/MNG-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6303:
Issue Type: New Feature (was: Bug)
> .mvn/jvm.config and .mvn/maven.config should allow to resolve environment
> variables
> ---
>
> Key: MNG-6303
> URL: https://issues.apache.org/jira/browse/MNG-6303
> Project: Maven
> Issue Type: New Feature
> Components: Bootstrap & Build
>Affects Versions: 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> With the mechanism of having project-specific maven options being specified
> in {{.mvn/maven.config}} and {{.mvn/jvm.config}} (MNG-6267) it is often handy
> to share those settings among multiple developers (i.e. via maintaining it
> via the SCM). Unfortunately the mechanism does not support resolving
> environment variables, which makes it hard to deal with user-specific
> directories or settings. Please support resolving environment variables
> through a special pattern like {{$ENV_NAME}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6303) .mvn/jvm.config and .mvn/maven.config should allow to resolve environment variables
[
https://issues.apache.org/jira/browse/MNG-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6303:
Summary: .mvn/jvm.config and .mvn/maven.config should allow to resolve
environment variables (was: .mvn/jvm.config should allow to resolve
environment variables)
> .mvn/jvm.config and .mvn/maven.config should allow to resolve environment
> variables
> ---
>
> Key: MNG-6303
> URL: https://issues.apache.org/jira/browse/MNG-6303
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap & Build
>Affects Versions: 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> With the mechanism of having project-specific maven options being specified
> in {{.mvn/maven.config}} and {{.mvn/jvm.config}} (MNG-6267) it is often handy
> to share those settings among multiple developers (i.e. via maintaining it
> via the SCM). Unfortunately the mechanism does not support resolving
> environment variables, which makes it hard to deal with user-specific
> directories or settings. Please support resolving environment variables
> through a special pattern like {{$ENV_NAME}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7010) omit "NB: JAVA_HOME should point to a JDK not a JRE" except when that is the problem.
[ https://issues.apache.org/jira/browse/MNG-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385769#comment-17385769 ] Elliotte Rusty Harold commented on MNG-7010: Yes, that makes sense. Speciifcally: 1. Warn "The JAVA_HOME environment variable is not defined correctly This environment variable is needed to run this program." when the JAVA_HOME environment variable is not defined correctly. 2. Drop "NB" completely. It's very obscure. 3. If and only if the problem is that JAVA_HOME should points to a JRE instead of a JDK, then also add, "JAVA_HOME should point to a JDK, not a JRE." > omit "NB: JAVA_HOME should point to a JDK not a JRE" except when that is the > problem. > - > > Key: MNG-7010 > URL: https://issues.apache.org/jira/browse/MNG-7010 > Project: Maven > Issue Type: Improvement >Reporter: Elliotte Rusty Harold >Priority: Minor > > Got this message a bunch today: > > $ mvn verify > The JAVA_HOME environment variable is not defined correctly > This environment variable is needed to run this program > NB: JAVA_HOME should point to a JDK not a JRE > > fair enough. My JAVA_HOME is broken, for reasons. However the problem is > **not** that it points to a JDK instead of a JRE. Maven should omit "NB: > JAVA_HOME should point to a JDK not a JRE" except when that is the problem. > Also, I have no idea what NB means here. Nota bene perhaps? > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7010) omit "NB: JAVA_HOME should point to a JDK not a JRE" except when that is the problem.
[
https://issues.apache.org/jira/browse/MNG-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385765#comment-17385765
]
Michael Osipov commented on MNG-7010:
-
Wen can test whether {{JAVA_HOME}} contains {{javac}} and then issue a warning.
WDYT?
> omit "NB: JAVA_HOME should point to a JDK not a JRE" except when that is the
> problem.
> -
>
> Key: MNG-7010
> URL: https://issues.apache.org/jira/browse/MNG-7010
> Project: Maven
> Issue Type: Improvement
>Reporter: Elliotte Rusty Harold
>Priority: Minor
>
> Got this message a bunch today:
>
> $ mvn verify
> The JAVA_HOME environment variable is not defined correctly
> This environment variable is needed to run this program
> NB: JAVA_HOME should point to a JDK not a JRE
>
> fair enough. My JAVA_HOME is broken, for reasons. However the problem is
> **not** that it points to a JDK instead of a JRE. Maven should omit "NB:
> JAVA_HOME should point to a JDK not a JRE" except when that is the problem.
> Also, I have no idea what NB means here. Nota bene perhaps?
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7130) Integration with Jansi and windows console create JVM fork errors with lots of output during tests
[
https://issues.apache.org/jira/browse/MNG-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385763#comment-17385763
]
Michael Osipov commented on MNG-7130:
-
Can you retry with Maven master or 3.8.x?
> Integration with Jansi and windows console create JVM fork errors with lots
> of output during tests
> --
>
> Key: MNG-7130
> URL: https://issues.apache.org/jira/browse/MNG-7130
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: Philippe Deslauriers
>Priority: Minor
>
> see my answer to this thread
> [https://stackoverflow.com/a/66801171/1634131]
>
> Build with lots of console ouput (15Mb+ in my case) in surefire / failsafe
> tests fails with this error :
>
> {{The forked VM terminated without saying properly goodbye. VM crash or
> System.exit called}}
>
> This happens even with -B (batch) option.
>
> On a given project this would *fails systematically* in a new windows console
> (cmd.exe)
> {quote}[path_to_jdk]\java.exe -Dmaven.home=[path_to_maven]\apache-maven-3.6.3
> -Dclassworlds.conf=[path_to_maven]\bin..\bin\m2.conf
> -Dmaven.multiModuleProjectDirectory=[path_to_myproject] -Dfile.encoding=UTF-8
> -classpath [path_to_maven]\boot\plexus-classworlds-2.6.0.jar
> org.codehaus.plexus.classworlds.launcher.Launcher clean install -B
> {quote}
> This will *always works* in a new console window (cmd.exe).
> {quote}[path_to_jdk]\java.exe -Dmaven.home=[path_to_maven]\apache-maven-3.6.3
> -Dclassworlds.conf=[path_to_maven]\bin..\bin\m2.conf
> -Dmaven.multiModuleProjectDirectory=[path_to_myproject] -Dfile.encoding=UTF-8
> -Djansi.force=true -Djansi.passthrough=true -classpath
> [path_to_maven]\boot\plexus-classworlds-2.6.0.jar
> org.codehaus.plexus.classworlds.launcher.Launcher clean install -B
> {quote}
> Notice that both command have -B (batch mode which should turn off coloring),
> and the only difference is
>
> {{-Djansi.force=true -Djansi.passthrough=true}}
>
> {{maven-surefire-plugin/useSystemClassLoader does not have an impact on test
> results}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-7130) Integration with Jansi and windows console create JVM fork errors with lots of output during tests
[
https://issues.apache.org/jira/browse/MNG-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7130:
Fix Version/s: waiting-for-feedback
> Integration with Jansi and windows console create JVM fork errors with lots
> of output during tests
> --
>
> Key: MNG-7130
> URL: https://issues.apache.org/jira/browse/MNG-7130
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.6.3
>Reporter: Philippe Deslauriers
>Priority: Minor
> Fix For: waiting-for-feedback
>
>
> see my answer to this thread
> [https://stackoverflow.com/a/66801171/1634131]
>
> Build with lots of console ouput (15Mb+ in my case) in surefire / failsafe
> tests fails with this error :
>
> {{The forked VM terminated without saying properly goodbye. VM crash or
> System.exit called}}
>
> This happens even with -B (batch) option.
>
> On a given project this would *fails systematically* in a new windows console
> (cmd.exe)
> {quote}[path_to_jdk]\java.exe -Dmaven.home=[path_to_maven]\apache-maven-3.6.3
> -Dclassworlds.conf=[path_to_maven]\bin..\bin\m2.conf
> -Dmaven.multiModuleProjectDirectory=[path_to_myproject] -Dfile.encoding=UTF-8
> -classpath [path_to_maven]\boot\plexus-classworlds-2.6.0.jar
> org.codehaus.plexus.classworlds.launcher.Launcher clean install -B
> {quote}
> This will *always works* in a new console window (cmd.exe).
> {quote}[path_to_jdk]\java.exe -Dmaven.home=[path_to_maven]\apache-maven-3.6.3
> -Dclassworlds.conf=[path_to_maven]\bin..\bin\m2.conf
> -Dmaven.multiModuleProjectDirectory=[path_to_myproject] -Dfile.encoding=UTF-8
> -Djansi.force=true -Djansi.passthrough=true -classpath
> [path_to_maven]\boot\plexus-classworlds-2.6.0.jar
> org.codehaus.plexus.classworlds.launcher.Launcher clean install -B
> {quote}
> Notice that both command have -B (batch mode which should turn off coloring),
> and the only difference is
>
> {{-Djansi.force=true -Djansi.passthrough=true}}
>
> {{maven-surefire-plugin/useSystemClassLoader does not have an impact on test
> results}}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6962) jvm.config via command line flags
[
https://issues.apache.org/jira/browse/MNG-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6962:
Fix Version/s: wontfix-candidate
> jvm.config via command line flags
> -
>
> Key: MNG-6962
> URL: https://issues.apache.org/jira/browse/MNG-6962
> Project: Maven
> Issue Type: New Feature
> Components: core
>Reporter: John Patrick
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Command line flag to provide location of .mvn/jvm.config
> On Jenkins I use https://plugins.jenkins.io/config-file-provider/ to provide
> a jvm.config file as jenkins is running on a private openshift. So that maven
> wrapper can download etc it needs to know the http proxy to use. That proxy
> is different to the developers so we can't check in the file that works for
> both environments.
> At the moment we something likes this;
> ```
> configFileProvider([
> configFile(fileId: 'maven-settings', variable: 'MAVEN_SETTINGS'),
> configFile(fileId: 'maven-jvm-options', variable: 'MAVEN_JVM_OPTIONS')
> ]) {
> sh 'mkdir .mvn'
> sh 'cp ${MAVEN_JVM_OPTIONS} .mvn/jvm.config'
> sh './mvnw -s ${MAVEN_SETTINGS} clean package'
> }
> ```
> Which feels 2 lines more than it needs to be, ideally it can be collapsed to
> something like;
> ```
> configFileProvider([
> configFile(fileId: 'maven-settings', variable: 'MAVEN_SETTINGS'),
> configFile(fileId: 'maven-jvm-options', variable: 'MAVEN_JVM_OPTIONS')
> ]) {
> sh './mvnw -s ${MAVEN_SETTINGS} --jvm-options ${MAVEN_JVM_OPTIONS}
> clean verify'
> }
> ```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6962) jvm.config via command line flags
[
https://issues.apache.org/jira/browse/MNG-6962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385753#comment-17385753
]
Michael Osipov commented on MNG-6962:
-
The purpose of this file is to be project-*specific* and not agnostic. If you
need general values, use {{MAVEN_OPTS}} for this.
> jvm.config via command line flags
> -
>
> Key: MNG-6962
> URL: https://issues.apache.org/jira/browse/MNG-6962
> Project: Maven
> Issue Type: New Feature
> Components: core
>Reporter: John Patrick
>Priority: Major
> Fix For: wontfix-candidate
>
>
> Command line flag to provide location of .mvn/jvm.config
> On Jenkins I use https://plugins.jenkins.io/config-file-provider/ to provide
> a jvm.config file as jenkins is running on a private openshift. So that maven
> wrapper can download etc it needs to know the http proxy to use. That proxy
> is different to the developers so we can't check in the file that works for
> both environments.
> At the moment we something likes this;
> ```
> configFileProvider([
> configFile(fileId: 'maven-settings', variable: 'MAVEN_SETTINGS'),
> configFile(fileId: 'maven-jvm-options', variable: 'MAVEN_JVM_OPTIONS')
> ]) {
> sh 'mkdir .mvn'
> sh 'cp ${MAVEN_JVM_OPTIONS} .mvn/jvm.config'
> sh './mvnw -s ${MAVEN_SETTINGS} clean package'
> }
> ```
> Which feels 2 lines more than it needs to be, ideally it can be collapsed to
> something like;
> ```
> configFileProvider([
> configFile(fileId: 'maven-settings', variable: 'MAVEN_SETTINGS'),
> configFile(fileId: 'maven-jvm-options', variable: 'MAVEN_JVM_OPTIONS')
> ]) {
> sh './mvnw -s ${MAVEN_SETTINGS} --jvm-options ${MAVEN_JVM_OPTIONS}
> clean verify'
> }
> ```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6801) MavenXpp3Writer doesn't retain structure
[
https://issues.apache.org/jira/browse/MNG-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385751#comment-17385751
]
Michael Osipov commented on MNG-6801:
-
We'd need to have
https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/properties/SortedProperties.html
in Modello to define:
{code:xml}
> MavenXpp3Writer doesn't retain structure
>
>
> Key: MNG-6801
> URL: https://issues.apache.org/jira/browse/MNG-6801
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Reporter: Liana Lupsa
>Priority: Major
>
> 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.3.4#803005)
[jira] [Comment Edited] (MNG-6801) MavenXpp3Writer doesn't retain structure
[
https://issues.apache.org/jira/browse/MNG-6801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385751#comment-17385751
]
Michael Osipov edited comment on MNG-6801 at 7/22/21, 8:15 PM:
---
We'd need to have
https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/properties/SortedProperties.html
in Modello to define:
{code:xml}
20
21 java.util.Properties
22 new org.codehaus.modello.SortedProperties()
23
{code}
was (Author: michael-o):
We'd need to have
https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/properties/SortedProperties.html
in Modello to define:
{code:xml}
> MavenXpp3Writer doesn't retain structure
>
>
> Key: MNG-6801
> URL: https://issues.apache.org/jira/browse/MNG-6801
> Project: Maven
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Reporter: Liana Lupsa
>Priority: Major
>
> 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.3.4#803005)
[jira] [Closed] (MNG-7141) different environment variables like JAVA_HOME depending on the project.
[
https://issues.apache.org/jira/browse/MNG-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7141.
---
Resolution: Information Provided
> different environment variables like JAVA_HOME depending on the project.
>
>
> Key: MNG-7141
> URL: https://issues.apache.org/jira/browse/MNG-7141
> Project: Maven
> Issue Type: Improvement
> Components: maven wrapper
>Reporter: Terrien Jean-Yves
>Priority: Major
>
> Hello,
> A suggestion :
> Add in script just after
> {code:sh}
>if [-f "$ HOME/.mavenrc"]; then
> . "$ HOME/.mavenrc"
>fi
> # < this to load local mavenrc
>if [-f ".mvn/mavenrc"]; then
> . ".mvn/mavenrc"
>fi
> {code}
> This allows to have different environment variables like JAVA_HOME depending
> on the project.
> Currently it is possible to choose the version of maven in the properties
> file but not the version of java.
> In all projects, the maven command is run with the same version of java
> because it depends on the user's environment and not the project.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-archetype] pzygielo opened a new pull request #67: Remove unused containers
pzygielo opened a new pull request #67: URL: https://github.com/apache/maven-archetype/pull/67 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7016) Some ITs still require outbound access
[
https://issues.apache.org/jira/browse/MNG-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7016:
Labels: up-for-grabs (was: )
> Some ITs still require outbound access
> --
>
> Key: MNG-7016
> URL: https://issues.apache.org/jira/browse/MNG-7016
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Priority: Major
> Labels: up-for-grabs
>
> We require our integration tests to rune completely offline or register deps
> in bootstrap to have them locally. To circumvent any download {{central}} is
> rerouted to {{target/null}}. Some projects still do download:
> {noformat}
> ./core-it-suite/target/test-classes/it0041/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/org/apache/maven/maven-core-it-support/1.2/maven-core-it-support-1.2-it.jar
> ./core-it-suite/target/test-classes/it0041/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/org/apache/maven/maven-core-it-support/1.2/maven-core-it-support-1.2.pom
> ./core-it-suite/target/test-classes/mng-0507/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/org/apache/maven/maven-core-it-support-old-location/1.1/maven-core-it-support-old-location-1.1.pom
> ./core-it-suite/target/test-classes/mng-0507/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/org/apache/maven/maven-core-it-support/1.1/maven-core-it-support-1.1.jar
> ./core-it-suite/target/test-classes/mng-0507/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/org/apache/maven/maven-core-it-support/1.1/maven-core-it-support-1.1.pom
> ./core-it-suite/target/test-classes/mng-2199-parent-version-range/expression/log.txt:[INFO]
> Downloading from central:
> https://repo1.maven.org/maven2/org/apache/apache/maven-metadata.xml
> ./core-it-suite/target/test-classes/mng-2199-parent-version-range/inherited/log.txt:[INFO]
> Downloading from central:
> https://repo1.maven.org/maven2/org/apache/apache/maven-metadata.xml
> ./core-it-suite/target/test-classes/mng-2199-parent-version-range/invalid/log.txt:[INFO]
> Downloading from central:
> https://repo1.maven.org/maven2/org/apache/apache/maven-metadata.xml
> ./core-it-suite/target/test-classes/mng-2199-parent-version-range/valid-exclusive-upper-bound/log.txt:[INFO]
> Downloading from central:
> https://repo1.maven.org/maven2/org/apache/apache/maven-metadata.xml
> ./core-it-suite/target/test-classes/mng-2199-parent-version-range/valid-inclusive-upper-bound/log.txt:[INFO]
> Downloading from central:
> https://repo1.maven.org/maven2/org/apache/apache/maven-metadata.xml
> ./core-it-suite/target/test-classes/mng-3259/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/com/thoughtworks/xstream/xstream-parent/1.4.15/xstream-parent-1.4.15.pom
> ./core-it-suite/target/test-classes/mng-3259/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/com/thoughtworks/xstream/xstream/1.4.15/xstream-1.4.15.jar
> ./core-it-suite/target/test-classes/mng-3259/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/com/thoughtworks/xstream/xstream/1.4.15/xstream-1.4.15.pom
> ./core-it-suite/target/test-classes/mng-3259/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/jboss/jboss-j2ee/3.2.3/jboss-j2ee-3.2.3.jar
> ./core-it-suite/target/test-classes/mng-3259/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/jboss/jboss-j2ee/3.2.3/jboss-j2ee-3.2.3.pom
> ./core-it-suite/target/test-classes/mng-3259/log.txt:[INFO] Downloading from
> central: https://repo1.maven.org/maven2/jmock/jmock/1.2.0/jmock-1.2.0.jar
> ./core-it-suite/target/test-classes/mng-3259/log.txt:[INFO] Downloading from
> central: https://repo1.maven.org/maven2/jmock/jmock/1.2.0/jmock-1.2.0.pom
> ./core-it-suite/target/test-classes/mng-3259/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/org/apache/maven/plugins/maven-ejb-plugin/3.1.0/maven-ejb-plugin-3.1.0.jar
> ./core-it-suite/target/test-classes/mng-3259/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/org/apache/maven/plugins/maven-ejb-plugin/3.1.0/maven-ejb-plugin-3.1.0.pom
> ./core-it-suite/target/test-classes/mng-3259/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.3/maven-surefire-plugin-2.3.jar
> ./core-it-suite/target/test-classes/mng-3259/log.txt:[INFO] Downloading from
> central:
> https://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.3/maven-surefire-plugin-2.3.pom
> ./core-it-suite/target/test-classes/mng-3259/log.txt:[INFO] Downloading from
> central:
> https://r
[jira] [Updated] (MNG-6648) 'mavenrc_pre' script does not receive arguments like mavenrc in Bourne shell does
[
https://issues.apache.org/jira/browse/MNG-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6648:
Fix Version/s: (was: waiting-for-feedback)
3.8.x-candidate
> 'mavenrc_pre' script does not receive arguments like mavenrc in Bourne shell
> does
> -
>
> Key: MNG-6648
> URL: https://issues.apache.org/jira/browse/MNG-6648
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.6.0, 3.6.1
>Reporter: Alix Lourme
>Assignee: Michael Osipov
>Priority: Major
> Labels: command-line, script
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
>
> Hello,
> In some corner-case, you could have to run Maven with a custom {{JAVA_HOME}}
> (JDK v8, v11, ... even if it is evil some plugin can be impacted by JDK at
> runtime).
> If it is per-project, [JVM and Command Line
> Options|https://maven.apache.org/docs/3.3.1/release-notes.html#JVM_and_Command_Line_Options]
> is not relevant and update {{JAVA_HOME}} each time in your environment could
> be boring.
> A command line user-custom-parameter (ex : {{-Dmy.jdk=11}}) could be simple
> to achieve that.
> A Maven script wrapper could be implemented for that, but it's like update
> the Maven distribution => evil.
> The *mavenrc_pre* (MNGSITE-246) could be perfect for that feature !
> But currently command line parameters are not used in script :(.
> If parameters are used dor script call, sample for {{mvn.cmd}} (windows):
> {code}
> if exist "%USERPROFILE%\mavenrc_pre.cmd" call "%USERPROFILE%\mavenrc_pre.cmd
> %*"
> {code}
> It's allow any user customization, using Maven standards.
> If relevant, I can provide PR.
> Best regards
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] michael-o opened a new pull request #511: [MNG-6648] 'mavenrc_pre' script does not receive arguments like maven…
michael-o opened a new pull request #511: URL: https://github.com/apache/maven/pull/511 …rc in Bourne shell does This closes #511 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7034) StackOverflowError thrown if a cycle exists in BOM imports
[ https://issues.apache.org/jira/browse/MNG-7034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7034: Fix Version/s: 3.8.x-candidate > StackOverflowError thrown if a cycle exists in BOM imports > -- > > Key: MNG-7034 > URL: https://issues.apache.org/jira/browse/MNG-7034 > Project: Maven > Issue Type: Bug > Components: core >Affects Versions: 3.1.0 >Reporter: Guillaume Nodet >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1, 3.8.x-candidate > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-pmd-plugin] SammyVimes opened a new pull request #44: [MPMD-318] Fix the aux classpath when includeTests is set to true
SammyVimes opened a new pull request #44: URL: https://github.com/apache/maven-pmd-plugin/pull/44 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MPMD) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MPMD-XXX] - Subject of the JIRA Ticket`, where you replace `MPMD-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-6648) 'mavenrc_pre' script does not receive arguments like mavenrc in Bourne shell does
[
https://issues.apache.org/jira/browse/MNG-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6648:
Summary: 'mavenrc_pre' script does not receive arguments like mavenrc in
Bourne shell does (was: Add command line parameters in 'mavenrc_pre' script)
> 'mavenrc_pre' script does not receive arguments like mavenrc in Bourne shell
> does
> -
>
> Key: MNG-6648
> URL: https://issues.apache.org/jira/browse/MNG-6648
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.6.0, 3.6.1
>Reporter: Alix Lourme
>Assignee: Michael Osipov
>Priority: Major
> Labels: command-line, script
> Fix For: 4.0.x-candidate, waiting-for-feedback
>
>
> Hello,
> In some corner-case, you could have to run Maven with a custom {{JAVA_HOME}}
> (JDK v8, v11, ... even if it is evil some plugin can be impacted by JDK at
> runtime).
> If it is per-project, [JVM and Command Line
> Options|https://maven.apache.org/docs/3.3.1/release-notes.html#JVM_and_Command_Line_Options]
> is not relevant and update {{JAVA_HOME}} each time in your environment could
> be boring.
> A command line user-custom-parameter (ex : {{-Dmy.jdk=11}}) could be simple
> to achieve that.
> A Maven script wrapper could be implemented for that, but it's like update
> the Maven distribution => evil.
> The *mavenrc_pre* (MNGSITE-246) could be perfect for that feature !
> But currently command line parameters are not used in script :(.
> If parameters are used dor script call, sample for {{mvn.cmd}} (windows):
> {code}
> if exist "%USERPROFILE%\mavenrc_pre.cmd" call "%USERPROFILE%\mavenrc_pre.cmd
> %*"
> {code}
> It's allow any user customization, using Maven standards.
> If relevant, I can provide PR.
> Best regards
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6648) 'mavenrc_pre' script does not receive arguments like mavenrc in Bourne shell does
[
https://issues.apache.org/jira/browse/MNG-6648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6648:
Issue Type: Bug (was: Improvement)
> 'mavenrc_pre' script does not receive arguments like mavenrc in Bourne shell
> does
> -
>
> Key: MNG-6648
> URL: https://issues.apache.org/jira/browse/MNG-6648
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.6.0, 3.6.1
>Reporter: Alix Lourme
>Assignee: Michael Osipov
>Priority: Major
> Labels: command-line, script
> Fix For: 4.0.x-candidate, waiting-for-feedback
>
>
> Hello,
> In some corner-case, you could have to run Maven with a custom {{JAVA_HOME}}
> (JDK v8, v11, ... even if it is evil some plugin can be impacted by JDK at
> runtime).
> If it is per-project, [JVM and Command Line
> Options|https://maven.apache.org/docs/3.3.1/release-notes.html#JVM_and_Command_Line_Options]
> is not relevant and update {{JAVA_HOME}} each time in your environment could
> be boring.
> A command line user-custom-parameter (ex : {{-Dmy.jdk=11}}) could be simple
> to achieve that.
> A Maven script wrapper could be implemented for that, but it's like update
> the Maven distribution => evil.
> The *mavenrc_pre* (MNGSITE-246) could be perfect for that feature !
> But currently command line parameters are not used in script :(.
> If parameters are used dor script call, sample for {{mvn.cmd}} (windows):
> {code}
> if exist "%USERPROFILE%\mavenrc_pre.cmd" call "%USERPROFILE%\mavenrc_pre.cmd
> %*"
> {code}
> It's allow any user customization, using Maven standards.
> If relevant, I can provide PR.
> Best regards
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MPMD-318) Incorrect aux classpath if 'includeTests' set to true
Semyon Danilov created MPMD-318: --- Summary: Incorrect aux classpath if 'includeTests' set to true Key: MPMD-318 URL: https://issues.apache.org/jira/browse/MPMD-318 Project: Maven PMD Plugin Issue Type: Bug Reporter: Semyon Danilov PmdReport#determineAuxClasspath determines classpath incorrectly in case if 'includeTests' is true: only test dependencies and test source paths are added to the classpath. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MENFORCER-280) Enforcer dependency convergence stumbles on selenium-java
[
https://issues.apache.org/jira/browse/MENFORCER-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MENFORCER-280:
-
Description:
When running the dependency convergence check, we get this impossible result:
{noformat}
Dependency convergence error for org.seleniumhq.selenium:selenium-java:3.3.1
paths to dependency are:
+-com.mywebapp:0-SNAPSHOT
+-org.seleniumhq.selenium:selenium-java:3.3.1
and
+-com.mywebapp:0-SNAPSHOT
+-org.seleniumhq.selenium:selenium-java:3.3.1
+-org.seleniumhq.selenium:selenium-java:3.1.0
{noformat}
was:
When running the dependency convergence check, we get this impossible result:
{{Dependency convergence error for org.seleniumhq.selenium:selenium-java:3.3.1
paths to dependency are:
+-com.mywebapp:0-SNAPSHOT
+-org.seleniumhq.selenium:selenium-java:3.3.1
and
+-com.mywebapp:0-SNAPSHOT
+-org.seleniumhq.selenium:selenium-java:3.3.1
+-org.seleniumhq.selenium:selenium-java:3.1.0}}
> Enforcer dependency convergence stumbles on selenium-java
> -
>
> Key: MENFORCER-280
> URL: https://issues.apache.org/jira/browse/MENFORCER-280
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Axel Fontaine
>Priority: Major
>
> When running the dependency convergence check, we get this impossible result:
> {noformat}
> Dependency convergence error for org.seleniumhq.selenium:selenium-java:3.3.1
> paths to dependency are:
> +-com.mywebapp:0-SNAPSHOT
> +-org.seleniumhq.selenium:selenium-java:3.3.1
> and
> +-com.mywebapp:0-SNAPSHOT
> +-org.seleniumhq.selenium:selenium-java:3.3.1
> +-org.seleniumhq.selenium:selenium-java:3.1.0
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7191) Remove undocumented environment variable MAVEN_CONFIG in startup scripts
[
https://issues.apache.org/jira/browse/MNG-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385592#comment-17385592
]
Hudson commented on MNG-7191:
-
Build failed in Jenkins: Maven » Maven TLP » maven » master #201
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/201/
> Remove undocumented environment variable MAVEN_CONFIG in startup scripts
>
>
> Key: MNG-7191
> URL: https://issues.apache.org/jira/browse/MNG-7191
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> During a review I have found this:
> {noformat}
> ./apache-maven/src/assembly/shared/run:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $@"
> {noformat}
> There is no counterpart for Windows command prompt nor is it used somewhere
> else in ITs. Let's remove it if we see no use for.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MENFORCER-357) RequirePluginVersions not recognizing versions-from-properties
[
https://issues.apache.org/jira/browse/MENFORCER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385594#comment-17385594
]
Hudson commented on MENFORCER-357:
--
Build failed in Jenkins: Maven » Maven TLP » maven-enforcer » master #76
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-enforcer/job/master/76/
> RequirePluginVersions not recognizing versions-from-properties
> --
>
> Key: MENFORCER-357
> URL: https://issues.apache.org/jira/browse/MENFORCER-357
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Jeffrey Bennett
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: Annotation 2020-08-02 024036.png, child-pom.xml,
> parent-pom.xml, sample-pom.xml
>
>
> Fails (plugin version as a property applied in pluginManagement):
> {code:xml}
>
> 1.0.0
>
>
>
>
>
> org.examplesome-plugin
> ${some.plugin.version}
>
>
>
>
>
> org.example
> some-plugin
>
>
>
> {code}
> Works OK: (plugin version as a raw-version in pluginManagement):
> {code:xml}
>
>
>
>
> org.example
> some-plugin
> 1.0.0
>
>
>
>
>
> org.example
> some-plugin
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7192) Remove unsed MAVEN_CMD_LINE_ARGS environment variable in startup scripts
[ https://issues.apache.org/jira/browse/MNG-7192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385593#comment-17385593 ] Hudson commented on MNG-7192: - Build failed in Jenkins: Maven » Maven TLP » maven » master #201 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/201/ > Remove unsed MAVEN_CMD_LINE_ARGS environment variable in startup scripts > > > Key: MNG-7192 > URL: https://issues.apache.org/jira/browse/MNG-7192 > Project: Maven > Issue Type: Task > Components: Command Line >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > It has been introduced in 70218af1c1824caa892e7e507463ea713faa7133 > This environment variable has several issues: > * Its usage has already been reduced: > https://github.com/apache/maven/commit/27eabec6c6b311d3b24eb2d5752634d9811f9f51, > > https://github.com/apache/maven/commit/6d304204389af94b75aa26cf30c7eb5bc90279ea, > > https://github.com/apache/maven/commit/27eabec6c6b311d3b24eb2d5752634d9811f9f51, > > https://github.com/apache/maven/commit/7589e43f57125ee078aeec15d3f2d62360727a57 > * Is is not consistently used between Bourne shell script and Windows command > script > * It breaks arguments/options with spaces in the Bourne shell script > * It is not used in any of our plugins according to the GitHub search in the > apache organization > * It is not realiable possible to break this up again in single args because > of whitespaces and incompatible quoting rules between Windows and POSIX, thus > requires non-portable Java code -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MENFORCER-357) RequirePluginVersions not recognizing versions-from-properties
[
https://issues.apache.org/jira/browse/MENFORCER-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MENFORCER-357.
Fix Version/s: 3.0.0
Assignee: Robert Scholte
Resolution: Fixed
I've created an IT and added it with
[ab53fd99607eb36554f2fd3af41847ad9568a5ed|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commit;h=ab53fd99607eb36554f2fd3af41847ad9568a5ed]
to confirm that this was solved as part of MENFORCER-359
> RequirePluginVersions not recognizing versions-from-properties
> --
>
> Key: MENFORCER-357
> URL: https://issues.apache.org/jira/browse/MENFORCER-357
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Jeffrey Bennett
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: Annotation 2020-08-02 024036.png, child-pom.xml,
> parent-pom.xml, sample-pom.xml
>
>
> Fails (plugin version as a property applied in pluginManagement):
> {code:xml}
>
> 1.0.0
>
>
>
>
>
> org.examplesome-plugin
> ${some.plugin.version}
>
>
>
>
>
> org.example
> some-plugin
>
>
>
> {code}
> Works OK: (plugin version as a raw-version in pluginManagement):
> {code:xml}
>
>
>
>
> org.example
> some-plugin
> 1.0.0
>
>
>
>
>
> org.example
> some-plugin
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (SUREFIRE-1932) Periodic failure caused by parallel execution of tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
EVGENII STRATOVICH updated SUREFIRE-1932:
-
Summary: Periodic failure caused by parallel execution of tests (was:
Periodic parallel execution of tests)
> Periodic failure caused by parallel execution of tests
> --
>
> Key: SUREFIRE-1932
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1932
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin, process forking
>Affects Versions: 3.0.0-M2, 3.0.0-M1, 3.0.0-M3, 3.0.0-M4, 3.0.0-M5
>Reporter: EVGENII STRATOVICH
>Priority: Trivial
>
> For parallel testing is used next stack of technologies: java 8 (openjdk
> version "1.8.0_292", OpenJDK Runtime Environment (build 1.8.0_292-b10),
> OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)), Jenkins, Selenium,
> Selenide, Selenoid etc.
> From time to time during execution I encounter different problem associated
> with maven surefire. I perform parallel testing using Jenkins and jenkins
> file:
>
> {code:java}
> stage('First suite'){
> parallel {
> stage('1 test'){
> }
> stage('2 test'){
> }
> }
> }
> {code}
> but periodically got error and failed stage due to failed test. Fragment of
> trace with error:
> {code:java}
> ExecutionException Error creating properties files for forking
> org.apache.maven.surefire.booter.SurefireBooterForkException:
> ExecutionException Error creating properties files for forking at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:532)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:405)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:321)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:266)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1314)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1159)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:932)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305) at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192) at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105) at
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:957) at
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289) at
> org.apache.maven.cli.MavenCli.main(MavenCli.java:193) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException:
> Error creating properties files for forking at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:604)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$700(ForkStarter.java:121)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:393)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:370)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
> java.util.concurrent.Threa
[GitHub] [maven] rfscholte opened a new pull request #510: [MNG-6656] Features must use userProperties instead of systemProperties
rfscholte opened a new pull request #510: URL: https://github.com/apache/maven/pull/510 Following this checklist to help us incorporate your contribution quickly and easily: - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MNG) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [ ] Each commit in the pull request should have a meaningful subject line and body. - [ ] Format the pull request title like `[MNG-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MNG-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [ ] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [ ] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the [Core IT][core-its] successfully. If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [ ] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). [core-its]: https://maven.apache.org/core-its/core-it-suite/ -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases
[
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385567#comment-17385567
]
Hudson commented on MNG-6759:
-
Build failed in Jenkins: Maven » Maven TLP » maven » MNG-7192 #2
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7192/2/
> [REGRESSION] Maven fails to use section from dependency when
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
> URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR] Try downloading the file manually from the project website.
> [ERROR]
> [ERROR] Then, install it using the command:
> [ERROR] mvn install:install-file -DgroupId=io.confluent
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar
> -Dfile=/path/to/file
> [ERROR]
> [ERROR] Alternatively, if you host your own repository you can deploy the
> file there:
> [ERROR] mvn deploy:deploy-file -DgroupId=io.confluent
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR] Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR] io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] apache.snapshots (https://repository.apache.org/snapshots,
> releases=false, snapshots=true),
> [ERROR] central (https://repo.maven.apache.org/maven2, releases=true,
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven
> 3.6.2 doesn't like?
> * Copying the section from ChildB into ChildA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7192) Remove unsed MAVEN_CMD_LINE_ARGS environment variable in startup scripts
[ https://issues.apache.org/jira/browse/MNG-7192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385566#comment-17385566 ] Hudson commented on MNG-7192: - Build failed in Jenkins: Maven » Maven TLP » maven » MNG-7192 #2 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7192/2/ > Remove unsed MAVEN_CMD_LINE_ARGS environment variable in startup scripts > > > Key: MNG-7192 > URL: https://issues.apache.org/jira/browse/MNG-7192 > Project: Maven > Issue Type: Task > Components: Command Line >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > It has been introduced in 70218af1c1824caa892e7e507463ea713faa7133 > This environment variable has several issues: > * Its usage has already been reduced: > https://github.com/apache/maven/commit/27eabec6c6b311d3b24eb2d5752634d9811f9f51, > > https://github.com/apache/maven/commit/6d304204389af94b75aa26cf30c7eb5bc90279ea, > > https://github.com/apache/maven/commit/27eabec6c6b311d3b24eb2d5752634d9811f9f51, > > https://github.com/apache/maven/commit/7589e43f57125ee078aeec15d3f2d62360727a57 > * Is is not consistently used between Bourne shell script and Windows command > script > * It breaks arguments/options with spaces in the Bourne shell script > * It is not used in any of our plugins according to the GitHub search in the > apache organization > * It is not realiable possible to break this up again in single args because > of whitespaces and incompatible quoting rules between Windows and POSIX, thus > requires non-portable Java code -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7191) Remove undocumented environment variable MAVEN_CONFIG in startup scripts
[
https://issues.apache.org/jira/browse/MNG-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385565#comment-17385565
]
Hudson commented on MNG-7191:
-
Build failed in Jenkins: Maven » Maven TLP » maven » MNG-7192 #2
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7192/2/
> Remove undocumented environment variable MAVEN_CONFIG in startup scripts
>
>
> Key: MNG-7191
> URL: https://issues.apache.org/jira/browse/MNG-7191
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> During a review I have found this:
> {noformat}
> ./apache-maven/src/assembly/shared/run:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $@"
> {noformat}
> There is no counterpart for Windows command prompt nor is it used somewhere
> else in ITs. Let's remove it if we see no use for.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7189) Remove undocumented environment variable MAVEN_BASEDIR in startup scripts
[
https://issues.apache.org/jira/browse/MNG-7189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385564#comment-17385564
]
Hudson commented on MNG-7189:
-
Build failed in Jenkins: Maven » Maven TLP » maven » MNG-7192 #2
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7192/2/
> Remove undocumented environment variable MAVEN_BASEDIR in startup scripts
> -
>
> Key: MNG-7189
> URL: https://issues.apache.org/jira/browse/MNG-7189
> Project: Maven
> Issue Type: Task
> Components: Command Line, Documentation: General
>Affects Versions: 4.0.0-alpha-1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> During a review I have found this:
> {noformat}
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir "$@"`}"
> {noformat}
> and
> {noformat}
> set "MAVEN_PROJECTBASEDIR=%MAVEN_BASEDIR%"
> if not "%MAVEN_PROJECTBASEDIR%"=="" goto endDetectBaseDir
> {noformat}
> I was about to remove it until I have found:
> {noformat}
> $ grep -r MAVEN_BASEDIR .
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6118SubmoduleInvocation.java:
> // It seems MAVEN_BASEDIR isn't always properly set, so make sure to
> have the right value here
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6118SubmoduleInvocation.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./environments/solaris-10-jdk7/apache-maven-3.3.9.patch:<
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-$(find_maven_basedir)}"
> ./environments/solaris-10-jdk7/apache-maven-3.3.9.patch:>
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
> ./environments/solaris-10-jdk8/apache-maven-3.3.9.patch:<
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-$(find_maven_basedir)}"
> ./environments/solaris-10-jdk8/apache-maven-3.3.9.patch:>
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
> {noformat}
> It is not clear why this variable is there and and why it is necessary. There
> are several ways to resolve this issue:
> * Remove it and rely on basedir discovery in scripts
> * Document it officially in the prolog of the scripts
> * Inline document them as private and used for testing purposes only
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7131) maven.config doesn't handle arguments with spaces in them
[
https://issues.apache.org/jira/browse/MNG-7131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385563#comment-17385563
]
Hudson commented on MNG-7131:
-
Build failed in Jenkins: Maven » Maven TLP » maven » MNG-7192 #2
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7192/2/
> maven.config doesn't handle arguments with spaces in them
> -
>
> Key: MNG-7131
> URL: https://issues.apache.org/jira/browse/MNG-7131
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.6.3
>Reporter: Stefan Oehme
>Assignee: Michael Osipov
>Priority: Minor
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> I tried putting a path with a space in the maven.config like so:
> {code:java}
> "-Dmy.path=/some/path with/a/space"
> {code}
> When asking for the my.path property inside Maven, I get the path with a
> trailing quote
> {code:java}
> /some/path with/a/space"
> {code}
> The file is parsed by [splitting it by
> whitespace|https://github.com/apache/maven/blob/c3cf29438e3d65d6ee5c5726f8611af99d9a649a/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L386].
> I suggest replacing that code with the much better
> [CommandLineUtils.translateCommandline(argLine)|https://github.com/codehaus-plexus/plexus-utils/blob/85a4a3c534752919dd97d757d4ef0fdb6d40eb8c/src/main/java/org/codehaus/plexus/util/cli/CommandLineUtils.java#L412]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7047) Validate that repo configuration does not contain any expression
[ https://issues.apache.org/jira/browse/MNG-7047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385562#comment-17385562 ] Hudson commented on MNG-7047: - Build failed in Jenkins: Maven » Maven TLP » maven » MNG-7192 #2 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7192/2/ > Validate that repo configuration does not contain any expression > > > Key: MNG-7047 > URL: https://issues.apache.org/jira/browse/MNG-7047 > Project: Maven > Issue Type: Improvement > Components: Inheritance and Interpolation >Affects Versions: 3.6.3 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Minor > Fix For: 4.0.0, 4.0.0-alpha-1 > > > MNG-7046 reverts the option to allow expressions in the repository > configuration. This should be secured in the ModelValidator to prevent > regression in the future. > As of Maven 4 expressions in the repository will fail the build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7190) Load mavenrc from /usr/local/etc also in Bourne shell script
[
https://issues.apache.org/jira/browse/MNG-7190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385561#comment-17385561
]
Hudson commented on MNG-7190:
-
Build failed in Jenkins: Maven » Maven TLP » maven » MNG-7192 #2
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/MNG-7192/2/
> Load mavenrc from /usr/local/etc also in Bourne shell script
>
>
> Key: MNG-7190
> URL: https://issues.apache.org/jira/browse/MNG-7190
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> On many systems third party packages go to {{/usr/local}}, therefore the RC
> files go to {{/usr/local/etc}}. Therefore, we should load from there first
> and then go over to {{/etc}} and finally to {{$HOME}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-7192) Remove unsed MAVEN_CMD_LINE_ARGS environment variable in startup scripts
[ https://issues.apache.org/jira/browse/MNG-7192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov closed MNG-7192. --- Resolution: Fixed Fixed with [1328d6ef7f952ac737050922e1cb2a2ff15cdd88|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=1328d6ef7f952ac737050922e1cb2a2ff15cdd88]. > Remove unsed MAVEN_CMD_LINE_ARGS environment variable in startup scripts > > > Key: MNG-7192 > URL: https://issues.apache.org/jira/browse/MNG-7192 > Project: Maven > Issue Type: Task > Components: Command Line >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > It has been introduced in 70218af1c1824caa892e7e507463ea713faa7133 > This environment variable has several issues: > * Its usage has already been reduced: > https://github.com/apache/maven/commit/27eabec6c6b311d3b24eb2d5752634d9811f9f51, > > https://github.com/apache/maven/commit/6d304204389af94b75aa26cf30c7eb5bc90279ea, > > https://github.com/apache/maven/commit/27eabec6c6b311d3b24eb2d5752634d9811f9f51, > > https://github.com/apache/maven/commit/7589e43f57125ee078aeec15d3f2d62360727a57 > * Is is not consistently used between Bourne shell script and Windows command > script > * It breaks arguments/options with spaces in the Bourne shell script > * It is not used in any of our plugins according to the GitHub search in the > apache organization > * It is not realiable possible to break this up again in single args because > of whitespaces and incompatible quoting rules between Windows and POSIX, thus > requires non-portable Java code -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven] asfgit closed pull request #492: [MNG-7192] Remove unsed MAVEN_CMD_LINE_ARGS environment variable in s…
asfgit closed pull request #492: URL: https://github.com/apache/maven/pull/492 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MNG-7192) Remove unsed MAVEN_CMD_LINE_ARGS environment variable in startup scripts
[ https://issues.apache.org/jira/browse/MNG-7192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov reassigned MNG-7192: --- Assignee: Michael Osipov > Remove unsed MAVEN_CMD_LINE_ARGS environment variable in startup scripts > > > Key: MNG-7192 > URL: https://issues.apache.org/jira/browse/MNG-7192 > Project: Maven > Issue Type: Task > Components: Command Line >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > > It has been introduced in 70218af1c1824caa892e7e507463ea713faa7133 > This environment variable has several issues: > * Its usage has already been reduced: > https://github.com/apache/maven/commit/27eabec6c6b311d3b24eb2d5752634d9811f9f51, > > https://github.com/apache/maven/commit/6d304204389af94b75aa26cf30c7eb5bc90279ea, > > https://github.com/apache/maven/commit/27eabec6c6b311d3b24eb2d5752634d9811f9f51, > > https://github.com/apache/maven/commit/7589e43f57125ee078aeec15d3f2d62360727a57 > * Is is not consistently used between Bourne shell script and Windows command > script > * It breaks arguments/options with spaces in the Bourne shell script > * It is not used in any of our plugins according to the GitHub search in the > apache organization > * It is not realiable possible to break this up again in single args because > of whitespaces and incompatible quoting rules between Windows and POSIX, thus > requires non-portable Java code -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (MNG-7192) Remove unsed MAVEN_CMD_LINE_ARGS environment variable in startup scripts
[ https://issues.apache.org/jira/browse/MNG-7192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-7192: Fix Version/s: 4.0.0-alpha-1 4.0.0 > Remove unsed MAVEN_CMD_LINE_ARGS environment variable in startup scripts > > > Key: MNG-7192 > URL: https://issues.apache.org/jira/browse/MNG-7192 > Project: Maven > Issue Type: Task > Components: Command Line >Reporter: Michael Osipov >Assignee: Michael Osipov >Priority: Major > Fix For: 4.0.0, 4.0.0-alpha-1 > > > It has been introduced in 70218af1c1824caa892e7e507463ea713faa7133 > This environment variable has several issues: > * Its usage has already been reduced: > https://github.com/apache/maven/commit/27eabec6c6b311d3b24eb2d5752634d9811f9f51, > > https://github.com/apache/maven/commit/6d304204389af94b75aa26cf30c7eb5bc90279ea, > > https://github.com/apache/maven/commit/27eabec6c6b311d3b24eb2d5752634d9811f9f51, > > https://github.com/apache/maven/commit/7589e43f57125ee078aeec15d3f2d62360727a57 > * Is is not consistently used between Bourne shell script and Windows command > script > * It breaks arguments/options with spaces in the Bourne shell script > * It is not used in any of our plugins according to the GitHub search in the > apache organization > * It is not realiable possible to break this up again in single args because > of whitespaces and incompatible quoting rules between Windows and POSIX, thus > requires non-portable Java code -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MNG-7191) Remove undocumented environment variable MAVEN_CONFIG in startup scripts
[
https://issues.apache.org/jira/browse/MNG-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7191.
---
Fix Version/s: 4.0.0-alpha-1
4.0.0
Assignee: Michael Osipov
Resolution: Fixed
Fixed with
[6b37fcbda828f1b77e01a401b09b04b55b871956|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=6b37fcbda828f1b77e01a401b09b04b55b871956].
> Remove undocumented environment variable MAVEN_CONFIG in startup scripts
>
>
> Key: MNG-7191
> URL: https://issues.apache.org/jira/browse/MNG-7191
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> During a review I have found this:
> {noformat}
> ./apache-maven/src/assembly/shared/run:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $@"
> {noformat}
> There is no counterpart for Windows command prompt nor is it used somewhere
> else in ITs. Let's remove it if we see no use for.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-7191) Remove environment variable MAVEN_CONFIG in startup scripts
[
https://issues.apache.org/jira/browse/MNG-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7191:
Summary: Remove environment variable MAVEN_CONFIG in startup scripts (was:
Document or remove environment variable MAVEN_CONFIG in startup scripts)
> Remove environment variable MAVEN_CONFIG in startup scripts
> ---
>
> Key: MNG-7191
> URL: https://issues.apache.org/jira/browse/MNG-7191
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Reporter: Michael Osipov
>Priority: Major
>
> During a review I have found this:
> {noformat}
> ./apache-maven/src/assembly/shared/run:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $@"
> {noformat}
> There is no counterpart for Windows command prompt nor is it used somewhere
> else in ITs. Let's remove it if we see no use for.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-7191) Remove undocumented environment variable MAVEN_CONFIG in startup scripts
[
https://issues.apache.org/jira/browse/MNG-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7191:
Summary: Remove undocumented environment variable MAVEN_CONFIG in startup
scripts (was: Remove environment variable MAVEN_CONFIG in startup scripts)
> Remove undocumented environment variable MAVEN_CONFIG in startup scripts
>
>
> Key: MNG-7191
> URL: https://issues.apache.org/jira/browse/MNG-7191
> Project: Maven
> Issue Type: Task
> Components: Command Line
>Reporter: Michael Osipov
>Priority: Major
>
> During a review I have found this:
> {noformat}
> ./apache-maven/src/assembly/shared/run:MAVEN_CMD_LINE_ARGS="$MAVEN_CONFIG $@"
> {noformat}
> There is no counterpart for Windows command prompt nor is it used somewhere
> else in ITs. Let's remove it if we see no use for.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-6380) Option -Dstyle.color=always doesn't force color output
[
https://issues.apache.org/jira/browse/MNG-6380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-6380.
---
Fix Version/s: (was: waiting-for-feedback)
4.0.0-alpha-1
4.0.0
3.8.2
Resolution: Fixed
Implicitly fixed by Jansi upgrade.
> Option -Dstyle.color=always doesn't force color output
> --
>
> Key: MNG-6380
> URL: https://issues.apache.org/jira/browse/MNG-6380
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Henning Hoefer
>Assignee: Michael Osipov
>Priority: Minor
> Labels: workaround-exists
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> When the output is not a TTY (e.g. on a CI server), the new option
> {{-Dstyle.color=always}} doesn't work, because JAnsi itself is disabling its
> color output.
> {code:bash}
> # OK, produces color:
> mvn -B -Dstyle.color=always package
> # FAIL, doesn't produce color:
> mvn -B -Dstyle.color=always package | less -R
> # WORKAROUND:
> MAVEN_OPTS=-Djansi.force=true mvn -B -Dstyle.color=always package | less -R
> {code}
> The {{-Dstyle.color=always}} option needs to imply {{-Djansi.force=true}} –
> otherwise, "always" doesn't really mean always.
> The problem for the implementation is, that the JAnsi option needs to be set
> as a system property way early during startup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-6380) Option -Dstyle.color=always doesn't force color output
[
https://issues.apache.org/jira/browse/MNG-6380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-6380:
---
Assignee: Michael Osipov
> Option -Dstyle.color=always doesn't force color output
> --
>
> Key: MNG-6380
> URL: https://issues.apache.org/jira/browse/MNG-6380
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Henning Hoefer
>Assignee: Michael Osipov
>Priority: Minor
> Labels: workaround-exists
> Fix For: waiting-for-feedback
>
>
> When the output is not a TTY (e.g. on a CI server), the new option
> {{-Dstyle.color=always}} doesn't work, because JAnsi itself is disabling its
> color output.
> {code:bash}
> # OK, produces color:
> mvn -B -Dstyle.color=always package
> # FAIL, doesn't produce color:
> mvn -B -Dstyle.color=always package | less -R
> # WORKAROUND:
> MAVEN_OPTS=-Djansi.force=true mvn -B -Dstyle.color=always package | less -R
> {code}
> The {{-Dstyle.color=always}} option needs to imply {{-Djansi.force=true}} –
> otherwise, "always" doesn't really mean always.
> The problem for the implementation is, that the JAnsi option needs to be set
> as a system property way early during startup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNG-6380) Option -Dstyle.color=always doesn't force color output
[
https://issues.apache.org/jira/browse/MNG-6380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-6380:
Issue Type: Bug (was: Improvement)
> Option -Dstyle.color=always doesn't force color output
> --
>
> Key: MNG-6380
> URL: https://issues.apache.org/jira/browse/MNG-6380
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.3
>Reporter: Henning Hoefer
>Priority: Minor
> Labels: workaround-exists
> Fix For: waiting-for-feedback
>
>
> When the output is not a TTY (e.g. on a CI server), the new option
> {{-Dstyle.color=always}} doesn't work, because JAnsi itself is disabling its
> color output.
> {code:bash}
> # OK, produces color:
> mvn -B -Dstyle.color=always package
> # FAIL, doesn't produce color:
> mvn -B -Dstyle.color=always package | less -R
> # WORKAROUND:
> MAVEN_OPTS=-Djansi.force=true mvn -B -Dstyle.color=always package | less -R
> {code}
> The {{-Dstyle.color=always}} option needs to imply {{-Djansi.force=true}} –
> otherwise, "always" doesn't really mean always.
> The problem for the implementation is, that the JAnsi option needs to be set
> as a system property way early during startup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Deleted] (MPH-176) summary
[ https://issues.apache.org/jira/browse/MPH-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov deleted MPH-176: --- > summary > --- > > Key: MPH-176 > URL: https://issues.apache.org/jira/browse/MPH-176 > Project: Maven Help Plugin > Issue Type: Test >Reporter: 1979809618 >Priority: Major > Original Estimate: 48h > Remaining Estimate: 48h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MENFORCER-298) bannedDependencies can break compilation against a timestamped snapshot
[
https://issues.apache.org/jira/browse/MENFORCER-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MENFORCER-298.
Assignee: Robert Scholte
Resolution: Done
MENFORCER-277 has been fixed, and based on the comments I will assume that it
will fix this issue too. Otherwise we can reopen it and try to write an
integrationtest to reproduce the issue.
> bannedDependencies can break compilation against a timestamped snapshot
> ---
>
> Key: MENFORCER-298
> URL: https://issues.apache.org/jira/browse/MENFORCER-298
> Project: Maven Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 3.0.0-M1, 3.0.0-M3
>Reporter: Jesse Glick
>Assignee: Robert Scholte
>Priority: Major
>
> While working heavily with timestamped snapshots across repositories
> (reactors) I found occasional build errors suggesting that
> {{maven-compiler-plugin}} was picking up the wrong version of a dependency.
> To reproduce, using say Maven 3.5.2:
> {code:none}
> git clone https://github.com/jenkinsci/jenkins
> cd jenkins
> git checkout e2c1ae15a3bc6a9e1dcde0bc139b34d2c5812214
> mvn -DskipTests -am -pl core clean install
> {code}
> Compilation will fail with some errors like
> {code:none}
> [ERROR]
> .../jenkins/core/src/main/java/jenkins/security/ClassFilterImpl.java:[77,19]
> error: cannot find symbol
> [ERROR] symbol: method setDefault(ClassFilterImpl)
> [ERROR] location: class ClassFilter
> {code}
> What is going on here is that [the artifact
> repository|http://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15-SNAPSHOT/]
> contains various timestamped snapshots for this base version of
> {{remoting}}. The {{jenkins}} commit requests the {{-3}} snapshot in its
> {{pom.xml}}; the newest currently available is {{-10}}, which represents an
> unrelated branch. The compiler error happens when
> {{jenkins/core/src/main/java/}} is compiled against the {{-10}} artifact.
> Now {{MavenITmng4189UniqueVersionSnapshotTest}} in
> {{maven-integration-testing}} verifies that the compiler classpath in such
> cases is correct, and in fact you can patch the IT to actually run the
> compiler and it will work as expected: Maven will copy the requested
> timestamped snapshot artifacts to the corresponding base versions, then
> return those from {{MavenProject.getCompileClasspathElements}}, as [this
> blog|http://blog.sonatype.com/2009/12/maven-dependency-resolution-a-repository-perspective/]
> says it will (without further explanation). Yet it breaks in {{jenkins}}.
> I managed to narrow this down to the fact that {{jenkins}} used the
> {{bannedDependencies}} Enforcer rule. If it uses only, say,
> {{}}, then there is no error. But running {{bannedDependencies}}
> changes the behavior of compilation (even though the {{enforce}} mojo
> passes): the {{-10}} artifacts ({{pom}} and {{jar}}) are downloaded, and the
> base artifacts (esp. {{remoting-3.15-SNAPSHOT.jar}}) are overwritten with the
> {{-10}} versions, not the {{-3}} versions as expected. By patching
> {{BannedDependencies}} I found that this problem occurs iff
> {{buildDependencyGraph}} is called. By adding
> {code}
> System.setSecurityManager( new SecurityManager()
> {
> @Override
> public void checkWrite( String file )
> {
> if ( file.contains( "remoting" ) )
> {
> System.err.println( file );
> Thread.dumpStack();
> }
> }
> @Override
> public void checkPermission( Permission perm )
> {
> }
> }
> );
> {code}
> I found this stack trace:
> {code:none}
> at java.io.FileOutputStream.(FileOutputStream.java:200)
> at java.io.FileOutputStream.(FileOutputStream.java:162)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:166)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:150)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:464)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:329)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:224)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:338)
> at
> org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:202)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.resolveDependencies(Maven31DependencyGraphBuilder.java:127)
> at
> org.apache.maven.shared.dependency.graph.internal.Maven31DependencyGraphBuilder.buildDependencyGraph(Maven31DependencyGraphBuilde
[jira] [Updated] (MPH-176) summary
[ https://issues.apache.org/jira/browse/MPH-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] 1979809618 updated MPH-176: --- Attachment: (was: error2.txt) > summary > --- > > Key: MPH-176 > URL: https://issues.apache.org/jira/browse/MPH-176 > Project: Maven Help Plugin > Issue Type: Test >Reporter: 1979809618 >Priority: Major > Original Estimate: 48h > Remaining Estimate: 48h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MENFORCER-368) finer JDK detection
[
https://issues.apache.org/jira/browse/MENFORCER-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MENFORCER-368.
Assignee: Robert Scholte
Resolution: Won't Fix
{{RequireJavaVersion}} refers first of all to the Java Runtime Envirnment for
Maven, which is often also used for tools like javac and javadoc.
If you want to use a different JDK for compilation, toolchains is indeed your
friend.
With the maven-toolchains-plugin you can specify the version based on a range,
so I don't see the need to provide a more finegrained solution with an enforcer
rule.
https://maven.apache.org/plugins/maven-toolchains-plugin/toolchains/jdk.html
> finer JDK detection
> ---
>
> Key: MENFORCER-368
> URL: https://issues.apache.org/jira/browse/MENFORCER-368
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 3.0.0-M3
>Reporter: Delany
>Assignee: Robert Scholte
>Priority: Major
>
> It seems the *requireJavaVersion* rule checks the version of the *java*
> executable. But I can set a java version of 8 and a *javac* version of 15
> using `update-alternatives --config javac`
> Suggest allowing a finer evaluation by adding configuration properties java,
> javac, and whatever else might be important. Maybe also a *versions* property
> for all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MPH-176) summary
1979809618 created MPH-176: -- Summary: summary Key: MPH-176 URL: https://issues.apache.org/jira/browse/MPH-176 Project: Maven Help Plugin Issue Type: Test Reporter: 1979809618 Attachments: error2.txt -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] pzygielo opened a new pull request #384: Remove unused method
pzygielo opened a new pull request #384: URL: https://github.com/apache/maven-surefire/pull/384 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MENFORCER-386) caching implementation
[
https://issues.apache.org/jira/browse/MENFORCER-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385444#comment-17385444
]
Robert Scholte commented on MENFORCER-386:
--
Looking at the implementation it looks like cache is never used. I wouldn't be
surprised if it dates back from Maven 1.
So we need to understand what the intention of 'cache' is and if it still fits
in the current implementation.
> caching implementation
> --
>
> Key: MENFORCER-386
> URL: https://issues.apache.org/jira/browse/MENFORCER-386
> Project: Maven Enforcer Plugin
> Issue Type: Bug
>Affects Versions: 3.0.0-M3
>Reporter: Delany
>Priority: Major
>
> The enforcer seems to cache results in a session but it does not persist them.
> The log will always say
> {noformat}
> [INFO] Adding ignore: META-INF/versions/*/module-info
> [INFO] Adding ignore: module-info{noformat}
> whether I add -D{{enforcer.ignoreCache}} or not. And in any case I don't see
> any module-info files being written.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MENFORCER-388) Extends RequirePluginVersions with banMavenDefaults
[ https://issues.apache.org/jira/browse/MENFORCER-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385443#comment-17385443 ] Hudson commented on MENFORCER-388: -- Build failed in Jenkins: Maven » Maven TLP » maven-enforcer » master #75 See https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-enforcer/job/master/75/ > Extends RequirePluginVersions with banMavenDefaults > --- > > Key: MENFORCER-388 > URL: https://issues.apache.org/jira/browse/MENFORCER-388 > Project: Maven Enforcer Plugin > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 3.0.0 > > > Since Maven 2.0.9 Maven comes with a set of predefined versions in the [super > POM|http://maven.apache.org/ref/current/maven-model-builder/super-pom.html] > and the [default lifecycle > bindings|http://maven.apache.org/ref/current/maven-core/default-bindings.html] > When using these plugins without explicit giving it a version in your pom, > the build depends on a specific Maven version. > Best practice is to lock these plugins in your pom, hence these Maven > defaults should be banned. > When using the Maven Wrapper, you have already locked the Maven version, in > which case you don't need to lock these versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (MENFORCER-388) Extends RequirePluginVersions with banMavenDefaults
[ https://issues.apache.org/jira/browse/MENFORCER-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MENFORCER-388. Resolution: Fixed Fixed in [1b8ca8f82815ec721e09abbd2330ce315893f2ed|https://gitbox.apache.org/repos/asf?p=maven-enforcer.git;a=commit;h=1b8ca8f82815ec721e09abbd2330ce315893f2ed] > Extends RequirePluginVersions with banMavenDefaults > --- > > Key: MENFORCER-388 > URL: https://issues.apache.org/jira/browse/MENFORCER-388 > Project: Maven Enforcer Plugin > Issue Type: Improvement >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Major > Fix For: 3.0.0 > > > Since Maven 2.0.9 Maven comes with a set of predefined versions in the [super > POM|http://maven.apache.org/ref/current/maven-model-builder/super-pom.html] > and the [default lifecycle > bindings|http://maven.apache.org/ref/current/maven-core/default-bindings.html] > When using these plugins without explicit giving it a version in your pom, > the build depends on a specific Maven version. > Best practice is to lock these plugins in your pom, hence these Maven > defaults should be banned. > When using the Maven Wrapper, you have already locked the Maven version, in > which case you don't need to lock these versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6380) Option -Dstyle.color=always doesn't force color output
[
https://issues.apache.org/jira/browse/MNG-6380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385375#comment-17385375
]
Henning Hoefer commented on MNG-6380:
-
I tried it in `maven-3.8.x` [3.8.2-SNAPSHOT
(c395ca976dc9eaed65dcdc0037508d1edbfb57f3)] and in `master`
[4.0.0-alpha-1-SNAPSHOT (0696cf14adec8fc4939b938844cfa93f421c1dfe)] and it
worked in both. :)
> Option -Dstyle.color=always doesn't force color output
> --
>
> Key: MNG-6380
> URL: https://issues.apache.org/jira/browse/MNG-6380
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.3
>Reporter: Henning Hoefer
>Priority: Minor
> Labels: workaround-exists
> Fix For: waiting-for-feedback
>
>
> When the output is not a TTY (e.g. on a CI server), the new option
> {{-Dstyle.color=always}} doesn't work, because JAnsi itself is disabling its
> color output.
> {code:bash}
> # OK, produces color:
> mvn -B -Dstyle.color=always package
> # FAIL, doesn't produce color:
> mvn -B -Dstyle.color=always package | less -R
> # WORKAROUND:
> MAVEN_OPTS=-Djansi.force=true mvn -B -Dstyle.color=always package | less -R
> {code}
> The {{-Dstyle.color=always}} option needs to imply {{-Djansi.force=true}} –
> otherwise, "always" doesn't really mean always.
> The problem for the implementation is, that the JAnsi option needs to be set
> as a system property way early during startup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven] gnodet commented on a change in pull request #486: [MNG-7182] Use a pull parser during the build/consumer transformation
gnodet commented on a change in pull request #486: URL: https://github.com/apache/maven/pull/486#discussion_r674625338 ## File path: maven-model-transform/src/test/java/org/apache/maven/model/transform/ConsumerPomXMLFilterTest.java ## @@ -82,10 +69,9 @@ protected AbstractSAXFilter getFilter( Consumer lexicalHandlerCo }; -RawToConsumerPomXMLFilter filter = -new RawToConsumerPomXMLFilterFactory( buildPomXMLFilterFactory ).get( Paths.get( "pom.xml" ) ); -filter.setFeature( "http://xml.org/sax/features/namespaces";, true ); -return filter; +parser = new RawToConsumerPomXMLFilterFactory( buildPomXMLFilterFactory ) +.get( parser, Paths.get( "pom.xml" ) ); +return parser; Review comment: I really don't get the problem, but once again, I've added an intermediary variable. Some people also prefer not returning instances created directly to ease debugging. -- 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-7189) Remove undocumented environment variable MAVEN_BASEDIR in startup scripts
[
https://issues.apache.org/jira/browse/MNG-7189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385362#comment-17385362
]
Hudson commented on MNG-7189:
-
Build failed in Jenkins: Maven » Maven TLP » maven » master #199
See
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven/job/master/199/
> Remove undocumented environment variable MAVEN_BASEDIR in startup scripts
> -
>
> Key: MNG-7189
> URL: https://issues.apache.org/jira/browse/MNG-7189
> Project: Maven
> Issue Type: Task
> Components: Command Line, Documentation: General
>Affects Versions: 4.0.0-alpha-1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> During a review I have found this:
> {noformat}
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir "$@"`}"
> {noformat}
> and
> {noformat}
> set "MAVEN_PROJECTBASEDIR=%MAVEN_BASEDIR%"
> if not "%MAVEN_PROJECTBASEDIR%"=="" goto endDetectBaseDir
> {noformat}
> I was about to remove it until I have found:
> {noformat}
> $ grep -r MAVEN_BASEDIR .
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6118SubmoduleInvocation.java:
> // It seems MAVEN_BASEDIR isn't always properly set, so make sure to
> have the right value here
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6118SubmoduleInvocation.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./environments/solaris-10-jdk7/apache-maven-3.3.9.patch:<
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-$(find_maven_basedir)}"
> ./environments/solaris-10-jdk7/apache-maven-3.3.9.patch:>
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
> ./environments/solaris-10-jdk8/apache-maven-3.3.9.patch:<
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-$(find_maven_basedir)}"
> ./environments/solaris-10-jdk8/apache-maven-3.3.9.patch:>
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
> {noformat}
> It is not clear why this variable is there and and why it is necessary. There
> are several ways to resolve this issue:
> * Remove it and rely on basedir discovery in scripts
> * Document it officially in the prolog of the scripts
> * Inline document them as private and used for testing purposes only
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MNG-7189) Remove undocumented environment variable MAVEN_BASEDIR in startup scripts
[
https://issues.apache.org/jira/browse/MNG-7189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-7189.
---
Resolution: Fixed
Fixed with
[b8cdac5573a27e97540dc1fd7b50fbe4de7d4410|https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=b8cdac5573a27e97540dc1fd7b50fbe4de7d4410]
and
[1adb6bcebcee4c848b65f1956031a0ce1b172d32|https://gitbox.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=1adb6bcebcee4c848b65f1956031a0ce1b172d32].
> Remove undocumented environment variable MAVEN_BASEDIR in startup scripts
> -
>
> Key: MNG-7189
> URL: https://issues.apache.org/jira/browse/MNG-7189
> Project: Maven
> Issue Type: Task
> Components: Command Line, Documentation: General
>Affects Versions: 4.0.0-alpha-1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> During a review I have found this:
> {noformat}
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir "$@"`}"
> {noformat}
> and
> {noformat}
> set "MAVEN_PROJECTBASEDIR=%MAVEN_BASEDIR%"
> if not "%MAVEN_PROJECTBASEDIR%"=="" goto endDetectBaseDir
> {noformat}
> I was about to remove it until I have found:
> {noformat}
> $ grep -r MAVEN_BASEDIR .
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6118SubmoduleInvocation.java:
> // It seems MAVEN_BASEDIR isn't always properly set, so make sure to
> have the right value here
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6118SubmoduleInvocation.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./environments/solaris-10-jdk7/apache-maven-3.3.9.patch:<
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-$(find_maven_basedir)}"
> ./environments/solaris-10-jdk7/apache-maven-3.3.9.patch:>
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
> ./environments/solaris-10-jdk8/apache-maven-3.3.9.patch:<
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-$(find_maven_basedir)}"
> ./environments/solaris-10-jdk8/apache-maven-3.3.9.patch:>
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
> {noformat}
> It is not clear why this variable is there and and why it is necessary. There
> are several ways to resolve this issue:
> * Remove it and rely on basedir discovery in scripts
> * Document it officially in the prolog of the scripts
> * Inline document them as private and used for testing purposes only
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-integration-testing] asfgit closed pull request #109: [MNG-7189] Remove undocumented environment variable MAVEN_BASEDIR in …
asfgit closed pull request #109: URL: https://github.com/apache/maven-integration-testing/pull/109 -- 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] asfgit closed pull request #490: [MNG-7189] Remove undocumented environment variable MAVEN_BASEDIR in …
asfgit closed pull request #490: URL: https://github.com/apache/maven/pull/490 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MNG-7189) Remove undocumented environment variable MAVEN_BASEDIR in startup scripts
[
https://issues.apache.org/jira/browse/MNG-7189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-7189:
Fix Version/s: 4.0.0-alpha-1
4.0.0
> Remove undocumented environment variable MAVEN_BASEDIR in startup scripts
> -
>
> Key: MNG-7189
> URL: https://issues.apache.org/jira/browse/MNG-7189
> Project: Maven
> Issue Type: Task
> Components: Command Line, Documentation: General
>Affects Versions: 4.0.0-alpha-1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 4.0.0, 4.0.0-alpha-1
>
>
> During a review I have found this:
> {noformat}
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir "$@"`}"
> {noformat}
> and
> {noformat}
> set "MAVEN_PROJECTBASEDIR=%MAVEN_BASEDIR%"
> if not "%MAVEN_PROJECTBASEDIR%"=="" goto endDetectBaseDir
> {noformat}
> I was about to remove it until I have found:
> {noformat}
> $ grep -r MAVEN_BASEDIR .
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6118SubmoduleInvocation.java:
> // It seems MAVEN_BASEDIR isn't always properly set, so make sure to
> have the right value here
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6118SubmoduleInvocation.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./environments/solaris-10-jdk7/apache-maven-3.3.9.patch:<
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-$(find_maven_basedir)}"
> ./environments/solaris-10-jdk7/apache-maven-3.3.9.patch:>
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
> ./environments/solaris-10-jdk8/apache-maven-3.3.9.patch:<
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-$(find_maven_basedir)}"
> ./environments/solaris-10-jdk8/apache-maven-3.3.9.patch:>
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
> {noformat}
> It is not clear why this variable is there and and why it is necessary. There
> are several ways to resolve this issue:
> * Remove it and rely on basedir discovery in scripts
> * Document it officially in the prolog of the scripts
> * Inline document them as private and used for testing purposes only
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (MNG-7189) Remove undocumented environment variable MAVEN_BASEDIR in startup scripts
[
https://issues.apache.org/jira/browse/MNG-7189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reassigned MNG-7189:
---
Assignee: Michael Osipov
> Remove undocumented environment variable MAVEN_BASEDIR in startup scripts
> -
>
> Key: MNG-7189
> URL: https://issues.apache.org/jira/browse/MNG-7189
> Project: Maven
> Issue Type: Task
> Components: Command Line, Documentation: General
>Affects Versions: 4.0.0-alpha-1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> During a review I have found this:
> {noformat}
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir "$@"`}"
> {noformat}
> and
> {noformat}
> set "MAVEN_PROJECTBASEDIR=%MAVEN_BASEDIR%"
> if not "%MAVEN_PROJECTBASEDIR%"=="" goto endDetectBaseDir
> {noformat}
> I was about to remove it until I have found:
> {noformat}
> $ grep -r MAVEN_BASEDIR .
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5937MavenWrapper.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6118SubmoduleInvocation.java:
> // It seems MAVEN_BASEDIR isn't always properly set, so make sure to
> have the right value here
> ./core-it-suite/src/test/java/org/apache/maven/it/MavenITmng6118SubmoduleInvocation.java:
> envVars.put( "MAVEN_BASEDIR", testDir.getAbsolutePath() );
> ./environments/solaris-10-jdk7/apache-maven-3.3.9.patch:<
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-$(find_maven_basedir)}"
> ./environments/solaris-10-jdk7/apache-maven-3.3.9.patch:>
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
> ./environments/solaris-10-jdk8/apache-maven-3.3.9.patch:<
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-$(find_maven_basedir)}"
> ./environments/solaris-10-jdk8/apache-maven-3.3.9.patch:>
> MAVEN_PROJECTBASEDIR="${MAVEN_BASEDIR:-`find_maven_basedir`}"
> {noformat}
> It is not clear why this variable is there and and why it is necessary. There
> are several ways to resolve this issue:
> * Remove it and rely on basedir discovery in scripts
> * Document it officially in the prolog of the scripts
> * Inline document them as private and used for testing purposes only
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-shade-plugin] kriegaex commented on pull request #110: [MSHADE-400] Self-minimisation with custom entry points
kriegaex commented on pull request #110: URL: https://github.com/apache/maven-shade-plugin/pull/110#issuecomment-884731787 OK, I squashed into one commit, using `Co-authored-by:` to set both of you as co-authors. Looks like GitHub understands it, I did it for the first time:  -- 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-7193) Introduce MAVEN_ARGS environment variable
[
https://issues.apache.org/jira/browse/MNG-7193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385087#comment-17385087
]
Michael Osipov edited comment on MNG-7193 at 7/22/21, 7:41 AM:
---
Another approach to the separation problem is to supply/parse {{maven.config}}
just like {{jvm.config}} and not in Java. It has two benefits:
* Processing of the two config files would be consistent
* It would perfectly solve the order problem and avoid hacks with a separator
token
was (Author: michael-o):
Another approach to the separation problem is to supply/parse {{maven.config}}
just like {{jvm.config}} and not in Java. It has two benefits:
* Processing of the two config files would be consistent
* It would perfectly solve the older problem and avoid hacks with a separator
token
> Introduce MAVEN_ARGS environment variable
> -
>
> Key: MNG-7193
> URL: https://issues.apache.org/jira/browse/MNG-7193
> Project: Maven
> Issue Type: New Feature
> Components: Command Line
>Affects Versions: 3.8.1
>Reporter: Michael Osipov
>Priority: Major
> Fix For: 4.0.x-candidate
>
>
> Over the last couple of years people demanded to always pass arguments down
> to Maven without supplying it specifically or repeat for every project over
> and over again in {{maven.config}}. Arguments like {{-B}} or {{-V}}.
> A new environment variable {{MAVEN_ARGS}} can be passed *before* the actual
> CLI arguments.
> Ideal precedence:
> {{MAVEN_ARGS}} is overwritten by {{maven.config}} is overwritten by CLI
> arguments. General to specific. Unfortunately, since {{MAVEN_ARGS}} will be
> passed just like CLI arguments there is no way to detect that these arguments
> came either via CLI or {{MAVEN_ARGS}}
> One option would be to add separator token which would be dropped internally
> thus makes it possible to differentiate between both, e.g,,
> {{MAVEN_ARGS_START [ARGS...] MAVEN_ARGS_STOP}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-shade-plugin] JanMosigItemis commented on pull request #110: [MSHADE-400] Self-minimisation with custom entry points
JanMosigItemis commented on pull request #110: URL: https://github.com/apache/maven-shade-plugin/pull/110#issuecomment-884708887 Do it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shade-plugin] kriegaex commented on pull request #110: [MSHADE-400] Self-minimisation with custom entry points
kriegaex commented on pull request #110: URL: https://github.com/apache/maven-shade-plugin/pull/110#issuecomment-884708342 @JanMosigItemis, would you mind if I squashed your commits (and my early one too)? The original workaround incl. unit test is no longer necessary, nor is my refactoring of it. Only a little bit of structural test refactoring is left over. @rmannibucau, I can squash your "basic dir handling in default shader" commit too, but also try to retain it, even though Tibor is not going to like it and probably going to squash before the merge anyway. Please also be so kind as to review this PR. I think it is as far as we should go before the next major release, for which you are planning more general refactoring. Thank you. -- 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-shade-plugin] kriegaex edited a comment on pull request #110: [MSHADE-400] Self-minimisation with custom entry points
kriegaex edited a comment on pull request #110: URL: https://github.com/apache/maven-shade-plugin/pull/110#issuecomment-884678704 -- 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-366) "Access denied" during 'minimizeJar'
[
https://issues.apache.org/jira/browse/MSHADE-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385304#comment-17385304
]
Alexander Kriegisch commented on MSHADE-366:
Please note that this issue is indirectly addressed by MSHADE-400, correctly
handling directories as input sources (similar to JARs) and also being able to
minimise the artifact of the executing module. Therefore, this issue should be
resolved together with MSHADE-400.
> "Access denied" during 'minimizeJar'
>
>
> Key: MSHADE-366
> URL: https://issues.apache.org/jira/browse/MSHADE-366
> Project: Maven Shade Plugin
> Issue Type: Bug
>Affects Versions: 3.2.3
> Environment: Windows 10 Professional, Java 8, Maven 3.6.3 (bundled in
> IntelliJ IDEA Ultimate 2020.1)
>Reporter: Alexander Kriegisch
>Priority: Major
> Attachments: full-build.log, module-build.log
>
>
> Whenever I use Maven Shade with {{minimizeJar}} on my Windows 10 box, I see
> this warning during the build:
> {code:none}
> [INFO] Including net.bytebuddy:byte-buddy:jar:1.10.10 in the shaded jar.
> [INFO] Minimizing jar de.scrum-master:remove-final-agent:jar:1.0-SNAPSHOT
> [WARNING]
> C:\Users\alexa\Documents\java-src\ByteBuddyAspect\remove-final-parent\remove-final-agent\target\classes
> (Zugriff verweigert)
> {code}
> "Zugriff verweigert" is German for "access denied".
> One sample plugin configuration is:
> {code:xml}
>
> org.apache.maven.plugins
> maven-shade-plugin
> 3.2.3
>
>
> package
>
> shade
>
>
> true
> false
> false
>
>
>
>
> {code}
> I removed my filters because even without them the same warning occurs. As
> soon as I deactivate {{minimizeJar}}, the warning is gone.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
