[jira] [Commented] (SUREFIRE-1432) trimStackTrace = false by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714051#comment-17714051
]
Jesse Glick commented on SUREFIRE-1432:
---
[~ste...@apache.org] how would defaulting {{trimStackTrace}} to {{false}}
_remove_ the ability to the get detailed results from test failures? In certain
cases (depending on the sort of application) it _restores_ that ability.
Setting it to {{true}} is fine if you know from experience that in your
application domain, test framework, etc. the trimmed lines will in fact be
irrelevant, and you want to make the root cause easier to spot instantly
without distractions.
> trimStackTrace = false by default
> -
>
> Key: SUREFIRE-1432
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1432
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *New description:*
> Currently, the default value of the config parameter _trimStackTrace_ is set
> to _true_. This fix changes the default value.
> *Old description:*
> Specify {{StackTraceInterpreterExtension}} abstract class with constructor
> parameter {{boolean trim}} and protected getter for {{trim}}. Single public
> method {{interpret(context): String}}.
> DefaultStackTraceImpl - current implementation that trimmed trace prints only
> test class
> SmartStackTraceImpl - full trace or the following if trimmed (for error):
> java.lang.NullPointerException: msg
> o.a.s.m.xyz.ExceptionThrownFromHereClass (three classes here max.)
> o.a.s.m.NestedStackTraceInTheSamePackage
> o.a.s.m.NestedStackTraceInTheSamePackage
> ...
> o.a.s.m.SomeTestInSamePackageTest
> o.a.s.m.SomeTestInSamePackageTest
> (for failure - assertion failed - only this: )
> SomeAssertionError: msg
> o.a.s.m.SomeTestInSamePackageTest
> o.a.s.m.SomeTestInSamePackageTest
> Here is brief package displayed or full Java package if totally different
> from package in test.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2087) rerunFailingTestsCount incorrectly marks failed parametrized test as pass
[ https://issues.apache.org/jira/browse/SUREFIRE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17678733#comment-17678733 ] Jesse Glick commented on SUREFIRE-2087: --- While a full fix would of course be to rerun parameterized tests as expected, I think it would suffice in the interim to just disable the rerun feature on parameterized tests, if that is easier to implement. It would certainly be better than pretending your test suite passes when in fact you have introduced a regression, which for a test runner is a critical defect. > rerunFailingTestsCount incorrectly marks failed parametrized test as pass > - > > Key: SUREFIRE-2087 > URL: https://issues.apache.org/jira/browse/SUREFIRE-2087 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 3.0.0-M4 >Reporter: Ramanan Rajendran >Priority: Major > > rerunFailingTestsCount is not working as expected with junit5 > `@ParameterizedTest` > If 1st iteration of the test passes and the 2nd one fails, it still marks the > test as flaky passed. > Eg: In the following run, iteration 1 with input A passed but iteration 2 > with input B failed. Iteration 2 was rerun 2 times and failed in all the > attempts. Instead of failing TestA, it's marked as flaky giving an overall > pass for the test suite. I believe it's using the Run 1 PASS as a gate to > mark the whole test as a pass. > > [INFO] Run 1: PASS > [ERROR] Run 2: TestA.iteration2:101 1 expectation failed. > Expected status code <400> doesn't match actual status code <401>. > [ERROR] Run 3: TestA.iteration2:101 1 expectation failed. > Expected status code <400> doesn't match actual status code <401>. > [ERROR] Run 4: TestA.iteration2:101 1 expectation failed. > <400> doesn't match actual status code <401>. > > Tests run: 23, Failures: 0, Errors: 0, Skipped: 2, Flakes: 1 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MSHADE-323) Flatten Maven Plugin conflicts with Maven Shade Plugin
[
https://issues.apache.org/jira/browse/MSHADE-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599113#comment-17599113
]
Jesse Glick commented on MSHADE-323:
https://github.com/mojohaus/flatten-maven-plugin/releases/tag/flatten-maven-plugin-1.3.0
> Flatten Maven Plugin conflicts with Maven Shade Plugin
> --
>
> Key: MSHADE-323
> URL: https://issues.apache.org/jira/browse/MSHADE-323
> Project: Maven Shade Plugin
> Issue Type: Bug
>Reporter: lakunma
>Priority: Minor
>
> When using Flatten Maven Plugin in the same project with Maven Shade Plugin
> then the dependency reduced POM is _not_ flattened.
> What i encountered that having flatten plugin configured according to
> [https://maven.apache.org/maven-ci-friendly.html], and having shade plugin
> configured with the default settings to produce uber jar the ${revision}
> variable remains and gets installed/deployed within the final pom, thus
> making the pom in the repository invalid.
> It seems that both plugins transform original pom. And then what gets
> installed in the last one, which is the 'shades' one. I'm not sure that's a
> bug (in a sense that it is shade's fault).
> See also [https://github.com/mojohaus/flatten-maven-plugin/issues/100]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SUREFIRE-2058) Corrupted STDOUT by directly writing to native stream in forked JVM 1 with UTF-8 console logging
[
https://issues.apache.org/jira/browse/SUREFIRE-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17553669#comment-17553669
]
Jesse Glick commented on SUREFIRE-2058:
---
I was able to confirm that M7 fixes at least one variety of the stream
corruption problem mentioned in the plugin FAQ.
([details|https://github.com/jenkinsci/plugin-pom/pull/557#issuecomment-1154075116])
Thanks!
> Corrupted STDOUT by directly writing to native stream in forked JVM 1 with
> UTF-8 console logging
>
>
> Key: SUREFIRE-2058
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2058
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M6
>Reporter: Zoltan Meze
>Assignee: Tibor Digana
>Priority: Blocker
> Fix For: 3.0.0-M7
>
>
> With 3.0.0-M6 surefire and slf4j + logback, most test runs end up with:
> {code:java}
> [WARNING] Corrupted channel by directly writing to native stream in forked
> JVM 1. {code}
> This only affects *3.0.0-M6* (3.0.0-M5 version is working fine in test
> project).
>
> After some digging, there are two different scenarios (most likely caused by
> the same issue):
> * 2-byte character at position 1023 (or N * 1024 - 1) in log message is
> causing the following warning
> {code:java}
> [WARNING] Corrupted channel by directly writing to native stream in forked
> JVM 1.
> {code}
> To reproduce this issue logback (with slf4j) should be used.
> Not able to reproduce with System.out.println.
> * 4-byte character at position 1023 (or N * 1024 - 1) in log message.
> Can be reproduced with System.out.println (logback not required in this case).
> This blocks surefire entirely at (from jstack):
> {code:java}
> "fork-1-event-thread" #30 daemon prio=5 os_prio=0 cpu=32350.09ms
> elapsed=32.94s tid=0x7ff8292d7800 nid=0x3caef runnable
> [0x7ff7876f6000]
>java.lang.Thread.State: RUNNABLE
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.decodeString(AbstractStreamDecoder.java:350)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:322)
> at
> org.apache.maven.surefire.api.stream.AbstractStreamDecoder.readString(AbstractStreamDecoder.java:196)
> at
> org.apache.maven.surefire.stream.EventDecoder.decode(EventDecoder.java:176)
> at
> org.apache.maven.plugin.surefire.extensions.EventConsumerThread.run(EventConsumerThread.java:73)
> {code}
>
> Project with reproducible tests (for both scenarios, more in README):
> [https://github.com/zoltanmeze/surefire-corrupted-channel]
>
> One workaround on M6 for now is to use different charset (instead of default
> UTF-8) or limit message size.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (MRESOLVER-253) Dynamic prefixes for LRM
[ https://issues.apache.org/jira/browse/MRESOLVER-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527568#comment-17527568 ] Jesse Glick commented on MRESOLVER-253: --- This sounds promising. Is https://github.com/apache/maven-resolver/blob/master/src/site/markdown/local-repository.md + https://github.com/apache/maven-resolver/blob/master/src/site/markdown/configuration.md intended to be user documentation, or is something higher-level planned for the main Maven site? > Dynamic prefixes for LRM > > > Key: MRESOLVER-253 > URL: https://issues.apache.org/jira/browse/MRESOLVER-253 > Project: Maven Resolver > Issue Type: New Feature > Components: Resolver >Reporter: Tamás Cservenák >Assignee: Tamás Cservenák >Priority: Major > Fix For: 1.8.1 > > > Enhances existing "enhanced" LRM (local repository manager) with "prefix" > from from path prefix composer. Default behavior is not changed (will not use > prefix, local repository will work as before). > The point in change is that it introduce a "composer", that is composing LRM > path prefixes, and is able to apply different strategies, and split local > repository into "installed" (locally built and installed) and "cached" > (downloaded from remote), etc. > There are several composer options out of the box: > * split between "cached" and locally "installed" artifacts > * split "cached" artifacts based on their origin (remote repository) > * split between "release" and "snapshot" versioned artifacts > These properties can all be configured via resolver "configuration", > essentially via session configuration. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (MCOMPILER-485) Incorrect internal string format in generated package-info.class files on Windows
[
https://issues.apache.org/jira/browse/MCOMPILER-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17502454#comment-17502454
]
Jesse Glick commented on MCOMPILER-485:
---
Will there be some notification when the fix is released to Central?
> Incorrect internal string format in generated package-info.class files on
> Windows
> -
>
> Key: MCOMPILER-485
> URL: https://issues.apache.org/jira/browse/MCOMPILER-485
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.10.0
> Environment: Windows, or any operating system with a file separator
> character other than a forward slash
>Reporter: Daniel Widdis
>Assignee: Olivier Lamy
>Priority: Major
> Fix For: 3.11.0
>
>
> In 3.10.0, a new feature to generate package-info classes was added in
> [[MCOMPILER-205] |https://github.com/apache/maven-compiler-plugin/pull/88]
> Unfortunately, the binary class file is incorrectly generated using Java's
> file toString() which uses a platform dependent file separator character: on
> Windows, these Strings contain a backslash. See [this
> line|https://github.com/gnodet/maven-compiler-plugin/blob/8521ef8fdd12cc0b85c1ace17114ed3d3ffd0b0c/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java#L1356]
> which passes the platform-dependent file name (minus the root path and .java
> extension) to the ClassWriter.
> The Java class file specification (4.2.1) specifies the internal format: "In
> this internal form, the ASCII periods (.) that normally separate the
> identifiers which make up the binary name are replaced by ASCII forward
> slashes (/)."
> This invalid class file format causes problems in downstream plugins, e.g.,
> * The bnd-maven-plugin fails with an error: Classes found in the wrong
> directory:
> \{oshi/jna/platform/unix/package-info.class=oshi\jna\platform\unix\package-info
> ... (and hundreds more) ... }
> * The JDK's
> [classFileParser|https://github.com/openjdk/jdk17/blob/74007890bb9a3fa3a65683a3f480e399f2b1a0b6/src/hotspot/share/classfile/classFileParser.cpp#L5797]
> will throw java.lang.NoClassDefFoundError:
> com\puppycrawl\tools\checkstyle\ant\package-info (wrong name:
> com/puppycrawl/tools/checkstyle/ant/package-info
> Steps to reproduce:
> # Perform a build on any Windows machine using maven-compiler-plugin 3.10.0
> # Inspect any of the generated package-info.class files in target/classes
> using a text editor
> Expected behavior:
> Internal strings representing package names use forward slashes
> Observed behavior:
> Internal strings representing package names use backward slashes
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1911) Groovy-based JUnit 4 tests no longer run w/ 5 in classpath
[
https://issues.apache.org/jira/browse/SUREFIRE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468167#comment-17468167
]
Jesse Glick commented on SUREFIRE-1911:
---
Good to know that is a resolution once the problem is noticed, but it is still
very dangerous for the mojo to silently decline to run any tests.
> Groovy-based JUnit 4 tests no longer run w/ 5 in classpath
> --
>
> Key: SUREFIRE-1911
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1911
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Jesse Glick
>Assignee: Tibor Digana
>Priority: Major
> Labels: regression
>
> Using Maven 3.8.1 and JDK 8,
> https://github.com/jenkins-infra/pipeline-library/commit/48fc69bdd3f7e3adbebea76b8bf68edfe5ed3e32
> causes {{mvn test}} to not do anything:
> {code:none}
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> {code}
> In 3.0.0-M3, or for that matter 3.0.0-M4, this runs a variety of tests as
> expected. {{git bisect}} points to the fix of SUREFIRE-1787 as the culprit:
> {code:none}
> d5bbb3f9ae37ff5ad2bb7e8b3c11d1f24ea6f041 is the first bad commit
> commit d5bbb3f9ae37ff5ad2bb7e8b3c11d1f24ea6f041
> Author: tibordigana
> Date: Sat May 2 13:08:16 2020 +0200
> [SUREFIRE-1787] Support multiple runners (JUnit4, TestNG, other) and
> their API in JUnit5 Provider
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (SUREFIRE-1911) Groovy-based JUnit 4 tests no longer run w/ 5 in classpath
[
https://issues.apache.org/jira/browse/SUREFIRE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17411203#comment-17411203
]
Jesse Glick commented on SUREFIRE-1911:
---
Struck again, this time in Jenkins core, and apparently causing Java-based
JUnit 4 tests to be silently skipped:
* https://github.com/jnr/jnr-ffi/pull/269
* https://github.com/jenkinsci/jenkins/pull/5703
* https://github.com/jenkinsci/jenkins/pull/5712
* https://github.com/jenkinsci/jenkins/pull/5713
> Groovy-based JUnit 4 tests no longer run w/ 5 in classpath
> --
>
> Key: SUREFIRE-1911
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1911
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Jesse Glick
>Assignee: Tibor Digana
>Priority: Major
> Labels: regression
>
> Using Maven 3.8.1 and JDK 8,
> https://github.com/jenkins-infra/pipeline-library/commit/48fc69bdd3f7e3adbebea76b8bf68edfe5ed3e32
> causes {{mvn test}} to not do anything:
> {code:none}
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> {code}
> In 3.0.0-M3, or for that matter 3.0.0-M4, this runs a variety of tests as
> expected. {{git bisect}} points to the fix of SUREFIRE-1787 as the culprit:
> {code:none}
> d5bbb3f9ae37ff5ad2bb7e8b3c11d1f24ea6f041 is the first bad commit
> commit d5bbb3f9ae37ff5ad2bb7e8b3c11d1f24ea6f041
> Author: tibordigana
> Date: Sat May 2 13:08:16 2020 +0200
> [SUREFIRE-1787] Support multiple runners (JUnit4, TestNG, other) and
> their API in JUnit5 Provider
> {code}
--
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=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=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]
> error: cannot
[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=17385140#comment-17385140
]
Jesse Glick commented on MNG-6380:
--
Seems to work in
{code:none}
Apache Maven 3.8.2-SNAPSHOT (c395ca976dc9eaed65dcdc0037508d1edbfb57f3)
{code}
> 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)
[jira] [Commented] (SUREFIRE-1911) Groovy-based JUnit 4 tests no longer run w/ 5 in classpath
[
https://issues.apache.org/jira/browse/SUREFIRE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17346381#comment-17346381
]
Jesse Glick commented on SUREFIRE-1911:
---
{code:none}
$ mvn dependency:tree
…
[INFO] io.jenkins.infra:pipeline-library:jar:0.0.1
[INFO] +- org.codehaus.groovy:groovy-all:pom:3.0.7:test
…
[INFO] | +- org.codehaus.groovy:groovy-test:jar:3.0.7:test
[INFO] | | \- junit:junit:jar:4.13.1:test
[INFO] | | \- org.hamcrest:hamcrest-core:jar:1.3:test
[INFO] | +- org.codehaus.groovy:groovy-test-junit5:jar:3.0.7:test
[INFO] | | +- org.junit.platform:junit-platform-launcher:jar:1.7.0:test
[INFO] | | | \- org.junit.platform:junit-platform-engine:jar:1.7.0:test
[INFO] | | \- org.junit.jupiter:junit-jupiter-engine:jar:5.7.0:test
…
[INFO] +- org.junit.jupiter:junit-jupiter-api:jar:5.7.0:test
[INFO] | +- org.apiguardian:apiguardian-api:jar:1.1.0:test
[INFO] | +- org.opentest4j:opentest4j:jar:1.2.0:test
[INFO] | \- org.junit.platform:junit-platform-commons:jar:1.7.0:test
…
{code}
> Groovy-based JUnit 4 tests no longer run w/ 5 in classpath
> --
>
> Key: SUREFIRE-1911
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1911
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 3.0.0-M5
>Reporter: Jesse Glick
>Assignee: Tibor Digana
>Priority: Major
> Labels: regression
>
> Using Maven 3.8.1 and JDK 8,
> https://github.com/jenkins-infra/pipeline-library/commit/48fc69bdd3f7e3adbebea76b8bf68edfe5ed3e32
> causes {{mvn test}} to not do anything:
> {code:none}
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> {code}
> In 3.0.0-M3, or for that matter 3.0.0-M4, this runs a variety of tests as
> expected. {{git bisect}} points to the fix of SUREFIRE-1787 as the culprit:
> {code:none}
> d5bbb3f9ae37ff5ad2bb7e8b3c11d1f24ea6f041 is the first bad commit
> commit d5bbb3f9ae37ff5ad2bb7e8b3c11d1f24ea6f041
> Author: tibordigana
> Date: Sat May 2 13:08:16 2020 +0200
> [SUREFIRE-1787] Support multiple runners (JUnit4, TestNG, other) and
> their API in JUnit5 Provider
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1787) Support multiple runners (JUnit4, TestNG, other) and their API in JUnit5 Provider
[ https://issues.apache.org/jira/browse/SUREFIRE-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335809#comment-17335809 ] Jesse Glick commented on SUREFIRE-1787: --- Appears to have caused a regression: SUREFIRE-1911 > Support multiple runners (JUnit4, TestNG, other) and their API in JUnit5 > Provider > - > > Key: SUREFIRE-1787 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1787 > Project: Maven Surefire > Issue Type: Improvement > Components: JUnit 5.x support, Maven Failsafe Plugin, Maven Surefire > Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana >Priority: Major > Fix For: 3.0.0-M5 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (SUREFIRE-1911) Groovy-based JUnit 4 tests no longer run w/ 5 in classpath
Jesse Glick created SUREFIRE-1911:
-
Summary: Groovy-based JUnit 4 tests no longer run w/ 5 in classpath
Key: SUREFIRE-1911
URL: https://issues.apache.org/jira/browse/SUREFIRE-1911
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support, Maven Surefire Plugin
Affects Versions: 3.0.0-M5
Reporter: Jesse Glick
Using Maven 3.8.1 and JDK 8,
https://github.com/jenkins-infra/pipeline-library/commit/48fc69bdd3f7e3adbebea76b8bf68edfe5ed3e32
causes {{mvn test}} to not do anything:
{code:none}
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
{code}
In 3.0.0-M3, or for that matter 3.0.0-M4, this runs a variety of tests as
expected. {{git bisect}} points to the fix of SUREFIRE-1787 as the culprit:
{code:none}
d5bbb3f9ae37ff5ad2bb7e8b3c11d1f24ea6f041 is the first bad commit
commit d5bbb3f9ae37ff5ad2bb7e8b3c11d1f24ea6f041
Author: tibordigana
Date: Sat May 2 13:08:16 2020 +0200
[SUREFIRE-1787] Support multiple runners (JUnit4, TestNG, other) and their
API in JUnit5 Provider
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ARCHETYPE-539) Maven archetype:generate hangs on retrieval of archetype-catalog.xml even on offline mode
[
https://issues.apache.org/jira/browse/ARCHETYPE-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17227010#comment-17227010
]
Jesse Glick commented on ARCHETYPE-539:
---
This is particular painful when a Nexus mirror is configured; for some reason
seems to be much slower, taking ~2m to generate one project from archetype.
I would think that if the GAV are all defined, then this should work offline;
and if the GA are defined, and {{version}} is set to {{LATEST}} or {{RELEASE}},
then it should merely need to download {{maven-metadata.xml}} for that GA. The
full catalog should only be necessary if you are running in interactive mode
and browsing available archetypes.
> Maven archetype:generate hangs on retrieval of archetype-catalog.xml even on
> offline mode
> -
>
> Key: ARCHETYPE-539
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-539
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator
>Affects Versions: 3.0.1
> Environment: macOS High Sierra v10.13.1
> java version "1.8.0_121"
> Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
> Apache Maven 3.5.2 (138edd61fd100ec658bfa2d307c43b76940a5d7d;
> 2017-10-18T15:58:13+08:00)
> Maven home: /opt/maven/active
> Java version: 1.8.0_121, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.13.1", arch: "x86_64", family: "mac"
>Reporter: Franz Allan Valencia See
>Priority: Major
> Attachments: build.log
>
>
> *Steps to reproduce*
> 1.a Have slow connection
> 1.b.Alternatively, simulate slow connection with
> [crapify|https://www.npmjs.com/package/crapify]
> 1.b.1. Install crapify - {{npm install crapify -g}}
> 1.b.2. Run crapify - {{crapify --port=5000 --speed=1 start}}
> 1.b.3. Configure {{~/.m2/settings.xml}} to use crapify
> {code:xml}
>
> ...
>
>
> crapify-proxy
> true
> http
> localhost
> 5000
>
>
> ...
> {code}
>
> 2. Execute
> {code:bash}
> $ mvn archetype:generate -DgroupId=com.example -DartifactId=example
> -Dversion=1.0-SNAPSHOT -o
> {code}
>
> *Expected Behaviour:*
> The list of available archetypes would be shown to the user.
> _Note: I believe in older versions, only the basic archetypes are shown like
> quickstart_
>
> *Actual Behaviour:*
> Maven command hangs in this last last line:
> {code:bash}
> [DEBUG] Searching for remote catalog:
> https://repo.maven.apache.org/maven2/archetype-catalog.xml
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6976) --no-transfer-progress variant to diagnose download issue
[
https://issues.apache.org/jira/browse/MNG-6976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17219317#comment-17219317
]
Jesse Glick commented on MNG-6976:
--
A custom Logback configuration does not seem like a reasonable solution. Need
something short and documented; if not {{-ntp}} itself, then something equally
straightforward. Any usage of Maven from CI really needs this.
Will think about offering a PR to Maven Resolver. Minimally, if some downloads
are in flight yet there has been no output for a while, print the last message
that _would_ have been printed had {{-ntp}} not been in use.
> --no-transfer-progress variant to diagnose download issue
> -
>
> Key: MNG-6976
> URL: https://issues.apache.org/jira/browse/MNG-6976
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, Logging
>Affects Versions: 3.6.3
>Reporter: Jesse Glick
>Priority: Major
>
> {{-ntp}} is very welcome as a way to cut down on log spam. This is especially
> significant in a CI environment where Maven is being run in a virgin
> container/VM with no initial local repository, typically with a settings file
> directing downloads to some local mirror: every {{mvn}} command's output
> would otherwise be 99% transfer messages, making it very difficult to find
> real messages in the middle.
> The problem comes if there is a serious delay or even hang in some transfer.
> Without {{-ntp}}, you could guess that a build was stuck waiting for an
> overloaded Nexus server or the like just by scanning a timestamped log file
> and noticing that some big artifact had been requested but never served, or
> that thousands of little artifacts are being served but take a second each,
> etc. With {{-ntp}}, it is less obvious what is going wrong: there is no
> information about which artifact download is stuck, what the URL of the
> server it is stuck on is, or even whether Maven is waiting for a download at
> all (perhaps it is doing something unrelated).
> Suggestions:
> * Amend {{-ntp}} (or introduce an argument or a variant) so that if a
> particular artifact download is in progress for, say, 10s that a warning is
> emitted with the download URL. Or, if a whole block of downloads during some
> artifact resolution phase is taking more than, say, 5m, print a warning
> summarizing the server(s) in use, the number of artifacts requested vs.
> retrieved, etc.
> * Offer a convenient way to capture the sort of logging produced by {{-B}}
> without {{-ntp}} (i.e., one line per artifact requested or retrieved) but
> direct this to a file rather than the stdout/stderr of the {{mvn}} process,
> so it does not overwhelm a CI log yet can be inspected on demand.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1798) trimStackTrace should be false by default
[
https://issues.apache.org/jira/browse/SUREFIRE-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17189572#comment-17189572
]
Jesse Glick commented on SUREFIRE-1798:
---
bq. pushing this change right now would mean that the behavior of configuration
parameter would change. We have a big opportunity to use the version 3.0.0-M5
in Maven 3.7.0.
Misleading I think. From what I can tell, the current default version in Maven
is 2.12.4, which did trim stack traces by default but only above the test code:
in the above example, lines below {{BaseSlackIntegrationTest.setUp}}. (The
trimming actually seems to be broken in 2.12.4 at least on JUnit 4.13; fixed in
2.13.) Still potentially missing some critical diagnostic information, but far
less likely than the current (2.19+) behavior.
Therefore I would advise against such an upgrade until this issue is fixed, as
it would make everyday test-driven development less usable by default.
> trimStackTrace should be false by default
> -
>
> Key: SUREFIRE-1798
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1798
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Surefire Plugin
>Reporter: Romain Manni-Bucau
>Priority: Major
>
> True was intended to clean up the output but it always misses any useful data
> so let's set an useful default
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SUREFIRE-1827) The console output is not flushed
[
https://issues.apache.org/jira/browse/SUREFIRE-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186787#comment-17186787
]
Jesse Glick edited comment on SUREFIRE-1827 at 8/28/20, 8:08 PM:
-
According to {{git bisect}}, SUREFIRE-1658 is the source of the regression in
3.0.0-M5.
was (Author: jgl...@netbeans.org):
According to {{git bisect}}, SUREFIRE-1658 is the source of the regression.
> The console output is not flushed
> -
>
> Key: SUREFIRE-1827
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1827
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1827) The console output is not flushed
[
https://issues.apache.org/jira/browse/SUREFIRE-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186787#comment-17186787
]
Jesse Glick commented on SUREFIRE-1827:
---
According to {{git bisect}}, SUREFIRE-1658 is the source of the regression.
> The console output is not flushed
> -
>
> Key: SUREFIRE-1827
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1827
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, process
> forking
>Reporter: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M6
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1818) Surefire buffers log messages in memory instead of printing them out to the terminal which leads to OOM error.
[
https://issues.apache.org/jira/browse/SUREFIRE-1818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186779#comment-17186779
]
Jesse Glick commented on SUREFIRE-1818:
---
Sounds similar to SUREFIRE-1827.
> Surefire buffers log messages in memory instead of printing them out to the
> terminal which leads to OOM error.
> --
>
> Key: SUREFIRE-1818
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1818
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Anton Ermolenko
>Priority: Major
> Attachments: image-2020-07-11-18-57-41-164.png
>
>
> For unknown reason when running tests Surefire version 2.22.1 buffers logging
> messages in memory in {{ConcurrentLinkedQueue}} which leads to
> OutOfMemoryError when amount of logging messages is sufficiently large. If
> amount of memory is big enough to hold those messages, Surefire will print
> those log messages after running the tests.
> Downgrading to 2.18.1 resolves the issue and log messages appear on the
> terminal without delay.
> While it's printing those messages the following stack trace can be observed:
> {code:java}
> "main" #1 prio=5 os_prio=0 tid=0x7f3ff400b000 nid=0x30adf runnable
> [0x7f3ffb3d7000]
>java.lang.Thread.State: RUNNABLE
> at java.io.FileOutputStream.writeBytes(Native Method)
> at java.io.FileOutputStream.write(FileOutputStream.java:326)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> - locked <0x0005cc251490> (a java.io.BufferedOutputStream)
> at java.io.PrintStream.write(PrintStream.java:482)
> - locked <0x0005cc251470> (a java.io.PrintStream)
> at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
> at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291)
> at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104)
> - locked <0x0005cc2515b0> (a java.io.OutputStreamWriter)
> at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185)
> at java.io.PrintStream.write(PrintStream.java:527)
> - locked <0x0005cc251470> (a java.io.PrintStream)
> at java.io.PrintStream.print(PrintStream.java:583)
> at
> org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:99)
> at
> org.fusesource.jansi.FilterPrintStream.write(FilterPrintStream.java:107)
> at
> org.fusesource.jansi.FilterPrintStream.print(FilterPrintStream.java:156)
> at
> org.fusesource.jansi.FilterPrintStream.println(FilterPrintStream.java:231)
> - locked <0x0005cc22b6d0> (a org.fusesource.jansi.AnsiConsole$2)
> at org.slf4j.impl.SimpleLogger.write(SimpleLogger.java:318)
> at org.slf4j.impl.SimpleLogger.log(SimpleLogger.java:295)
> at org.slf4j.impl.SimpleLogger.warn(SimpleLogger.java:522)
> at org.apache.maven.cli.logging.Slf4jLogger.warn(Slf4jLogger.java:74)
> at
> org.apache.maven.plugin.surefire.log.PluginConsoleLogger.warning(PluginConsoleLogger.java:92)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter$CloseableCloser.run(ForkStarter.java:203)
> at
> org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.CommandLineUtils$1.call(CommandLineUtils.java:282)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:614)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
> at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> at
>
[jira] [Commented] (SUREFIRE-1798) trimStackTrace should be false by default
[ https://issues.apache.org/jira/browse/SUREFIRE-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17186778#comment-17186778 ] Jesse Glick commented on SUREFIRE-1798: --- Argued before in SUREFIRE-1226. > trimStackTrace should be false by default > - > > Key: SUREFIRE-1798 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1798 > Project: Maven Surefire > Issue Type: Task > Components: Maven Surefire Plugin >Reporter: Romain Manni-Bucau >Priority: Major > > True was intended to clean up the output but it always misses any useful data > so let's set an useful default -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MNG-6976) --no-transfer-progress variant to diagnose download issue
Jesse Glick created MNG-6976:
Summary: --no-transfer-progress variant to diagnose download issue
Key: MNG-6976
URL: https://issues.apache.org/jira/browse/MNG-6976
Project: Maven
Issue Type: Improvement
Components: Command Line, Logging
Affects Versions: 3.6.3
Reporter: Jesse Glick
{{-ntp}} is very welcome as a way to cut down on log spam. This is especially
significant in a CI environment where Maven is being run in a virgin
container/VM with no initial local repository, typically with a settings file
directing downloads to some local mirror: every {{mvn}} command's output would
otherwise be 99% transfer messages, making it very difficult to find real
messages in the middle.
The problem comes if there is a serious delay or even hang in some transfer.
Without {{-ntp}}, you could guess that a build was stuck waiting for an
overloaded Nexus server or the like just by scanning a timestamped log file and
noticing that some big artifact had been requested but never served, or that
thousands of little artifacts are being served but take a second each, etc.
With {{-ntp}}, it is less obvious what is going wrong: there is no information
about which artifact download is stuck, what the URL of the server it is stuck
on is, or even whether Maven is waiting for a download at all (perhaps it is
doing something unrelated).
Suggestions:
* Amend {{-ntp}} (or introduce an argument or a variant) so that if a
particular artifact download is in progress for, say, 10s that a warning is
emitted with the download URL. Or, if a whole block of downloads during some
artifact resolution phase is taking more than, say, 5m, print a warning
summarizing the server(s) in use, the number of artifacts requested vs.
retrieved, etc.
* Offer a convenient way to capture the sort of logging produced by {{-B}}
without {{-ntp}} (i.e., one line per artifact requested or retrieved) but
direct this to a file rather than the stdout/stderr of the {{mvn}} process, so
it does not overwhelm a CI log yet can be inspected on demand.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-667) dependency:sources skips *-test-sources.jar by default
[
https://issues.apache.org/jira/browse/MDEP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17007607#comment-17007607
]
Jesse Glick commented on MDEP-667:
--
I suppose
[this|https://github.com/apache/maven-dependency-plugin/blob/dd8928914ee4c6b08010a0f20063b4604207f8e6/src/main/java/org/apache/maven/plugins/dependency/resolvers/ResolveDependencySourcesMojo.java#L41-L54]
a bit too simplistic.
Note that while specifying {{\-Dclassifier=test\-sources}} without a specific
{{includeArtifactIds}} does seem to work¹, it is too slow to be a practical
workaround as it attempts to download such an artifact for _every_ dependency
(for example
{{commons\-codec/commons\-codec/1.9/commons\-codec\-1.9\-test\-sources.jar}}),
the vast majority of which did not specify {{tests}}.
¹After running the mojo with no arguments first. Using
{{\-DincludeClassifiers=sources,test\-sources}} on a single invocation does
_not_ work.
> dependency:sources skips *-test-sources.jar by default
> --
>
> Key: MDEP-667
> URL: https://issues.apache.org/jira/browse/MDEP-667
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: sources
>Affects Versions: 3.1.1
>Reporter: Jesse Glick
>Priority: Major
>
> Save the following to {{/tmp/bug/Dockerfile}}:
> {code:none}
> FROM maven:3.6.3-jdk-8
> RUN git clone -b support-core-2.65
> https://github.com/jenkinsci/support-core-plugin /src
> WORKDIR /src
> RUN git checkout HEAD^
> RUN mvn -B validate
> RUN mvn dependency:build-classpath | tee /classpath
> RUN ls -lR ~/.m2/repository/org/jenkins-ci/plugins/workflow/workflow-support
> | tee /before
> RUN mvn dependency:sources
> RUN ls -lR ~/.m2/repository/org/jenkins-ci/plugins/workflow/workflow-support
> | tee /after
> RUN diff /before /after | tee /diff
> RUN mvn dependency:sources -Dclassifier=test-sources
> -DincludeArtifactIds=workflow-support
> RUN ls -lR ~/.m2/repository/org/jenkins-ci/plugins/workflow/workflow-support
> | tee /workaround
> RUN diff /after /workaround | tee /diff-workaround
> {code}
> Now {{docker build /tmp/bug}} and you will see the problem: sources for [this
> dependency|https://github.com/jenkinsci/support-core-plugin/blob/086d28109a56e3464f7a46036ba35827e03d33b3/pom.xml#L171-L176]
> are omitted. The {{dependency:sources}} downloads sources for the main
> artifact:
> {code:none}
> > -rw-r--r-- 1 root root 91116 Jan 3 15:47 workflow-support-3.3-sources.jar
> {code}
> after printing
> {code:none}
> [INFO] The following files have been resolved:
> ...
> [INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:sources:3.3
> ...
> [INFO] The following files have NOT been resolved:
> ...
> [INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:3.3:test
> ...
> [INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:tests:3.3:test
> {code}
> but only the workaround command suffices to get sources for the test JAR:
> {code:none}
> > -rw-r--r-- 1 root root 33273 Jan 3 15:51
> > workflow-support-3.3-test-sources.jar
> {code}
> after printing
> {code:none}
> [INFO] The following files have been resolved:
> [INFO]
> org.jenkins-ci.plugins.workflow:workflow-support:jar:test-sources:3.3
> [INFO]
> [INFO] The following files have NOT been resolved:
> [INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:3.3:test
> [INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:tests:3.3:test
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-667) dependency:sources skips *-test-sources.jar by default
[
https://issues.apache.org/jira/browse/MDEP-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Glick updated MDEP-667:
-
Summary: dependency:sources skips *-test-sources.jar by default (was:
dependency:sources skips *--test-sources.jar by default)
> dependency:sources skips *-test-sources.jar by default
> --
>
> Key: MDEP-667
> URL: https://issues.apache.org/jira/browse/MDEP-667
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: sources
>Affects Versions: 3.1.1
>Reporter: Jesse Glick
>Priority: Major
>
> Save the following to {{/tmp/bug/Dockerfile}}:
> {code:none}
> FROM maven:3.6.3-jdk-8
> RUN git clone -b support-core-2.65
> https://github.com/jenkinsci/support-core-plugin /src
> WORKDIR /src
> RUN git checkout HEAD^
> RUN mvn -B validate
> RUN mvn dependency:build-classpath | tee /classpath
> RUN ls -lR ~/.m2/repository/org/jenkins-ci/plugins/workflow/workflow-support
> | tee /before
> RUN mvn dependency:sources
> RUN ls -lR ~/.m2/repository/org/jenkins-ci/plugins/workflow/workflow-support
> | tee /after
> RUN diff /before /after | tee /diff
> RUN mvn dependency:sources -Dclassifier=test-sources
> -DincludeArtifactIds=workflow-support
> RUN ls -lR ~/.m2/repository/org/jenkins-ci/plugins/workflow/workflow-support
> | tee /workaround
> RUN diff /after /workaround | tee /diff-workaround
> {code}
> Now {{docker build /tmp/bug}} and you will see the problem: sources for [this
> dependency|https://github.com/jenkinsci/support-core-plugin/blob/086d28109a56e3464f7a46036ba35827e03d33b3/pom.xml#L171-L176]
> are omitted. The {{dependency:sources}} downloads sources for the main
> artifact:
> {code:none}
> > -rw-r--r-- 1 root root 91116 Jan 3 15:47 workflow-support-3.3-sources.jar
> {code}
> after printing
> {code:none}
> [INFO] The following files have been resolved:
> ...
> [INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:sources:3.3
> ...
> [INFO] The following files have NOT been resolved:
> ...
> [INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:3.3:test
> ...
> [INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:tests:3.3:test
> {code}
> but only the workaround command suffices to get sources for the test JAR:
> {code:none}
> > -rw-r--r-- 1 root root 33273 Jan 3 15:51
> > workflow-support-3.3-test-sources.jar
> {code}
> after printing
> {code:none}
> [INFO] The following files have been resolved:
> [INFO]
> org.jenkins-ci.plugins.workflow:workflow-support:jar:test-sources:3.3
> [INFO]
> [INFO] The following files have NOT been resolved:
> [INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:3.3:test
> [INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:tests:3.3:test
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MDEP-667) dependency:sources skips *--test-sources.jar by default
Jesse Glick created MDEP-667:
Summary: dependency:sources skips *--test-sources.jar by default
Key: MDEP-667
URL: https://issues.apache.org/jira/browse/MDEP-667
Project: Maven Dependency Plugin
Issue Type: Bug
Components: sources
Affects Versions: 3.1.1
Reporter: Jesse Glick
Save the following to {{/tmp/bug/Dockerfile}}:
{code:none}
FROM maven:3.6.3-jdk-8
RUN git clone -b support-core-2.65
https://github.com/jenkinsci/support-core-plugin /src
WORKDIR /src
RUN git checkout HEAD^
RUN mvn -B validate
RUN mvn dependency:build-classpath | tee /classpath
RUN ls -lR ~/.m2/repository/org/jenkins-ci/plugins/workflow/workflow-support |
tee /before
RUN mvn dependency:sources
RUN ls -lR ~/.m2/repository/org/jenkins-ci/plugins/workflow/workflow-support |
tee /after
RUN diff /before /after | tee /diff
RUN mvn dependency:sources -Dclassifier=test-sources
-DincludeArtifactIds=workflow-support
RUN ls -lR ~/.m2/repository/org/jenkins-ci/plugins/workflow/workflow-support |
tee /workaround
RUN diff /after /workaround | tee /diff-workaround
{code}
Now {{docker build /tmp/bug}} and you will see the problem: sources for [this
dependency|https://github.com/jenkinsci/support-core-plugin/blob/086d28109a56e3464f7a46036ba35827e03d33b3/pom.xml#L171-L176]
are omitted. The {{dependency:sources}} downloads sources for the main
artifact:
{code:none}
> -rw-r--r-- 1 root root 91116 Jan 3 15:47 workflow-support-3.3-sources.jar
{code}
after printing
{code:none}
[INFO] The following files have been resolved:
...
[INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:sources:3.3
...
[INFO] The following files have NOT been resolved:
...
[INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:3.3:test
...
[INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:tests:3.3:test
{code}
but only the workaround command suffices to get sources for the test JAR:
{code:none}
> -rw-r--r-- 1 root root 33273 Jan 3 15:51
> workflow-support-3.3-test-sources.jar
{code}
after printing
{code:none}
[INFO] The following files have been resolved:
[INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:test-sources:3.3
[INFO]
[INFO] The following files have NOT been resolved:
[INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:3.3:test
[INFO]org.jenkins-ci.plugins.workflow:workflow-support:jar:tests:3.3:test
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory
[
https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16978470#comment-16978470
]
Jesse Glick commented on MNG-6405:
--
It seems this was released in 3.6.2?
> Incorrect basedir in forked executions when using flatten-maven-plugin with
> custom outputDirectory
> --
>
> Key: MNG-6405
> URL: https://issues.apache.org/jira/browse/MNG-6405
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Jesse Glick
>Assignee: Olivier Lamy
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am
> trying to use a variant of the tip shown
> [here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]:
> using {{flatten-maven-plugin}} with a generated POM file in the {{target}}
> directory. This works fine in almost all cases, since the plugin calls
> {{MavenProject.setPomFile}}, which leaves the {{basedir}} untouched.
> Unfortunately it fails for mojos which rely on the basedir that are run
> inside a forked execution, as I found when accidentally using {{source:jar}}
> when {{source:jar-no-fork}} was what I wanted. (Ditto when using
> {{findbugs:check}}.) This seems to be because {{deepCopy}} still calls
> {{setFile}}, so the basedir of a cloned project is not the same as the
> original—it is always the parent directory of the POM file.
> Fixing this should be trivial
> {code}
> diff --git
> a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> index 80a51935e..ee7a68635 100644
> --- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> +++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> @@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project )
> // disown the parent
>
> // copy fields
> -setFile( project.getFile() );
> +file = project.file;
> +basedir = project.basedir;
>
> // don't need a deep copy, they don't get modified or added/removed
> to/from - but make them unmodifiable to be
> // sure!
> {code}
> but I am unsure what the best approach is to validate the fix. A unit test in
> {{MavenProjectTest}}? An IT which calls {{flatten-maven-plugin}},
> {{source:jar}}, and some other mojo TBD which is sensitive to project
> basedir? Both?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6551) Packaging 'jar' binding plugin upgrades
[
https://issues.apache.org/jira/browse/MNG-6551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739984#comment-16739984
]
Jesse Glick commented on MNG-6551:
--
The {{maven-compiler-plugin}} update is import to pick up MCOMPILER-335, so
that a hello-world POM will build on newer JDKs.
> Packaging 'jar' binding plugin upgrades
> ---
>
> Key: MNG-6551
> URL: https://issues.apache.org/jira/browse/MNG-6551
> Project: Maven
> Issue Type: Sub-task
> Components: core, Dependencies
>Affects Versions: 3.5.0, 3.6.0
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 3.7.0-candidate
>
>
> This affects:
> ||groupId||artifactId||[previous
> version|https://maven.apache.org/ref/3.5.0/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging]||target
> version||
> |org.apache.maven.plugins|maven-resources-plugin|2.6|3.1.0|
> |org.apache.maven.plugins|maven-compiler-plugin|3.1|3.8.0|
> |org.apache.maven.plugins|maven-surefire-plugin|2.12.4|3.0.0-M3|
> |org.apache.maven.plugins|maven-jar-plugin|2.4|3.1.1|
> |org.apache.maven.plugins|maven-install-plugin|2.4|3.0.0-M1|
> |org.apache.maven.plugins|maven-deploy-plugin|2.7|3.0.0-M1|
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory
[
https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16733584#comment-16733584
]
Jesse Glick commented on MNG-6405:
--
Filed [PR 225|https://github.com/apache/maven/pull/225] with the patch above.
> Incorrect basedir in forked executions when using flatten-maven-plugin with
> custom outputDirectory
> --
>
> Key: MNG-6405
> URL: https://issues.apache.org/jira/browse/MNG-6405
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Jesse Glick
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am
> trying to use a variant of the tip shown
> [here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]:
> using {{flatten-maven-plugin}} with a generated POM file in the {{target}}
> directory. This works fine in almost all cases, since the plugin calls
> {{MavenProject.setPomFile}}, which leaves the {{basedir}} untouched.
> Unfortunately it fails for mojos which rely on the basedir that are run
> inside a forked execution, as I found when accidentally using {{source:jar}}
> when {{source:jar-no-fork}} was what I wanted. (Ditto when using
> {{findbugs:check}}.) This seems to be because {{deepCopy}} still calls
> {{setFile}}, so the basedir of a cloned project is not the same as the
> original—it is always the parent directory of the POM file.
> Fixing this should be trivial
> {code}
> diff --git
> a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> index 80a51935e..ee7a68635 100644
> --- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> +++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> @@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project )
> // disown the parent
>
> // copy fields
> -setFile( project.getFile() );
> +file = project.file;
> +basedir = project.basedir;
>
> // don't need a deep copy, they don't get modified or added/removed
> to/from - but make them unmodifiable to be
> // sure!
> {code}
> but I am unsure what the best approach is to validate the fix. A unit test in
> {{MavenProjectTest}}? An IT which calls {{flatten-maven-plugin}},
> {{source:jar}}, and some other mojo TBD which is sensitive to project
> basedir? Both?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-276) Allow ignoring dependency scopes in RequireUpperBoundDeps
[ https://issues.apache.org/jira/browse/MENFORCER-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707712#comment-16707712 ] Jesse Glick commented on MENFORCER-276: --- [~matthies] yes that makes sense. Ideally I think the rule should report your example as a violation without any additional configuration: even an experienced Maven user is unlikely to think of this situation as a possible problem without prompting. > Allow ignoring dependency scopes in RequireUpperBoundDeps > - > > Key: MENFORCER-276 > URL: https://issues.apache.org/jira/browse/MENFORCER-276 > Project: Maven Enforcer Plugin > Issue Type: New Feature >Reporter: Oleg Nenashev >Priority: Major > > We have recently adopted RequireUpperBoundDeps in the Jenkins project > (https://github.com/jenkinsci/plugin-pom/pull/67). In order to implement it, > [~jgl...@netbeans.org] added a support of ignoring particular dependencies in > MENFORCER-273. > Sometimes we declare dependencies between plugins for testing purposes > (scope=test), and in such case RequireUpperBoundDeps fails the build if there > is a test dependency conflicting with the main code. Although it may cause > instability of tests (including false positive results), it does not really > impact the distributable package in our case. > I propose to add another option for filtering of dependency scopes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MENFORCER-276) Allow ignoring dependency scopes in RequireUpperBoundDeps
[ https://issues.apache.org/jira/browse/MENFORCER-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16707542#comment-16707542 ] Jesse Glick commented on MENFORCER-276: --- [~matthies] not sure I understand. If you run the rule as currently implemented, it reports violations in all scopes, and a given dependency can only have one version used in all of the scopes in which it appears. Is there a concrete example you have in mind of this “hiding”? > Allow ignoring dependency scopes in RequireUpperBoundDeps > - > > Key: MENFORCER-276 > URL: https://issues.apache.org/jira/browse/MENFORCER-276 > Project: Maven Enforcer Plugin > Issue Type: New Feature >Reporter: Oleg Nenashev >Priority: Major > > We have recently adopted RequireUpperBoundDeps in the Jenkins project > (https://github.com/jenkinsci/plugin-pom/pull/67). In order to implement it, > [~jgl...@netbeans.org] added a support of ignoring particular dependencies in > MENFORCER-273. > Sometimes we declare dependencies between plugins for testing purposes > (scope=test), and in such case RequireUpperBoundDeps fails the build if there > is a test dependency conflicting with the main code. Although it may cause > instability of tests (including false positive results), it does not really > impact the distributable package in our case. > I propose to add another option for filtering of dependency scopes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
[
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16704836#comment-16704836
]
Jesse Glick commented on SUREFIRE-1588:
---
The problem seems to have been resolved upstream if you update the OpenJDK
package. (For me, from {{1.8.0_181-8u181-b13-1ubuntu0.18.10.1-b13}} to
{{1.8.0_191-8u191-b12-0ubuntu0.18.10.1-b12}}.) See
[Debian|https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925#97] and
[Ubuntu|https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1800792]
notices.
> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M1
>
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that
> all the entries from the surefire JAR are simply ignored.
>
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2]
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1593) 3.0.0-M1 produces invalid code sources on Windows
[
https://issues.apache.org/jira/browse/SUREFIRE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16691868#comment-16691868
]
Jesse Glick commented on SUREFIRE-1593:
---
[Final
fix|https://github.com/apache/maven-surefire/commit/f5cca5bcc2c85060c21c82eea0081d016cb86909]
> 3.0.0-M1 produces invalid code sources on Windows
> -
>
> Key: SUREFIRE-1593
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1593
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading, process forking
>Affects Versions: 3.0.0-M1
>Reporter: Jesse Glick
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M2
>
>
> The fix for SUREFIRE-1588 did not work correctly on Windows. (When
> active—i.e., when the drive letters of the system temporary directory, per
> SUREFIRE-1400, and the project basedir were the same.) It would produce
> relative URIs containing {{%5C}} where {{/}} was intended.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (SUREFIRE-1593) 3.0.0-M1 produces invalid code sources on Windows
Jesse Glick created SUREFIRE-1593:
-
Summary: 3.0.0-M1 produces invalid code sources on Windows
Key: SUREFIRE-1593
URL: https://issues.apache.org/jira/browse/SUREFIRE-1593
Project: Maven Surefire
Issue Type: Bug
Components: classloading, process forking
Affects Versions: 3.0.0-M1
Reporter: Jesse Glick
The fix for SUREFIRE-1588 did not work correctly on Windows. (When active—i.e.,
when the drive letters of the system temporary directory, per SUREFIRE-1400,
and the project basedir were the same.) It would produce relative URIs
containing {{%5C}} where {{/}} was intended.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-267) Upgrade to make Maven 3+
[ https://issues.apache.org/jira/browse/MENFORCER-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16680229#comment-16680229 ] Jesse Glick commented on MENFORCER-267: --- Doing this might fix MENFORCER-298 by the way. (I no longer personally care to pursue it since the Jenkins project has largely [moved away from using timestamped snapshots|https://github.com/jenkinsci/jep/blob/master/jep/305/README.adoc#timestamped-snapshot-issues].) > Upgrade to make Maven 3+ > > > Key: MENFORCER-267 > URL: https://issues.apache.org/jira/browse/MENFORCER-267 > Project: Maven Enforcer Plugin > Issue Type: Improvement >Affects Versions: 3.0.0 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Blocker > Fix For: 3.0.0 > > > * maven-dependency-tree needs to be updated to 3.0.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1588) Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
[
https://issues.apache.org/jira/browse/SUREFIRE-1588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16671777#comment-16671777
]
Jesse Glick commented on SUREFIRE-1588:
---
Building on the tip by [~cstamas] I was able to work around this issue without
POM modifications by adding to the {{}} section of my
{{~/.m2/settings.xml}}:
{code:xml}
SUREFIRE-1588
true
-Djdk.net.URLClassPath.disableClassPathURLCheck=true
{code}
(Note that this assumes that the project did not already have an important
{{argLine}} defined.)
I would also be eager to see an emergency 2.x fix.
> Surefire manifest jar classloading broken on latest Debian/Ubuntu Java8
> ---
>
> Key: SUREFIRE-1588
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1588
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.22.1
>Reporter: Cservenak, Tamas
>Priority: Major
>
> See issue [1], but in short: latest Java8 on Ubuntu/Debian/Mint family of
> Linuxes (am on Mint, Ubuntu derivative) contains this patch [3], and eforces
> Manifest class path entries to be relative, as defined in [2].
> Hence, surefire booter and rest of Maven classpath, that uses absolute URLs
> are simply discarded.
> Example error:
> {noformat}
> # Created at 2018-10-30T21:34:43.339
> Error: Could not find or load main class
> org.apache.maven.surefire.booter.ForkedBooter{noformat}
> using the new property
> {{-Djdk.net.URLClassPath.disableClassPathURLCheck=debug}} clearly shows that
> all the entries from the surefire JAR are simply ignored.
>
> [1] [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925]
> [2]
> https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#classpath
> [3] [https://hg.openjdk.java.net/jdk/jdk/rev/27135de165ac]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6118) Add option to execute goals on a specific module while building a multimodule project
[
https://issues.apache.org/jira/browse/MNG-6118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574196#comment-16574196
]
Jesse Glick commented on MNG-6118:
--
Came across this in a
[blog|http://andresalmiray.com/multi-module-project-builds-with-maven-and-gradle/].
The motivating use case is similar to one mentioned in MNG-5059.
> Add option to execute goals on a specific module while building a multimodule
> project
> -
>
> Key: MNG-6118
> URL: https://issues.apache.org/jira/browse/MNG-6118
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, Plugins and Lifecycle
>Reporter: Robert Scholte
>Priority: Major
>
> Suppose we have a multimodule which results in a war. In the end we want to
> run this war in a container like jetty. Up until now the {{jetty:run}} is
> executed on every module, which doesn't make sense for the other modules.
> This is just one of several examples where you want to control on which
> module to execute a specific goal. In case of wars, the plugin could check
> for the packaging type, but in case of jars this won't work.
> There should be a generic solution to mark goals for a specific module.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory
[
https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522608#comment-16522608
]
Jesse Glick commented on MNG-6405:
--
No, the bug in core remains. I was just noting that _one trigger_ for it—the
choice of mojo in the superpom—is now removed. The bug will continue to be a
problem whenever anyone uses any mojo which requests a forked execution.
> Incorrect basedir in forked executions when using flatten-maven-plugin with
> custom outputDirectory
> --
>
> Key: MNG-6405
> URL: https://issues.apache.org/jira/browse/MNG-6405
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Jesse Glick
>Priority: Major
>
> For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am
> trying to use a variant of the tip shown
> [here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]:
> using {{flatten-maven-plugin}} with a generated POM file in the {{target}}
> directory. This works fine in almost all cases, since the plugin calls
> {{MavenProject.setPomFile}}, which leaves the {{basedir}} untouched.
> Unfortunately it fails for mojos which rely on the basedir that are run
> inside a forked execution, as I found when accidentally using {{source:jar}}
> when {{source:jar-no-fork}} was what I wanted. (Ditto when using
> {{findbugs:check}}.) This seems to be because {{deepCopy}} still calls
> {{setFile}}, so the basedir of a cloned project is not the same as the
> original—it is always the parent directory of the POM file.
> Fixing this should be trivial
> {code}
> diff --git
> a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> index 80a51935e..ee7a68635 100644
> --- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> +++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> @@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project )
> // disown the parent
>
> // copy fields
> -setFile( project.getFile() );
> +file = project.file;
> +basedir = project.basedir;
>
> // don't need a deep copy, they don't get modified or added/removed
> to/from - but make them unmodifiable to be
> // sure!
> {code}
> but I am unsure what the best approach is to validate the fix. A unit test in
> {{MavenProjectTest}}? An IT which calls {{flatten-maven-plugin}},
> {{source:jar}}, and some other mojo TBD which is sensitive to project
> basedir? Both?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory
[
https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522321#comment-16522321
]
Jesse Glick commented on MNG-6405:
--
The superpom has evidently been fixed in Maven 3.5.4, so at least now any
problems would come from use of forked executions in your _own_ POM(s).
> Incorrect basedir in forked executions when using flatten-maven-plugin with
> custom outputDirectory
> --
>
> Key: MNG-6405
> URL: https://issues.apache.org/jira/browse/MNG-6405
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Jesse Glick
>Priority: Major
>
> For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am
> trying to use a variant of the tip shown
> [here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]:
> using {{flatten-maven-plugin}} with a generated POM file in the {{target}}
> directory. This works fine in almost all cases, since the plugin calls
> {{MavenProject.setPomFile}}, which leaves the {{basedir}} untouched.
> Unfortunately it fails for mojos which rely on the basedir that are run
> inside a forked execution, as I found when accidentally using {{source:jar}}
> when {{source:jar-no-fork}} was what I wanted. (Ditto when using
> {{findbugs:check}}.) This seems to be because {{deepCopy}} still calls
> {{setFile}}, so the basedir of a cloned project is not the same as the
> original—it is always the parent directory of the POM file.
> Fixing this should be trivial
> {code}
> diff --git
> a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> index 80a51935e..ee7a68635 100644
> --- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> +++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> @@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project )
> // disown the parent
>
> // copy fields
> -setFile( project.getFile() );
> +file = project.file;
> +basedir = project.basedir;
>
> // don't need a deep copy, they don't get modified or added/removed
> to/from - but make them unmodifiable to be
> // sure!
> {code}
> but I am unsure what the best approach is to validate the fix. A unit test in
> {{MavenProjectTest}}? An IT which calls {{flatten-maven-plugin}},
> {{source:jar}}, and some other mojo TBD which is sensitive to project
> basedir? Both?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory
[
https://issues.apache.org/jira/browse/MNG-6405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474611#comment-16474611
]
Jesse Glick commented on MNG-6405:
--
If you are using both {{flatten-maven-plugin}} and {{maven-release-plugin}},
_and_ any plugins which rely on the basedir (such as
{{frontend-maven-plugin}}), you may need to override the (poor?) choice in the
superpom:
{code:xml}
fix-superpom-source-fork
performRelease
true
maven-source-plugin
attach-sources
DO-NOT-ACTUALLY-RUN
attach-sources-no-fork
jar-no-fork
{code}
YMMV.
> Incorrect basedir in forked executions when using flatten-maven-plugin with
> custom outputDirectory
> --
>
> Key: MNG-6405
> URL: https://issues.apache.org/jira/browse/MNG-6405
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Jesse Glick
>Priority: Major
>
> For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am
> trying to use a variant of the tip shown
> [here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]:
> using {{flatten-maven-plugin}} with a generated POM file in the {{target}}
> directory. This works fine in almost all cases, since the plugin calls
> {{MavenProject.setPomFile}}, which leaves the {{basedir}} untouched.
> Unfortunately it fails for mojos which rely on the basedir that are run
> inside a forked execution, as I found when accidentally using {{source:jar}}
> when {{source:jar-no-fork}} was what I wanted. (Ditto when using
> {{findbugs:check}}.) This seems to be because {{deepCopy}} still calls
> {{setFile}}, so the basedir of a cloned project is not the same as the
> original—it is always the parent directory of the POM file.
> Fixing this should be trivial
> {code}
> diff --git
> a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> index 80a51935e..ee7a68635 100644
> --- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> +++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
> @@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project )
> // disown the parent
>
> // copy fields
> -setFile( project.getFile() );
> +file = project.file;
> +basedir = project.basedir;
>
> // don't need a deep copy, they don't get modified or added/removed
> to/from - but make them unmodifiable to be
> // sure!
> {code}
> but I am unsure what the best approach is to validate the fix. A unit test in
> {{MavenProjectTest}}? An IT which calls {{flatten-maven-plugin}},
> {{source:jar}}, and some other mojo TBD which is sensitive to project
> basedir? Both?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6405) Incorrect basedir in forked executions when using flatten-maven-plugin with custom outputDirectory
Jesse Glick created MNG-6405:
Summary: Incorrect basedir in forked executions when using
flatten-maven-plugin with custom outputDirectory
Key: MNG-6405
URL: https://issues.apache.org/jira/browse/MNG-6405
Project: Maven
Issue Type: Bug
Components: core
Affects Versions: 3.5.3
Reporter: Jesse Glick
For [JENKINS-51247|https://issues.jenkins-ci.org/browse/JENKINS-51247] I am
trying to use a variant of the tip shown
[here|https://github.com/mojohaus/flatten-maven-plugin/issues/53#issuecomment-340366191]:
using {{flatten-maven-plugin}} with a generated POM file in the {{target}}
directory. This works fine in almost all cases, since the plugin calls
{{MavenProject.setPomFile}}, which leaves the {{basedir}} untouched.
Unfortunately it fails for mojos which rely on the basedir that are run inside
a forked execution, as I found when accidentally using {{source:jar}} when
{{source:jar-no-fork}} was what I wanted. (Ditto when using
{{findbugs:check}}.) This seems to be because {{deepCopy}} still calls
{{setFile}}, so the basedir of a cloned project is not the same as the
original—it is always the parent directory of the POM file.
Fixing this should be trivial
{code}
diff --git
a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
index 80a51935e..ee7a68635 100644
--- a/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
+++ b/maven-core/src/main/java/org/apache/maven/project/MavenProject.java
@@ -1207,7 +1207,8 @@ private void deepCopy( MavenProject project )
// disown the parent
// copy fields
-setFile( project.getFile() );
+file = project.file;
+basedir = project.basedir;
// don't need a deep copy, they don't get modified or added/removed
to/from - but make them unmodifiable to be
// sure!
{code}
but I am unsure what the best approach is to validate the fix. A unit test in
{{MavenProjectTest}}? An IT which calls {{flatten-maven-plugin}},
{{source:jar}}, and some other mojo TBD which is sensitive to project basedir?
Both?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6066) Continuous Delivery friendly versions break with multi-module projects
[
https://issues.apache.org/jira/browse/MNG-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428707#comment-16428707
]
Jesse Glick commented on MNG-6066:
--
Ah, I knew about the Flatten plugin and was actually already using it for
{{deploy}}, but given the error message it seemed like Maven was _looking_ for
the wrong parent artifact so I did not even try activating it for other phases.
Indeed that seems to fix the problem.
> Continuous Delivery friendly versions break with multi-module projects
> --
>
> Key: MNG-6066
> URL: https://issues.apache.org/jira/browse/MNG-6066
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9
>Reporter: G. Richard Bellamy
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> When I have a multi-module maven project, and one of the sub-modules is a
> mult-module POM itself, the use of a continuous delivery friendly version in
> the parent breaks the build from within either {{sub-module-1}}
> or {{sub-module-2}}.
> Some Maven multi-module project like so:
> {noformat}
> parent
> + sub-module 1
> |+ child 1-1
> ||
> |+ child 1-2
> |
> + sub-module 2
> + child 2-1
> {noformat}
> In the example build below, I've set Maven to offline mode - this happens
> when online as well. Specifically, the problem is that Maven is looking for a
> parent POM with the version set to {{1.${revision\}}}, which is incorrect.
> I believe the problem stems from the fact that the value stored in the
> {{}} includes the property, which isn't correctly parsed.
> {code}
> 2016-07-16 12:49:59
> rbellamy@terraspark i ~/Development/test-cd-ci-friendly-versions master % mvn
> -o -DskipTests compile
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] child-1-1
> [INFO] child-1-2
> [INFO] sub-module-1
> [INFO] child-2-1
> [INFO] sub-module-2
> [INFO] test-cd-ci-friendly-versions
> [INFO]
> [INFO]
>
> [INFO] Building child-1-1 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> child-1-1 ---
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child-1-1 ---
> [INFO] Changes detected - recompiling the module!
> [WARNING] File encoding has not been set, using platform encoding UTF-8, i.e.
> build is platform dependent!
> [INFO] Compiling 1 source file to
> /Users/rbellamy/Development/test-cd-ci-friendly-versions/sub-module-1/child-1-1/target/classes
> [INFO]
> [INFO]
>
> [INFO] Building child-1-2 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> child-1-2 ---
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child-1-2 ---
> [INFO] Changes detected - recompiling the module!
> [WARNING] File encoding has not been set, using platform encoding UTF-8, i.e.
> build is platform dependent!
> [INFO] Compiling 1 source file to
> /Users/rbellamy/Development/test-cd-ci-friendly-versions/sub-module-1/child-1-2/target/classes
> [INFO]
> [INFO]
>
> [INFO] Building sub-module-1 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO]
>
> [INFO] Building child-2-1 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> child-2-1 ---
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child-2-1 ---
> [INFO] Changes detected - recompiling the module!
> [WARNING] File encoding has not been set, using platform encoding UTF-8, i.e.
> build is platform dependent!
> [INFO] Compiling 1 source file to
>
[jira] [Commented] (MNG-6066) Continuous Delivery friendly versions break with multi-module projects
[
https://issues.apache.org/jira/browse/MNG-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428597#comment-16428597
]
Jesse Glick commented on MNG-6066:
--
Maybe something like MNG-5059 would be the best approach, so I could run
something like
{code:none}
mvn -amp validate -pl submodule -Dtest=SomeTest test
{code}
which would process the parent/aggregator and dependency submodules just enough
to identify their artifacts but do no real work, and then run the designated
submodule through the full {{test}} phase including main and test compilation.
> Continuous Delivery friendly versions break with multi-module projects
> --
>
> Key: MNG-6066
> URL: https://issues.apache.org/jira/browse/MNG-6066
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9
>Reporter: G. Richard Bellamy
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> When I have a multi-module maven project, and one of the sub-modules is a
> mult-module POM itself, the use of a continuous delivery friendly version in
> the parent breaks the build from within either {{sub-module-1}}
> or {{sub-module-2}}.
> Some Maven multi-module project like so:
> {noformat}
> parent
> + sub-module 1
> |+ child 1-1
> ||
> |+ child 1-2
> |
> + sub-module 2
> + child 2-1
> {noformat}
> In the example build below, I've set Maven to offline mode - this happens
> when online as well. Specifically, the problem is that Maven is looking for a
> parent POM with the version set to {{1.${revision\}}}, which is incorrect.
> I believe the problem stems from the fact that the value stored in the
> {{}} includes the property, which isn't correctly parsed.
> {code}
> 2016-07-16 12:49:59
> rbellamy@terraspark i ~/Development/test-cd-ci-friendly-versions master % mvn
> -o -DskipTests compile
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] child-1-1
> [INFO] child-1-2
> [INFO] sub-module-1
> [INFO] child-2-1
> [INFO] sub-module-2
> [INFO] test-cd-ci-friendly-versions
> [INFO]
> [INFO]
>
> [INFO] Building child-1-1 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> child-1-1 ---
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child-1-1 ---
> [INFO] Changes detected - recompiling the module!
> [WARNING] File encoding has not been set, using platform encoding UTF-8, i.e.
> build is platform dependent!
> [INFO] Compiling 1 source file to
> /Users/rbellamy/Development/test-cd-ci-friendly-versions/sub-module-1/child-1-1/target/classes
> [INFO]
> [INFO]
>
> [INFO] Building child-1-2 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> child-1-2 ---
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child-1-2 ---
> [INFO] Changes detected - recompiling the module!
> [WARNING] File encoding has not been set, using platform encoding UTF-8, i.e.
> build is platform dependent!
> [INFO] Compiling 1 source file to
> /Users/rbellamy/Development/test-cd-ci-friendly-versions/sub-module-1/child-1-2/target/classes
> [INFO]
> [INFO]
>
> [INFO] Building sub-module-1 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO]
>
> [INFO] Building child-2-1 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> child-2-1 ---
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child-2-1 ---
> [INFO] Changes detected - recompiling the module!
> [WARNING] File encoding has not been set, using platform encoding UTF-8, i.e.
>
[jira] [Commented] (MNG-6066) Continuous Delivery friendly versions break with multi-module projects
[
https://issues.apache.org/jira/browse/MNG-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428589#comment-16428589
]
Jesse Glick commented on MNG-6066:
--
While the automake idiom does serve as a workaround, this nonetheless seems to
be a serious regression in developer usability and local build performance for
multimodule projects compared to traditional version schemes, in which a
submodule could be repeatedly built independently after ensuring that its
parent and all dependencies were installed into the local repository. Doing a
full reactor build of potentially dozens of modules would be impractically slow
for, say, {{mvn -am -pl submodule compile}} after making a one-line change to a
source file in a submodule. Rerunning a test case using {{mvn -am -pl submodule
surefire:test}} is possible only after specifying {{-DfailIfNoTests=false}} to
prevent the build from failing in any of the prior modules lacking a test of
that name, and anyway you would need to {{test-compile}} first if you made any
main or test source changes.
Would Maven developers be open to a mitigation restoring the ability to run
non-reactor submodule builds when CI versions are in use? Since the
{{relativePath}} (default {{..}}) already tells Maven where the parent is, it
seems that it would be possible to locate and parse the parent POM reliably.
> Continuous Delivery friendly versions break with multi-module projects
> --
>
> Key: MNG-6066
> URL: https://issues.apache.org/jira/browse/MNG-6066
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.3.9
>Reporter: G. Richard Bellamy
>Assignee: Karl Heinz Marbaise
>Priority: Major
>
> When I have a multi-module maven project, and one of the sub-modules is a
> mult-module POM itself, the use of a continuous delivery friendly version in
> the parent breaks the build from within either {{sub-module-1}}
> or {{sub-module-2}}.
> Some Maven multi-module project like so:
> {noformat}
> parent
> + sub-module 1
> |+ child 1-1
> ||
> |+ child 1-2
> |
> + sub-module 2
> + child 2-1
> {noformat}
> In the example build below, I've set Maven to offline mode - this happens
> when online as well. Specifically, the problem is that Maven is looking for a
> parent POM with the version set to {{1.${revision\}}}, which is incorrect.
> I believe the problem stems from the fact that the value stored in the
> {{}} includes the property, which isn't correctly parsed.
> {code}
> 2016-07-16 12:49:59
> rbellamy@terraspark i ~/Development/test-cd-ci-friendly-versions master % mvn
> -o -DskipTests compile
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] child-1-1
> [INFO] child-1-2
> [INFO] sub-module-1
> [INFO] child-2-1
> [INFO] sub-module-2
> [INFO] test-cd-ci-friendly-versions
> [INFO]
> [INFO]
>
> [INFO] Building child-1-1 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> child-1-1 ---
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child-1-1 ---
> [INFO] Changes detected - recompiling the module!
> [WARNING] File encoding has not been set, using platform encoding UTF-8, i.e.
> build is platform dependent!
> [INFO] Compiling 1 source file to
> /Users/rbellamy/Development/test-cd-ci-friendly-versions/sub-module-1/child-1-1/target/classes
> [INFO]
> [INFO]
>
> [INFO] Building child-1-2 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> child-1-2 ---
> [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] Copying 0 resource
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ child-1-2 ---
> [INFO] Changes detected - recompiling the module!
> [WARNING] File encoding has not been set, using platform encoding UTF-8, i.e.
> build is platform dependent!
> [INFO] Compiling 1 source file to
> /Users/rbellamy/Development/test-cd-ci-friendly-versions/sub-module-1/child-1-2/target/classes
> [INFO]
> [INFO]
>
> [INFO] Building
[jira] [Commented] (MNG-6303) .mvn/jvm.config should allow to resolve environment variables
[
https://issues.apache.org/jira/browse/MNG-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406102#comment-16406102
]
Jesse Glick commented on MNG-6303:
--
If I understand correctly there is no current or proposed feature to allow a
file under {{.mvn}} to _define_ environment variables, for mojos which need
them in the Maven JVM itself (yes I know this is not great), whereas
{{$HOME/.mavenrc}} does seem to allow this:
{code:sh}
export FOO=bar
{code}
> .mvn/jvm.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
>
> 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
(v7.6.3#76005)
[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=16386743#comment-16386743
]
Jesse Glick commented on MENFORCER-298:
---
It is possible that my patch is also effective against MENFORCER-168 though I
did not check it.
> 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, 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Critical
>
> 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(Maven31DependencyGraphBuilder.java:113)
> 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=16386733#comment-16386733
]
Jesse Glick commented on MENFORCER-298:
---
I suspect the _best_ fix is to use {{maven-dependency-tree 3.0}}, as tracked in
MENFORCER-277.
> 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, 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Critical
>
> 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(Maven31DependencyGraphBuilder.java:113)
> at
>
[jira] [Commented] (MNG-5129) Maven struggles while resolving locked snapshots by two or more simultaneously used projects.
[
https://issues.apache.org/jira/browse/MNG-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386730#comment-16386730
]
Jesse Glick commented on MNG-5129:
--
Sounds similar to MNG-4189.
> Maven struggles while resolving locked snapshots by two or more
> simultaneously used projects.
> -
>
> Key: MNG-5129
> URL: https://issues.apache.org/jira/browse/MNG-5129
> Project: Maven
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.3
>Reporter: Christopher Klewes
>Priority: Blocker
> Attachments: maven-dependency-issue.zip
>
>
> This has to be explained with an easy example. Given that we have three
> projects (A, B and C). Both projects B and C has a dependency to a locked
> snapshot of project A.
> {code:title=Project B requires build number #2}
>
> org.codehaus
> A
> 1.0.0-20110705.132520-2
>
> {code}
> {code:title=Project C requires build number #1}
>
> org.codehaus
> A
> 1.0.0-20110705.132120-1
>
> {code}
> We now call {{dependency:resolve}} on each projects to resolve their
> dependencies from the repositories. As we can see in our local repository
> both versions are fetched and downloaded from their respective repository
> server. Unfortunately a last one wins conflict occurs. The project on which
> {{dependency:resolve}} is called last wins the race. Maven typically copies
> the latest fetched snapshot version (even if it's locked!) to the default
> version. Let's have a look at the folder structure:
> {code:title=Folder listing of the artifact dependency A
> (repository/org/codehaus/A/)}
> maven-metadata-local.xml
> maven-metadata-opensaga.xml
> maven-metadata-opensaga.xml.sha1
> A-1.0.0-20110705.132120-1.jar
> A-1.0.0-20110705.132120-1.pom
> A-1.0.0-20110705.132520-2.jar
> A-1.0.0-20110705.132520-2.pom
>
> A-1.0.0-SNAPSHOT.jar (the last fetched snapshot version)
> A-1.0.0-SNAPSHOT.pom
> {code}
> The last version will be copied to the file {{A-1.0.0-SNAPSHOT.jar}}. Maven
> references their dependencies to the file without the exactt
> timestamp/buildnumber. This fact make it impossible to develop the project B
> and C or even run them simultaneously, because only the last one wins.
> It would be mandatory to exactly reference the file with the timestamp of
> each project!
> What do you think on this issue? I submitted the project structure so you can
> easily reproduce this issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[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=16386727#comment-16386727
]
Jesse Glick commented on MENFORCER-298:
---
Filed PR 32 with a simple proposed fix. If this is rejected, I guess the
Jenkins project can deploy its own version of {{bannedDependencies}} as a
workaround.
> 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, 3.0.0-M1
>Reporter: Jesse Glick
>Priority: Critical
>
> 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(Maven31DependencyGraphBuilder.java:113)
> at
>
[jira] [Created] (MENFORCER-298) bannedDependencies can break compilation against a timestamped snapshot
Jesse Glick created MENFORCER-298:
-
Summary: 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
Reporter: Jesse Glick
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(Maven31DependencyGraphBuilder.java:113)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:91)
at
org.apache.maven.shared.dependency.graph.internal.DefaultDependencyGraphBuilder.buildDependencyGraph(DefaultDependencyGraphBuilder.java:66)
{code}
And passing {{-Daether.artifactResolver.snapshotNormalization=false}} resolves
the issue.
CC [~stephenc] who reviewed this strange misbehavior with me.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-244) Scoping and BannedDependencies
[ https://issues.apache.org/jira/browse/MENFORCER-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386668#comment-16386668 ] Jesse Glick commented on MENFORCER-244: --- I think you [can already do this|https://github.com/jenkinsci/jenkins/commit/a6485510be07ef06639d7b193a9a0d119effc3be]. > Scoping and BannedDependencies > -- > > Key: MENFORCER-244 > URL: https://issues.apache.org/jira/browse/MENFORCER-244 > Project: Maven Enforcer Plugin > Issue Type: Improvement >Reporter: Nick Cross >Priority: Major > > Currently > https://maven.apache.org/enforcer/enforcer-rules/bannedDependencies.html has > an option to ignore transitive dependencies. It would be quite useful to also > have an option to ignore test scoped dependencies. The use-case is that, > while we might care that for a runtime project we don't use certain > dependencies, using them during testing is acceptable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244271#comment-16244271
]
Jesse Glick commented on MNG-6220:
--
I was directed to MNG-6296 which tracks the problem.
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
>Assignee: Robert Scholte
> Fix For: 3.5.2
>
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16244119#comment-16244119
]
Jesse Glick commented on MNG-6220:
--
The usual risks of relying on unit tests: you get what you pay for. :-/
[~rfscholte] can this be reopened? (I have no permissions to do so.)
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
>Assignee: Robert Scholte
> Fix For: 3.5.2
>
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MENFORCER-276) Allow ignoring dependency scopes in RequireUpperBoundDeps
[
https://issues.apache.org/jira/browse/MENFORCER-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240636#comment-16240636
]
Jesse Glick commented on MENFORCER-276:
---
FWIW while I have not looked at this PR, I would probably be opposed to using
it in Jenkins. I consider it a key feature of this enforcer rule that the build
fails if your test-scoped dependencies are inconsistent. We often had cryptic
{{NoSuchMethodError}} mayhem due to simple POM mistakes before adopting the
rule.
> Allow ignoring dependency scopes in RequireUpperBoundDeps
> -
>
> Key: MENFORCER-276
> URL: https://issues.apache.org/jira/browse/MENFORCER-276
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
>Reporter: Oleg Nenashev
>
> We have recently adopted RequireUpperBoundDeps in the Jenkins project
> (https://github.com/jenkinsci/plugin-pom/pull/67). In order to implement it,
> [~jgl...@netbeans.org] added a support of ignoring particular dependencies in
> MENFORCER-273.
> Sometimes we declare dependencies between plugins for testing purposes
> (scope=test), and in such case RequireUpperBoundDeps fails the build if there
> is a test dependency conflicting with the main code. Although it may cause
> instability of tests (including false positive results), it does not really
> impact the distributable package in our case.
> I propose to add another option for filtering of dependency scopes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1433) rerunFailingTestsCount does not help with crashes
[
https://issues.apache.org/jira/browse/SUREFIRE-1433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16215494#comment-16215494
]
Jesse Glick commented on SUREFIRE-1433:
---
Obviously the above is not a real test. I was merely demonstrating that
Surefire is not robust against unforeseeable fatal problems in the test JVM,
making it ill suited to long-running test suites. JUnit itself treats any
{{Throwable}} thrown out of a test method as a “failure” which
{{rerunFailingTestsCount}} will process; yet lower-level errors in a forked
test VM are not recoverable.
> rerunFailingTestsCount does not help with crashes
> -
>
> Key: SUREFIRE-1433
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1433
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.20.1
> Environment: Linux, Java 8u131, Maven 3.5.0
>Reporter: Jesse Glick
> Attachments: demo.zip
>
>
> I have a CI job running lots of very slow tests, and am using
> {{-Dsurefire.rerunFailingTestsCount=2 -Dmaven.test.failure.ignore
> -Dsurefire.timeout=7200 -DreuseForks=false -DforkCount=2}} to run Maven. It
> will typically run for about three hours, collecting a lot of passing tests,
> a few flaking tests with subsequent passes, and a few true failures. But then
> it will abruptly halt with the infamous
> {code:none}
> Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
> project ...: ExecutionException The forked VM terminated without properly
> saying goodbye. VM crash or System.exit called?
> {code}
> The timing is unpredictable but the build seems to usually fail this way;
> sometimes I get lucky and it runs through all the tests, taking a number of
> hours. Diagnosing the crash is not likely to be straightforward, and frankly
> I do not care much—I just want Surefire to try again. Yet the
> {{rerunFailingTestsCount}} flag does not accomplish this—it only retries
> normal failures.
> You can see this from running the attached project. While you might expect it
> to go through 100 runs of the test, some failing politely and some crashing,
> instead you see something like
> {code:none}
> ...
> --- maven-surefire-plugin:2.20.1:test (default-test) @ demo ---
> ---
> T E S T S
> ---
> Running demo.CrashingTest
> failing
> failing
> failing
> crashing
> Results:
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
>
> BUILD FAILURE
>
> Total time: 2.456 s
> Finished at: 2017-10-07T15:11:04-04:00
> Final Memory: 11M/222M
>
> Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on
> project demo: There are test failures.
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SUREFIRE-1433) rerunFailingTestsCount does not help with crashes
Jesse Glick created SUREFIRE-1433:
-
Summary: rerunFailingTestsCount does not help with crashes
Key: SUREFIRE-1433
URL: https://issues.apache.org/jira/browse/SUREFIRE-1433
Project: Maven Surefire
Issue Type: Bug
Components: process forking
Affects Versions: 2.20.1
Environment: Linux, Java 8u131, Maven 3.5.0
Reporter: Jesse Glick
Attachments: demo.zip
I have a CI job running lots of very slow tests, and am using
{{-Dsurefire.rerunFailingTestsCount=2 -Dmaven.test.failure.ignore
-Dsurefire.timeout=7200 -DreuseForks=false -DforkCount=2}} to run Maven. It
will typically run for about three hours, collecting a lot of passing tests, a
few flaking tests with subsequent passes, and a few true failures. But then it
will abruptly halt with the infamous
{code:none}
Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.19.1:test (default-test) on
project ...: ExecutionException The forked VM terminated without properly
saying goodbye. VM crash or System.exit called?
{code}
The timing is unpredictable but the build seems to usually fail this way;
sometimes I get lucky and it runs through all the tests, taking a number of
hours. Diagnosing the crash is not likely to be straightforward, and frankly I
do not care much—I just want Surefire to try again. Yet the
{{rerunFailingTestsCount}} flag does not accomplish this—it only retries normal
failures.
You can see this from running the attached project. While you might expect it
to go through 100 runs of the test, some failing politely and some crashing,
instead you see something like
{code:none}
...
--- maven-surefire-plugin:2.20.1:test (default-test) @ demo ---
---
T E S T S
---
Running demo.CrashingTest
failing
failing
failing
crashing
Results:
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
BUILD FAILURE
Total time: 2.456 s
Finished at: 2017-10-07T15:11:04-04:00
Final Memory: 11M/222M
Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test (default-test) on
project demo: There are test failures.
...
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1226) Surefire trims all stack trace elements except those in the test that failed
[
https://issues.apache.org/jira/browse/SUREFIRE-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16194916#comment-16194916
]
Jesse Glick commented on SUREFIRE-1226:
---
This has nothing to do with Jenkins plugins specifically. I just happened to be
testing a Jenkins plugin when I ran into this bug.
The suggestions for smarter trimming algorithms and for clearer display of
where trimming has occurred are fine for future (3.x) releases, but I would
urge you to change the default for {{trimStackTrace}} to {{false}} right away
(a minor 2.x update).
In 2.18.1- there is a feature with broad benefits—almost everyone will have
tons of meaningless stack trace lines before their test case—and a very limited
downside—only people with rather exotic test runners or custom rules would need
to see details of such wrapping calls in order to troubleshoot test failures.
Thus having the feature be on by default was reasonable.
In 2.19+ there is a feature with slightly broader benefits—almost everyone will
appreciate trimming lots of lines at the bottom, and many test cases could
benefit from trimming a few more at the top—and a massive downside: a
completely routine test failure caused by an exception in code being tested
will result in an impossible-looking stack trace with no hint given to the
programmer that their test code is perfectly fine and it is the test reporting
tool which is to blame, and no easy way to find this out besides bisecting
plugin versions and Googling for a problem with no clear keyword match. So
having such a feature be on by default is quite inappropriate.
> Surefire trims all stack trace elements except those in the test that failed
>
>
> Key: SUREFIRE-1226
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1226
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19
>Reporter: Jiri Locker
>Assignee: Tibor Digana
>Priority: Minor
> Attachments: mvn_stacktrace.tar.gz
>
>
> This looks like a re-occurrence of SUREFIRE-992 but now the stack trace is
> even more trimmed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6274) snapshot timestamps of modules in multimodule build are not aligned
[
https://issues.apache.org/jira/browse/MNG-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138464#comment-16138464
]
Jesse Glick commented on MNG-6274:
--
AFAIK this only applies to {{deploy}} (to a remote repository), not {{install}}
(to the local repository).
> snapshot timestamps of modules in multimodule build are not aligned
> ---
>
> Key: MNG-6274
> URL: https://issues.apache.org/jira/browse/MNG-6274
> Project: Maven
> Issue Type: Improvement
> Components: Artifacts and Repositories, core
>Affects Versions: 3.5.0
>Reporter: James Nord
>
> If you have a multi-module build with SNAPSHOT versions and deploy it to your
> repository all of the modules have different time-stamps.
> This is a pain when you want to refer to many of these snapshots in a
> different project.
> Rather than being able to update a single property to reference the newly
> deployed version you need to make as many changes as the number of the
> dependencies your are using from this project. This is cumbersome and error
> prone.
> It would be much better if all the modules where deployed with the same
> time-stamp if they where part of the same reactor (e.g. the start time of the
> reactor build and not the start time of the module build)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6274) snapshot timestamps of modules in multimodule build are not aligned
[ https://issues.apache.org/jira/browse/MNG-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138437#comment-16138437 ] Jesse Glick commented on MNG-6274: -- [Example question about this|https://stackoverflow.com/q/13589893/12916] > snapshot timestamps of modules in multimodule build are not aligned > --- > > Key: MNG-6274 > URL: https://issues.apache.org/jira/browse/MNG-6274 > Project: Maven > Issue Type: Improvement > Components: Artifacts and Repositories, core >Affects Versions: 3.5.0 >Reporter: James Nord > > If you have a multi-module build with SNAPSHOT versions and either install or > deploy it to your local repository all of the modules have different > time-stamps. > This is a pain when you want to refer to many of these snapshots in a > different project. > Rather than being able to update a single property to reference the newly > deployed version you need to make as many changes as the number of the > dependencies your are using from this project. This is cumbersome and error > prone. > It would be much better if all the modules where deployed with the same > time-stamp if they where part of the same reactor (e.g. the start time of the > reactor build and not the start time of the module build) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MNG-6220) Add CLI options to control color output
[
https://issues.apache.org/jira/browse/MNG-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16050866#comment-16050866
]
Jesse Glick commented on MNG-6220:
--
I was surprised to find that {{TERM=dumb mvn willfail}} still prints ANSI
sequences, contrary to the expectations of Unix users.
> Add CLI options to control color output
> ---
>
> Key: MNG-6220
> URL: https://issues.apache.org/jira/browse/MNG-6220
> Project: Maven
> Issue Type: New Feature
>Reporter: Manuel Ryan
> Fix For: 3.5.1-candidate
>
>
> Currently, the only way to enable/disable color output is to use the
> batch-mode or log-file options.
> If a user wants colored output but no interactivity (ie: jenkins environment
> with the ansicolor plugin), there is no CLI option combination to support the
> use-case.
> I propose to add an option to control output coloring directly.
> {noformat}
> --color=enabled <- color output always enabled
> --color=disabled <- color output always disabled
> --color=auto <- current behavior (default)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MENFORCER-273) RequireUpperBoundDeps.excludes
Jesse Glick created MENFORCER-273:
-
Summary: RequireUpperBoundDeps.excludes
Key: MENFORCER-273
URL: https://issues.apache.org/jira/browse/MENFORCER-273
Project: Maven Enforcer Plugin
Issue Type: New Feature
Components: Standard Rules
Reporter: Jesse Glick
Sometimes it is desirable to run the {{requireUpperBoundDeps}} rule even though
it is known that there will be certain failures, so that the set of failures
can be strictly controlled. Currently there is no option allowing you to do
that. Other dependency-related rules allow you to specify a list of excludes.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MENFORCER-272) Allow site generation to work
Jesse Glick created MENFORCER-272:
-
Summary: Allow site generation to work
Key: MENFORCER-272
URL: https://issues.apache.org/jira/browse/MENFORCER-272
Project: Maven Enforcer Plugin
Issue Type: Task
Components: Documentation
Reporter: Jesse Glick
Priority: Minor
I was unable to get {{mvn site:site}} to run locally, first because of a
{{NullPointerException}}, then because of a Javadoc error. Patch proposed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MENFORCER-272) Allow site generation to work
[
https://issues.apache.org/jira/browse/MENFORCER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Glick updated MENFORCER-272:
--
Flags: Patch
> Allow site generation to work
> -
>
> Key: MENFORCER-272
> URL: https://issues.apache.org/jira/browse/MENFORCER-272
> Project: Maven Enforcer Plugin
> Issue Type: Task
> Components: Documentation
>Reporter: Jesse Glick
>Priority: Minor
>
> I was unable to get {{mvn site:site}} to run locally, first because of a
> {{NullPointerException}}, then because of a Javadoc error. Patch proposed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6223) mvn -f outputs invalid error when specifying POM directory
[
https://issues.apache.org/jira/browse/MNG-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16023504#comment-16023504
]
Jesse Glick commented on MNG-6223:
--
Was a regression of MNG-5338.
> mvn -f outputs invalid error when specifying POM directory
> --
>
> Key: MNG-6223
> URL: https://issues.apache.org/jira/browse/MNG-6223
> Project: Maven
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 3.5.0-alpha-1, 3.5.0
> Environment: Apache Maven 3.5.0
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T15:39:06-04:00)
> Maven home: /Users/cgould/dev/tools/apache-maven-3.5.0
> Java version: 1.8.0_131, vendor: Oracle Corporation
> Java home:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
>Reporter: Charles Gould
>Assignee: Hervé Boutemy
>Priority: Minor
> Fix For: 3.5.1
>
> Attachments: alternate-pom.zip
>
>
> Basic multi-module project: common, client, and server modules.
>
> {noformat}
> $ mvn -f client package
> POM file client specified with the -f/--file command line argument does not
> exist
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building alternate-pom-client 1.0
> [INFO]
>
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> alternate-pom-client ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/cgould/dev/personal/alternate-pom/client/src/main/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @
> alternate-pom-client ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @
> alternate-pom-client ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/cgould/dev/personal/alternate-pom/client/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @
> alternate-pom-client ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @
> alternate-pom-client ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ alternate-pom-client ---
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 0.764 s
> [INFO] Finished at: 2017-04-29T14:03:22-04:00
> [INFO] Final Memory: 11M/309M
> [INFO]
>
> {noformat}
> There is an error message, but the client module proceeds to build
> nonetheless.
> I don't see the error message when I run:
> {noformat}
> $ mvn -f client/pom.xml package
> {noformat}
> I've verified it doesn't happen on 3.3.9, but it does happen on 3.5.0 and
> 3.5.0-alpha-1.
> Sample project attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-4917) Profile not active even though it has activeByDefault set to true
[
https://issues.apache.org/jira/browse/MNG-4917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15888473#comment-15888473
]
Jesse Glick commented on MNG-4917:
--
So {{activeByDefault}} does not mean what you would intuitively think it
means—that the profile is active unless disabled. Rather, it means it is active
only if Maven cannot find some other—probably unrelated—profile to activate.
Basically this mode is useless.
> Profile not active even though it has activeByDefault set to true
> -
>
> Key: MNG-4917
> URL: https://issues.apache.org/jira/browse/MNG-4917
> Project: Maven
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 3.0
>Reporter: Benson Margulies
>Assignee: Benjamin Bentmann
> Attachments: pom.xml
>
>
> I've got a parent pom with a profile with
> true.
> You can retrieve it for yourself via git clone
> git://git.apache.org/webservices-xmlschema.git.
> The problem is the sourcecheck profile in the parent pom.
> running mvn -Psourcecheck works as expected, but running without the -P fails
> to activate the profile.
> the help plugin, I think, has separate problems in this area, or perhaps it's
> not supposed to look at -P?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MNG-3229) Active by default profile is ignored when another is specified explicitly.
[ https://issues.apache.org/jira/browse/MNG-3229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15888466#comment-15888466 ] Jesse Glick commented on MNG-3229: -- Cf. MNG-4917. > Active by default profile is ignored when another is specified explicitly. > --- > > Key: MNG-3229 > URL: https://issues.apache.org/jira/browse/MNG-3229 > Project: Maven > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.7 >Reporter: Oleksandr Maksymchuk > > When default profile is added its used only when there is no another profile > specified to be used on command line via -P option. > So in the pom containig: > > default > > true > > > dev > > default profile is used only when running command without -P dev > mvn > but not used when running: > mvn -P dev > Expected: should be used in both variants as per doc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MPH-99) Evaluate has no output in quiet mode
[
https://issues.apache.org/jira/browse/MPH-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15582278#comment-15582278
]
Jesse Glick commented on MPH-99:
Awkward compared to the original request—a script would be forced to create,
cat, and then delete a temporary file, unlike the Unix convention of using
{{stdout}} and {{stderr}}—but better than nothing.
> Evaluate has no output in quiet mode
>
>
> Key: MPH-99
> URL: https://issues.apache.org/jira/browse/MPH-99
> Project: Maven Help Plugin
> Issue Type: Bug
> Components: evaluate
>Affects Versions: 2.2
>Reporter: Alexandre Garnier
>Assignee: Guillaume Boué
> Fix For: 2.2.1
>
> Attachments: output_on_quiet.patch
>
>
> When using {{help:evaluate}} in normal mode, the evaluation result is lost in
> a lot of Maven {{[INFO\]}} :
> {code:language=bash}
> $ mvn help:evaluate -Dexpression=project.version
> [INFO] Scanning for projects...
> [INFO]
> [INFO]
>
> [INFO] Building myProject 1.0.0
> [INFO]
>
> [INFO]
> [INFO] --- maven-help-plugin:2.2:evaluate (default-cli) @ myProject ---
> [INFO] No artifact parameter specified, using 'com.test:myProject:pom:1.0.0'
> as project.
> [INFO]
> 1.0.0
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.216s
> [INFO] Finished at: Fri Feb 07 10:32:22 CET 2014
> [INFO] Final Memory: 21M/224M
> [INFO]
>
> $
> {code}
> I was hoping that launching Maven in quiet mode would avoid all the logs and
> only display the evaluation result, but there is just no output at all.
> {code:language=bash}
> $ mvn --quiet help:evaluate -Dexpression=project.version
> $
> {code}
> In attachment, a patch to use sysout instead of logging for evaluation output.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MINSTALL-126) localRepositoryPath for install like for install-file
[ https://issues.apache.org/jira/browse/MINSTALL-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15446301#comment-15446301 ] Jesse Glick commented on MINSTALL-126: -- In my case there is no simple list of coördinates I could purge in that fashion, as I work on numerous projects from time to time, and other people do releases in some of them. > localRepositoryPath for install like for install-file > - > > Key: MINSTALL-126 > URL: https://issues.apache.org/jira/browse/MINSTALL-126 > Project: Maven Install Plugin > Issue Type: Improvement >Reporter: Michael Vorburger > > I believe there are real world use cases where to have a localRepositoryPath > available for maven-install-plugin's install goal like it currently is for > the install-file goal would be useful. > http://blog2.vorburger.ch/2016/06/maven-install-into-additional.html is a > Blog post I wrote with some background about why this would be useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MINSTALL-126) localRepositoryPath for install like for install-file
[ https://issues.apache.org/jira/browse/MINSTALL-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15436826#comment-15436826 ] Jesse Glick commented on MINSTALL-126: -- [Use case from StackOverflow|http://stackoverflow.com/q/35451973/12916] > localRepositoryPath for install like for install-file > - > > Key: MINSTALL-126 > URL: https://issues.apache.org/jira/browse/MINSTALL-126 > Project: Maven Install Plugin > Issue Type: Improvement >Reporter: Michael Vorburger > > I believe there are real world use cases where to have a localRepositoryPath > available for maven-install-plugin's install goal like it currently is for > the install-file goal would be useful. > http://blog2.vorburger.ch/2016/06/maven-install-into-additional.html is a > Blog post I wrote with some background about why this would be useful. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1226) Surefire trims all stack trace elements except those in the test that failed
[
https://issues.apache.org/jira/browse/SUREFIRE-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15424904#comment-15424904
]
Jesse Glick commented on SUREFIRE-1226:
---
[~tibor17] I agree with [~jloc...@redhat.com]’s expectation. Was unpleasantly
surprised to update to 2.19.1 (so as to pick up SUREFIRE-1138) and finding test
output like
{code:none}
java.lang.NullPointerException
at
jenkins.plugins.git.AbstractGitSCMSourceTest.fileAt(AbstractGitSCMSourceTest.java:89)
at
jenkins.plugins.git.AbstractGitSCMSourceTest.retrieveRevision(AbstractGitSCMSourceTest.java:76)
{code}
(nonsensical since line 89 of the test could not possibly throw this
exception!) where before I had gotten
{code:none}
java.lang.NullPointerException
at
jenkins.plugins.git.AbstractGitSCMSource.resolveGitTool(AbstractGitSCMSource.java:157)
at
jenkins.plugins.git.AbstractGitSCMSource.retrieve(AbstractGitSCMSource.java:269)
at jenkins.scm.api.SCMSource.retrieve(SCMSource.java:295)
at
jenkins.plugins.git.AbstractGitSCMSource.retrieve(AbstractGitSCMSource.java:358)
at jenkins.scm.api.SCMSource.fetch(SCMSource.java:277)
at
jenkins.plugins.git.AbstractGitSCMSourceTest.fileAt(AbstractGitSCMSourceTest.java:89)
at
jenkins.plugins.git.AbstractGitSCMSourceTest.retrieveRevision(AbstractGitSCMSourceTest.java:76)
{code}
which clearly indicates the problem.
If you are going to trim stack frames inside the test (which I do not advise),
you need to leave *some* clue to users, so they do not have to spend an hour
bisecting and searching bug trackers! For example
{code:none}
java.lang.NullPointerException
…5 stack frames elided, set trimStackTrace=false to display
at
jenkins.plugins.git.AbstractGitSCMSourceTest.fileAt(AbstractGitSCMSourceTest.java:89)
at
jenkins.plugins.git.AbstractGitSCMSourceTest.retrieveRevision(AbstractGitSCMSourceTest.java:76)
{code}
> Surefire trims all stack trace elements except those in the test that failed
>
>
> Key: SUREFIRE-1226
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1226
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19
>Reporter: Jiri Locker
>Assignee: Tibor Digana
>Priority: Minor
> Attachments: mvn_stacktrace.tar.gz
>
>
> This looks like a re-occurrence of SUREFIRE-992 but now the stack trace is
> even more trimmed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5059) --also-make-phase
[
https://issues.apache.org/jira/browse/MNG-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15150699#comment-15150699
]
Jesse Glick commented on MNG-5059:
--
Since it seems unlikely this will ever be worked on as a core feature, I wonder
if the equivalent functionality could be provided somehow from a plugin.
Something like
{code:none}
mvn test-compile something:also-make -Dalso.goals=test
-Dalso.projects=testedmod -Dtest=OneTest
{code}
> --also-make-phase
> -
>
> Key: MNG-5059
> URL: https://issues.apache.org/jira/browse/MNG-5059
> Project: Maven
> Issue Type: Improvement
> Components: Command Line
>Affects Versions: 3.0.3
>Reporter: Jesse Glick
>Assignee: Jason van Zyl
>
> Background:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201104.mbox/%3Cincnbn$4kl$1...@dough.gmane.org%3E
> {{--also-make}} (with {{--projects}}) is useful, but suffers from the problem
> that dependent projects are always built to the same goal/phase as the
> selected project(s). That is fine for e.g. {{compile}} or {{install}}, but
> not for e.g. {{test}} where you would only want to build {{compile}} (or
> {{test-compile}}) for dependencies, not actually test them.
> Suggest a variant form of this parameter (say {{--also-make-phase}} /
> {{-amp}}) which would accept a goal or phase to run on dependencies in place
> of the regular arguments. For example, to run a unit test after making sure
> all its dependencies have been (re-)compiled:
> {noformat}
> mvn -amp test-compile -pl testedmod test -Dtest=OneTest
> {noformat}
> or to run an (unpacked) web application after (re-)compiling libraries it
> uses:
> {noformat}
> mvn -amp compile -pl webapp jetty:run
> {noformat}
> You might want to pass a goal rather than a phase, so the name could be
> misleading, but I think that would be a rarer use case. Ditto passing
> multiple goals/phases for the upstream projects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5604) make it possible to mark a maven module as deprected
[
https://issues.apache.org/jira/browse/MNG-5604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586399#comment-14586399
]
Jesse Glick commented on MNG-5604:
--
Seems to duplicate older MNG-3952 if I am not mistaken.
make it possible to mark a maven module as deprected
Key: MNG-5604
URL: https://issues.apache.org/jira/browse/MNG-5604
Project: Maven
Issue Type: Wish
Components: Artifacts and Repositories
Affects Versions: 3.2.1
Reporter: Klaus Claszen
Priority: Minor
Labels: build, pom.xml
It would be great if it would be possible to mark a maven module as
'deprecated'. It would help to document that a module is outdated. The
information could be used during build processes to show warnings and guide
the user to a better alternative.
Maybe it could be a pom enhancement linke this
{code:xml}
deprecated
reasonnot maintained anymore/reason
instead
groupIdfoo/groupId
artifactIdbar/artifactId
/instead
/deprecated
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (SUREFIRE-1061) wrong test output generation, prevents parsing of generated xml file
[
https://jira.codehaus.org/browse/SUREFIRE-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=352791#comment-352791
]
Jesse Glick commented on SUREFIRE-1061:
---
IMO this is a NetBeans bug, not a Surefire bug; the output is well-formed XML.
wrong test output generation, prevents parsing of generated xml file
Key: SUREFIRE-1061
URL: https://jira.codehaus.org/browse/SUREFIRE-1061
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.16
Reporter: Milos Kleint
Priority: Blocker
Attachments: testcase.zip
please see attached sample project demonstrating the problem. This is a
regression introduced in 2.16, likely by SUREFIRE-1020. originally reported
at https://netbeans.org/bugzilla/show_bug.cgi?id=241649
when the test contains the following code
{code:java}
@Test
public void testMain() {
System.out.println(blabla ]]);
assertTrue(false);
}
{code}
I get following output with these surefire versions (if below not readable,
it's included with the sample project):
{noformat}
2.16 system-out![CDATA[blabla ![CDATA[
]]/system-out
2.15 system-outblabla ]]gt;
/system-out
2.14 system-outblabla ]]
/system-out
2.13 system-outblabla ]]gt;
/system-out
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRELEASE-271) perform goal sometimes fails with multi-module projects
[
https://jira.codehaus.org/browse/MRELEASE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348274#comment-348274
]
Jesse Glick commented on MRELEASE-271:
--
Maven 3.1.0 still seems to be affected. Just have a multimodule project where
the parent POM and all modules share the same version (and depend on one
another using {{$\{project.version}}}), using {{maven-release-plugin 2.5}}.
Unless I specify {{preparationGoalsclean install/preparationGoals}} the
build fails in {{release:prepare}} on the second module, since it had only run
the {{verify}} goal on the first module and so it tried to download the release
version of the first module from the remote repository which of course failed.
Possibly this is because I am using {{packaginghpi/packaging}} (Jenkins
plugins) and so it could not find the first module?s final build product in the
reactor.
perform goal sometimes fails with multi-module projects
---
Key: MRELEASE-271
URL: https://jira.codehaus.org/browse/MRELEASE-271
Project: Maven Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0-beta-4, 2.0-beta-6
Environment: XP
Reporter: David Hoffer
Attachments: MavenReleaseFailure.zip, release.zip,
SuccessfulReleaseBuild.txt
We have a multi-module maven project that has recently started failing in the
release:perform goal.
We have just added a couple more modules but do not know if that is the cause
of the failure. It seems that the release:perform fails to compile the
source after the SCM tag and checkout. The failure says that it cannot find
a dependent jar but it is that jar that it is supposed to be building and
releasing! I updated to use the latest 2.0-beta-6 release plugin version but
this did not help.
Upon receiving feedback in the maven users group that others have seen this
behavior I followed their advise and added configuration
preparationGoalsclean install/preparationGoals/configuration to my
parent pom which did fix the problem.
Why is the release goal failing now? When do I and when do I not need these
changes to my pom? I will attach pom and build logs in hopes this can be
fixed soon, let me know if you need additional information.
-Dave
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-144) Using compiler API instead of tools.jar
[ https://jira.codehaus.org/browse/MCOMPILER-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=344028#comment-344028 ] Jesse Glick commented on MCOMPILER-144: --- I guess so. It would still be great for the OpenJDK compiler to be published in Central somehow, and a ?compiler plugin plugin? implementation published which uses it. Ideally this would be coördinated somehow with the OpenJDK tools team so it is considered an official build, though this might get into thorny TCK territory. Using compiler API instead of tools.jar --- Key: MCOMPILER-144 URL: https://jira.codehaus.org/browse/MCOMPILER-144 Project: Maven Compiler Plugin Issue Type: New Feature Reporter: Markus KARG Priority: Minor Currently (MVN 3.0) java compilation needs tools.jar provided by the Sun JDK: [ERROR] Unable to locate the Javac Compiler in: [ERROR] C:\Program Files\Java\jre6\..\lib\tools.jar [ERROR] Please ensure you are using JDK 1.4 or above and [ERROR] not a JRE (the com.sun.tools.javac.Main class is required). [ERROR] In most cases you can change the location of your Java [ERROR] installation by setting the JAVA_HOME environment variable. In fact, this is bad because (a) it assumes that a full JDK is installed just for this sole tool where a JRE would be sufficient, (b) tools.jar is not contained in any standards documents and such possibly is not existing on future or non-sun JDK. Since JRE 6 (i. e. for many years) the JRE (not JDK!) comes with a standardized (!) API for compilation: The Java Compiler API. It would make sense to use that standardized API instead of forcing the user to have Sun JDK installed. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1067) Nested causes conflated with wrapper exception
Jesse Glick created SUREFIRE-1067:
-
Summary: Nested causes conflated with wrapper exception
Key: SUREFIRE-1067
URL: https://jira.codehaus.org/browse/SUREFIRE-1067
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.13
Environment: JDK 7u51 on Linux
Reporter: Jesse Glick
Priority: Critical
I created a simple Maven project containing just a test
{code}
package p;
import java.io.IOException;
import org.junit.Test;
public class SomeTest {
@Test public void t() throws Exception {
try {
m();
} catch (RuntimeException x) {
throw new IOException(x);
}
}
private void m() {
throw new UnsupportedOperationException();
}
}
{code}
If I run this using {{maven-surefire-plugin}} 2.12.4, I get a
{{p.SomeTest.txt}} with the expected output:
{code:none}
---
Test set: p.SomeTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.037 sec
FAILURE!
t(p.SomeTest) Time elapsed: 0.009 sec ERROR!
java.io.IOException: java.lang.UnsupportedOperationException
at p.SomeTest.t(SomeTest.java:9)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.UnsupportedOperationException
at p.SomeTest.m(SomeTest.java:13)
at p.SomeTest.t(SomeTest.java:7)
... 29 more
{code}
But if I use 2.13 or higher, I get
{code:none}
---
Test set: p.SomeTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.037 sec
FAILURE!
t(p.SomeTest) Time elapsed: 0.009 sec ERROR!
java.io.IOException: java.lang.UnsupportedOperationException
at p.SomeTest.m(SomeTest.java:13)
at p.SomeTest.t(SomeTest.java:7)
{code}
which is missing the potentially crucial information about what threw the
{{IOException}} and why. (Or if the wrapper exception does not follow the
convention of appending {{: + cause}} to its own {{message}}, the Surefire
output would lack any information about the detail message in the original
exception.)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-4838) Permament move (error 301) not handled properly by Maven
[ https://jira.codehaus.org/browse/MNG-4838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=331033#comment-331033 ] Jesse Glick commented on MNG-4838: -- Seems like Wagon 2.0 with this fix was first introduced in Maven 3.1.0, meaning this should now be considered fixed (and ought to have been included in the 3.1.0 release notes); am I wrong? Permament move (error 301) not handled properly by Maven Key: MNG-4838 URL: https://jira.codehaus.org/browse/MNG-4838 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.11, 2.2.1, 3.0-beta-3 Reporter: Grzegorz Slowikowski Priority: Minor Fix For: 3.x / Backlog Artifact cannot be downloaded by http-lightweight-wagon used (as default) in all Maven versions except 2.2.0, which uses http-wagon by default. Instead of pom and jar files html files appear in the local repo with content like: !DOCTYPE HTML PUBLIC -//IETF//DTD HTML 2.0//EN htmlhead title301 Moved Permanently/title /headbody h1Moved Permanently/h1 pThe document has moved a href=http://download.java.net/maven/2/org/codehaus/castor/castor-xml-schema/1.2/castor-xml-schema-1.2.pom;here/a./p hr addressApache Server at maven2-repository.dev.java.net Port 443/address /body/html Only Maven 2.2.0 handles 301 properly. By the way, I haven't expected such Apache configuration (permament move) in central Maven repo. As you can see this is not handled properly by almost all versions of Maven. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1022) system-out malformed XML
Jesse Glick created SUREFIRE-1022:
-
Summary: system-out malformed XML
Key: SUREFIRE-1022
URL: https://jira.codehaus.org/browse/SUREFIRE-1022
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.15
Reporter: Jesse Glick
Priority: Critical
https://jenkins.ci.cloudbees.com/job/core/job/jenkins_main_trunk/ws/test/target/surefire-reports/TEST-hudson.tasks.EnvVarsInConfigTasksTest.xml
as of build #1082 was malformed:
{code:xml}
system-out=== Starting EnvVarsInConfigTasksTest.testNativeMavenOnSlave
#1 completed
Legacy code started this job. No cause information is available
Building remotely on
amp#;[8mha:nB+LCP9b85aBtbiIQTGjNKU4P08vOT+vOD8nVc83PyU1x6OyILUoJzMv2y+/JJUBAhiZGBgqihhk0NSjKDWzXb3RdlLBUSYGJk8GtpzUvPSSDB8G5tKinBIGIZ+sxLJE/ZzEvHT94JKizLx0a6BxUmjGOUNodHsLgAy2EgYB/eT83ILSktQi/eKcxLJUQwA49mDyxQ==amp#;[0mslave1
in workspace
/scratch/jenkins/workspace/core/jenkins_main_trunk/test/target/hudson8856170059407332280test/workspace/test0
Deleting existing workspace
/scratch/jenkins/workspace/core/jenkins_main_trunk/test/target/hudson8856170059407332280test/workspace/test0
Staging
file:/scratch/jenkins/workspace/core/jenkins_main_trunk/test/target/classes/simple-projects.zip
ERROR: Maven Home
/scratch/jenkins/workspace/core/jenkins_main_trunk/test/target/apache-maven-2.2.1${TOOLS_DUMMY_LOCATION}
doesn't exist
amp#;[8mha:WB+LCP9b85aBtbiIQSmjNKU4P08vOT+vOD8nVc8DzHWtSE4tKMnMz/PLL0ldFVf2c+b/lb5MDAwVRQxSaBqcITRIIQMEMIIUFgAAckCEiWA=amp#;[0mFinished:
FAILURE
#2 completed
/system-out
{code}
Here the original stdout contains ANSI escapes. It seems
{{StatelessXmlReporter.escapeXml}} is inserting the {{amp#;}} for reasons
relating to SUREFIRE-456. Whatever the intent was ({{\#27;}}?), it is clearly
not working.
Cf.: https://issues.jenkins-ci.org/browse/JENKINS-19186
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5497) maven-metadata.xml checked if dependency expressed snapshot range even if actual version is fixed
Jesse Glick created MNG-5497:
Summary: maven-metadata.xml checked if dependency expressed
snapshot range even if actual version is fixed
Key: MNG-5497
URL: https://jira.codehaus.org/browse/MNG-5497
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.1.0, 3.0.5, 2.2.1
Environment: Ubuntu, JDK 7
Reporter: Jesse Glick
Priority: Minor
Consider
{code:xml}
project xmlns=http://maven.apache.org/POM/4.0.0;
modelVersion4.0.0/modelVersion
groupIdtest/groupId
artifactIdtest/artifactId
version1.0-SNAPSHOT/version
dependencies
!--
dependency
artifactIdjffi/artifactId
groupIdcom.github.jnr/groupId
version1.2.7/version
/dependency
dependency
artifactIdjnr-x86asm/artifactId
groupIdcom.github.jnr/groupId
version1.0.2/version
/dependency
--
dependency
groupIdcom.github.jnr/groupId
artifactIdjnr-ffi/artifactId
version1.0.4/version
/dependency
/dependencies
/project
{code}
i.e. a project with a dependency on {{jnr-ffi 1.0.4}}. Building this with
{{--update-snapshots}} checks the remote repositories for newer versions of
transitive dependencies:
{code:none}
...
[INFO]
[INFO] Building test 1.0-SNAPSHOT
[INFO]
Downloading:
http://repo.maven.apache.org/maven2/com/github/jnr/jffi/maven-metadata.xml
Downloading:
https://oss.sonatype.org/content/repositories/snapshots/com/github/jnr/jffi/maven-metadata.xml
Downloaded:
http://repo.maven.apache.org/maven2/com/github/jnr/jffi/maven-metadata.xml (605
B at 1.9 KB/sec)
Downloaded:
https://oss.sonatype.org/content/repositories/snapshots/com/github/jnr/jffi/maven-metadata.xml
(361 B at 0.4 KB/sec)
Downloading:
http://repo.maven.apache.org/maven2/com/github/jnr/jnr-x86asm/maven-metadata.xml
Downloading:
https://oss.sonatype.org/content/repositories/snapshots/com/github/jnr/jnr-x86asm/maven-metadata.xml
Downloaded:
http://repo.maven.apache.org/maven2/com/github/jnr/jnr-x86asm/maven-metadata.xml
(362 B at 3.9 KB/sec)
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ test ---
...
{code}
which makes sense since the dependency uses version ranges for the transitive
dependencies:
{code:xml}
...
dependency
groupIdcom.github.jnr/groupId
artifactIdjffi/artifactId
version[1.2.1, 1.3.0)/version
scopecompile/scope
/dependency
dependency
groupIdcom.github.jnr/groupId
artifactIdjffi/artifactId
version[1.2.1, 1.3.0)/version
scoperuntime/scope
classifiernative/classifier
/dependency
...
dependency
groupIdcom.github.jnr/groupId
artifactIdjnr-x86asm/artifactId
version[1.0.2,)/version
scopecompile/scope
/dependency
...
{code}
Now suppose you want your own project to use definite versions of the
transitive dependencies. Uncomment the lines in the original POM to do that (as
per {{dependency:tree}}). Yet when building this, Maven _still_ checks the
remote repositories even though the result cannot matter!
Same in Maven 2:
{code:none}
...
[INFO] artifact com.github.jnr:jffi: checking for updates from central
[INFO] artifact com.github.jnr:jnr-x86asm: checking for updates from central
...
{code}
This is annoying as even without {{-U}} a network connection is made once per
day or so when building your project. Affects {{jenkins-core}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-829) junit | Support inheritance while running test cases belonging to a particular category/group
[
https://jira.codehaus.org/browse/SUREFIRE-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=326485#comment-326485
]
Jesse Glick commented on SUREFIRE-829:
--
Seems wrong to me. If the authors of {{Category}} had intended it to be
inherited, they would have marked it {{@Inherited}}. If they simply never
thought of this use case but agree that it should work, then a new JUnit
release should add the annotation. In neither case should Surefire be patched.
junit | Support inheritance while running test cases belonging to a
particular category/group
-
Key: SUREFIRE-829
URL: https://jira.codehaus.org/browse/SUREFIRE-829
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support
Affects Versions: 2.12
Reporter: Gayathri Muralidharan
Assignee: Andreas Gudian
Fix For: 2.15
Attachments: SUREFIRE-829-common-junit48-20130506.patch,
SUREFIRE-829-common-junit48-new.patch, SUREFIRE-829-common-junit48.patch
We have a parent class which is extended by all the unit test cases (multi
module maven based project)
It would be great if surefire plugin config looks for the category in parent
class as well. This will avoid redundant @Category(UnitTestCategory.class)
annotations, as we expect all unit test cases to extend the corresponding
base class and the base class will alone be annotated with
@Category(UnitTestCategory.class)
Please let me know if this can be achieved by any other config.
Thanks,
Gayathri
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-147) Failure to shade without explanation when signature is invalid
Jesse Glick created MSHADE-147:
--
Summary: Failure to shade without explanation when signature is
invalid
Key: MSHADE-147
URL: https://jira.codehaus.org/browse/MSHADE-147
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 2.0
Environment: JDK 7u21, Linux, Maven 3.0.5
Reporter: Jesse Glick
Priority: Minor
Attachments: stuff.zip
If there is a signature error in a shaded dependency, you can get a build error
like this:
{code:none}
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-shade-plugin:2.0:shade (shade) on project stuff:
Error creating shaded jar: Invalid signature file digest for Manifest main
attributes
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at
org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:100)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:66)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error creating
shaded jar: Invalid signature file digest for Manifest main attributes
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:551)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 27 more
Caused by: java.lang.SecurityException: Invalid signature file digest for
Manifest main attributes
at
sun.security.util.SignatureFileVerifier.processImpl(SignatureFileVerifier.java:240)
at
sun.security.util.SignatureFileVerifier.process(SignatureFileVerifier.java:193)
at java.util.jar.JarVerifier.processEntry(JarVerifier.java:305)
at java.util.jar.JarVerifier.update(JarVerifier.java:216)
at java.util.jar.JarFile.initializeVerifier(JarFile.java:345)
at java.util.jar.JarFile.getInputStream(JarFile.java:412)
at
org.apache.maven.plugins.shade.DefaultShader.shade(DefaultShader.java:134)
at
org.apache.maven.plugins.shade.mojo.ShadeMojo.execute(ShadeMojo.java:484)
... 29 more
{code}
Apparently {{DefaultShader}} is using the {{JarFile}} constructor that enables
signature verification. That may be correct, but if so it should catch
{{SecurityException}} and report the problem more nicely, say with the name of
the bad dependency, and perhaps with instructions on how to configure the
plugin to ignore this dependency or override the signature check.
Attaching my test project, though I cannot consistently reproduce the problem
with this. (Seems to file from inside Jenkins but not outside; not yet sure
what the difference would be.)
MSHADE-90 is a bit
[jira] (MNG-5075) MavenProject.getParent throws undocumented ISE
[
https://jira.codehaus.org/browse/MNG-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=324402#comment-324402
]
Jesse Glick commented on MNG-5075:
--
[JENKINS-17775|https://issues.jenkins-ci.org/browse/JENKINS-17775] is another
victim.
MavenProject.getParent throws undocumented ISE
--
Key: MNG-5075
URL: https://jira.codehaus.org/browse/MNG-5075
Project: Maven 2 3
Issue Type: Bug
Components: Embedding
Affects Versions: 3.0.3
Reporter: Jesse Glick
Fix For: 3.1.x
Attachments: MavenProject-getParent-ISE.diff
http://bugzilla-attachments-197994.netbeans.org/bugzilla/attachment.cgi?id=107899
shows a stack trace encountered when calling {{MavenProject.getParent}} on a
project with some errors (probably POMs missing in the local repository).
This method has no Javadoc comment, so it is hard to know exactly what it is
permitted/supposed to do, but {{hasParent}} implies that {{null}} is a valid
return value, and there is no {{throws IllegalStateException}} clause. The
attached patch brings the behavior in line with that signature. (I think I
got the {{PlexusTestCase}} infrastructure working with all the required
wiring but it may be possible to simplify the test case.)
Cleaner might be to just declare {{getParent}} (and also {{hasParent}}?) to
throw {{ProjectBuildingException}}, though this would be a
source-incompatible change. (Only binary-incompatible for clients which are
already catching {{IllegalStateException}}!)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5075) MavenProject.getParent throws undocumented ISE
[
https://jira.codehaus.org/browse/MNG-5075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=324403#comment-324403
]
Jesse Glick commented on MNG-5075:
--
Pull request: https://github.com/apache/maven/pull/8
MavenProject.getParent throws undocumented ISE
--
Key: MNG-5075
URL: https://jira.codehaus.org/browse/MNG-5075
Project: Maven 2 3
Issue Type: Bug
Components: Embedding
Affects Versions: 3.0.3
Reporter: Jesse Glick
Fix For: 3.1.x
Attachments: MavenProject-getParent-ISE.diff
http://bugzilla-attachments-197994.netbeans.org/bugzilla/attachment.cgi?id=107899
shows a stack trace encountered when calling {{MavenProject.getParent}} on a
project with some errors (probably POMs missing in the local repository).
This method has no Javadoc comment, so it is hard to know exactly what it is
permitted/supposed to do, but {{hasParent}} implies that {{null}} is a valid
return value, and there is no {{throws IllegalStateException}} clause. The
attached patch brings the behavior in line with that signature. (I think I
got the {{PlexusTestCase}} infrastructure working with all the required
wiring but it may be possible to simplify the test case.)
Cleaner might be to just declare {{getParent}} (and also {{hasParent}}?) to
throw {{ProjectBuildingException}}, though this would be a
source-incompatible change. (Only binary-incompatible for clients which are
already catching {{IllegalStateException}}!)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-974) Custom junit.framework.TestSuite subtypes ignored when excludedGroups defined
[
https://jira.codehaus.org/browse/SUREFIRE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=323380#comment-323380
]
Jesse Glick commented on SUREFIRE-974:
--
I filed SUREFIRE-984 to track the reporting format.
Custom junit.framework.TestSuite subtypes ignored when excludedGroups defined
-
Key: SUREFIRE-974
URL: https://jira.codehaus.org/browse/SUREFIRE-974
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.14
Reporter: Jesse Glick
Assignee: Andreas Gudian
Attachments: SUREFIRE-974.zip
In Jenkins sources @ 919bab8, run:
{{mvn -f test/pom.xml -Dtest=CoreJellyTest
-Dtest.excluded.groups=org.jvnet.hudson.test.FailsOnCloud test}}
You will get errors from every test case in this suite. When
{{test.excluded.groups}} is not defined, it passes.
This property just sets {{excludedGroups}} for the benefit of some unrelated
JUnit 4 tests in the same module which use {{@Category}}. But turning it on
apparently changes how JUnit 3 tests are run, too. The named suite has a
{{public static Test suite()}} method which creates a subclass of
{{TestSuite}} that overrides {{void run(TestResult)}}; when
{{excludedGroups}} is defined, a plain {{TestSuite}} is created which fails
to set the proper context for test cases and fails utterly.
Refactoring this test suite to use JUnit 4 idioms is probably not an option
at the moment for compatibility reasons. Why is Surefire failing to correctly
run JUnit 3 tests just because groups are defined?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-984) Different reporting format for 3.x custom suites when JUnit 4.7 provider enabled
Jesse Glick created SUREFIRE-984:
Summary: Different reporting format for 3.x custom suites when
JUnit 4.7 provider enabled
Key: SUREFIRE-984
URL: https://jira.codehaus.org/browse/SUREFIRE-984
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.7+ (parallel) support
Environment: JDK 7u17, Ubuntu. git://github.com/jenkinsci/jenkins.git
@94f781c
Reporter: Jesse Glick
Priority: Minor
In Jenkins sources, prepare with e.g. {{mvn -am -pl test -DskipTests install}}
then run
{code:none}
mvn -f test/pom.xml -Dtest=CoreJellyTest clean test
{code}
You will see these files in {{test/target/surefire-reports}}:
{code:none}
CoreJellyTest-output.txt
CoreJellyTest.txt
TEST-CoreJellyTest.xml
{code}
as expected. Now run:
{code:none}
mvn -f test/pom.xml -Dtest=CoreJellyTest -DexcludedGroups=hudson.ExtensionPoint
clean test
{code}
(This exclusion does not change what tests are run, only which Surefire
provider is used to run them.) You will see:
{code:none}
null-output.txt
org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyCheck-output.txt
org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyCheck.txt
org.jvnet.hudson.test.junit.FailedTest.txt
TEST-org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyCheck.xml
TEST-org.jvnet.hudson.test.junit.FailedTest.xml
{code}
As mentioned at the end of SUREFIRE-974, normally {{TEST-*.xml}} is named
according to the class defining the {{suite}} method, with {{classname}}
specifying the class extending {{TestSuite}}. But with {{excludedGroups}} the
result file is named according to the suite class ({{classname}} also
specifying this), and there is no indication anywhere of the name of the class
defining {{suite}}.
Tried to build 2.15-SNAPSHOT from sources to check behavior there, but failed
with
{code:none}
Could not resolve dependencies for project
org.apache.maven.surefire:surefire-api:jar:2.15-SNAPSHOT: Could not find
artifact org.apache.maven.shared:maven-shared-utils:jar:0.4
{code}
maybe related to mirror config.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-984) Different reporting format for 3.x custom suites when JUnit 4.7 provider enabled
[
https://jira.codehaus.org/browse/SUREFIRE-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=323381#comment-323381
]
Jesse Glick commented on SUREFIRE-984:
--
By the way, the relevant sources are:
*
[CoreJellyTest.java|https://github.com/jenkinsci/jenkins/blob/master/test/src/test/java/CoreJellyTest.java]
*
[JellyTestSuiteBuilder.java|https://github.com/jenkinsci/jenkins/blob/master/test/src/main/java/org/jvnet/hudson/test/JellyTestSuiteBuilder.java]
*
[GroupedTest.java|https://github.com/jenkinsci/jenkins/blob/master/test/src/main/java/org/jvnet/hudson/test/junit/GroupedTest.java]
*
[FailedTest.java|https://github.com/jenkinsci/jenkins/blob/master/test/src/main/java/org/jvnet/hudson/test/junit/FailedTest.java]
Different reporting format for 3.x custom suites when JUnit 4.7 provider
enabled
Key: SUREFIRE-984
URL: https://jira.codehaus.org/browse/SUREFIRE-984
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.7+ (parallel) support
Environment: JDK 7u17, Ubuntu. git://github.com/jenkinsci/jenkins.git
@94f781c
Reporter: Jesse Glick
Priority: Minor
In Jenkins sources, prepare with e.g. {{mvn -am -pl test -DskipTests
install}} then run
{code:none}
mvn -f test/pom.xml -Dtest=CoreJellyTest clean test
{code}
You will see these files in {{test/target/surefire-reports}}:
{code:none}
CoreJellyTest-output.txt
CoreJellyTest.txt
TEST-CoreJellyTest.xml
{code}
as expected. Now run:
{code:none}
mvn -f test/pom.xml -Dtest=CoreJellyTest
-DexcludedGroups=hudson.ExtensionPoint clean test
{code}
(This exclusion does not change what tests are run, only which Surefire
provider is used to run them.) You will see:
{code:none}
null-output.txt
org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyCheck-output.txt
org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyCheck.txt
org.jvnet.hudson.test.junit.FailedTest.txt
TEST-org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyCheck.xml
TEST-org.jvnet.hudson.test.junit.FailedTest.xml
{code}
As mentioned at the end of SUREFIRE-974, normally {{TEST-*.xml}} is named
according to the class defining the {{suite}} method, with {{classname}}
specifying the class extending {{TestSuite}}. But with {{excludedGroups}} the
result file is named according to the suite class ({{classname}} also
specifying this), and there is no indication anywhere of the name of the
class defining {{suite}}.
Tried to build 2.15-SNAPSHOT from sources to check behavior there, but failed
with
{code:none}
Could not resolve dependencies for project
org.apache.maven.surefire:surefire-api:jar:2.15-SNAPSHOT: Could not find
artifact org.apache.maven.shared:maven-shared-utils:jar:0.4
{code}
maybe related to mirror config.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-984) Different reporting format for 3.x custom suites when JUnit 4.7 provider enabled
[
https://jira.codehaus.org/browse/SUREFIRE-984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=323381#comment-323381
]
Jesse Glick edited comment on SUREFIRE-984 at 4/8/13 9:12 AM:
--
By the way, the relevant sources are:
*
[CoreJellyTest.java|https://github.com/jenkinsci/jenkins/blob/master/test/src/test/java/CoreJellyTest.java]
*
[JellyTestSuiteBuilder.java|https://github.com/jenkinsci/jenkins/blob/master/test/src/main/java/org/jvnet/hudson/test/JellyTestSuiteBuilder.java]
*
[GroupedTest.java|https://github.com/jenkinsci/jenkins/blob/master/test/src/main/java/org/jvnet/hudson/test/junit/GroupedTest.java]
*
[FailedTest.java|https://github.com/jenkinsci/jenkins/blob/master/test/src/main/java/org/jvnet/hudson/test/junit/FailedTest.java]
and Jenkins as of the mentioned revision uses Surefire 2.14.
was (Author: jglick):
By the way, the relevant sources are:
*
[CoreJellyTest.java|https://github.com/jenkinsci/jenkins/blob/master/test/src/test/java/CoreJellyTest.java]
*
[JellyTestSuiteBuilder.java|https://github.com/jenkinsci/jenkins/blob/master/test/src/main/java/org/jvnet/hudson/test/JellyTestSuiteBuilder.java]
*
[GroupedTest.java|https://github.com/jenkinsci/jenkins/blob/master/test/src/main/java/org/jvnet/hudson/test/junit/GroupedTest.java]
*
[FailedTest.java|https://github.com/jenkinsci/jenkins/blob/master/test/src/main/java/org/jvnet/hudson/test/junit/FailedTest.java]
Different reporting format for 3.x custom suites when JUnit 4.7 provider
enabled
Key: SUREFIRE-984
URL: https://jira.codehaus.org/browse/SUREFIRE-984
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.7+ (parallel) support
Environment: JDK 7u17, Ubuntu. git://github.com/jenkinsci/jenkins.git
@94f781c
Reporter: Jesse Glick
Priority: Minor
In Jenkins sources, prepare with e.g. {{mvn -am -pl test -DskipTests
install}} then run
{code:none}
mvn -f test/pom.xml -Dtest=CoreJellyTest clean test
{code}
You will see these files in {{test/target/surefire-reports}}:
{code:none}
CoreJellyTest-output.txt
CoreJellyTest.txt
TEST-CoreJellyTest.xml
{code}
as expected. Now run:
{code:none}
mvn -f test/pom.xml -Dtest=CoreJellyTest
-DexcludedGroups=hudson.ExtensionPoint clean test
{code}
(This exclusion does not change what tests are run, only which Surefire
provider is used to run them.) You will see:
{code:none}
null-output.txt
org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyCheck-output.txt
org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyCheck.txt
org.jvnet.hudson.test.junit.FailedTest.txt
TEST-org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyCheck.xml
TEST-org.jvnet.hudson.test.junit.FailedTest.xml
{code}
As mentioned at the end of SUREFIRE-974, normally {{TEST-*.xml}} is named
according to the class defining the {{suite}} method, with {{classname}}
specifying the class extending {{TestSuite}}. But with {{excludedGroups}} the
result file is named according to the suite class ({{classname}} also
specifying this), and there is no indication anywhere of the name of the
class defining {{suite}}.
Tried to build 2.15-SNAPSHOT from sources to check behavior there, but failed
with
{code:none}
Could not resolve dependencies for project
org.apache.maven.surefire:surefire-api:jar:2.15-SNAPSHOT: Could not find
artifact org.apache.maven.shared:maven-shared-utils:jar:0.4
{code}
maybe related to mirror config.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[
https://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=323037#comment-323037
]
Jesse Glick commented on MNG-3092:
--
An example using Maven 3.0.5:
https://github.com/stapler/stapler-adjunct-codemirror/commit/da995b03a1f165fef7c9d34eadb15797f58399cd
shows the workaround for what I take to be this issue. In versions of Jenkins
using stapler-adjunct-codemirror 1.1 prior to this change?and plugins depending
on those versions of Jenkins?at least one build per day spends a chunk of time
(10?20s?) looking for nonexistent SNAPSHOT versions of a transitive dependency.
(Where it gets these version numbers from, I have no idea?the Artifactory
mirror makes no mention of such versions in {{maven-metadata.xml}}, and the
occurrences in my local repo are all freshly created
{{resolver-status.properties}} and {{stapler-1.176-SNAPSHOT.pom.lastUpdated}}
files which list only ?errors? and soon get recreated if I delete them.)
Maven 2.2.1 also downloads 1.208-SNAPSHOT, which _does_ exist, but none of
these intermediate versions.
I have also encountered builds that _failed_ trying to find one of these
nonexistent snapshots, though I cannot now reproduce this problem.
Version ranges with non-snapshot bounds can contain snapshot versions
-
Key: MNG-3092
URL: https://jira.codehaus.org/browse/MNG-3092
Project: Maven 2 3
Issue Type: Bug
Components: Dependencies
Reporter: Mark Hobson
Assignee: Jason van Zyl
Fix For: 3.1.1
Attachments: MNG-3092.patch, MNG-3092.patch
Contrary to the 2.0 design docs:
Resolution of dependency ranges should not resolve to a snapshot
(development version) unless it is included as an explicit boundary.
-- from
http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification
The following is equates to true:
VersionRange.createFromVersionSpec( [1.0,1.1] ).containsVersion( new
DefaultArtifactVersion( 1.1-SNAPSHOT ) )
The attached patch only allows snapshot versions to be contained in a range
if they are equal to one of the boundaries. Note that this is a strict
equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-974) Custom junit.framework.TestSuite subtypes ignored when excludedGroups defined
[
https://jira.codehaus.org/browse/SUREFIRE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Glick closed SUREFIRE-974.
Resolution: Won't Fix
I do not see anything Surefire could do either. I did find a simple workaround,
though: extend {{JUnit4TestAdapter}} rather than {{TestSuite}}. This even works
properly when running single test methods.
Custom junit.framework.TestSuite subtypes ignored when excludedGroups defined
-
Key: SUREFIRE-974
URL: https://jira.codehaus.org/browse/SUREFIRE-974
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.14
Reporter: Jesse Glick
Assignee: Andreas Gudian
Fix For: 2.15
Attachments: SUREFIRE-974.zip
In Jenkins sources @ 919bab8, run:
{{mvn -f test/pom.xml -Dtest=CoreJellyTest
-Dtest.excluded.groups=org.jvnet.hudson.test.FailsOnCloud test}}
You will get errors from every test case in this suite. When
{{test.excluded.groups}} is not defined, it passes.
This property just sets {{excludedGroups}} for the benefit of some unrelated
JUnit 4 tests in the same module which use {{@Category}}. But turning it on
apparently changes how JUnit 3 tests are run, too. The named suite has a
{{public static Test suite()}} method which creates a subclass of
{{TestSuite}} that overrides {{void run(TestResult)}}; when
{{excludedGroups}} is defined, a plain {{TestSuite}} is created which fails
to set the proper context for test cases and fails utterly.
Refactoring this test suite to use JUnit 4 idioms is probably not an option
at the moment for compatibility reasons. Why is Surefire failing to correctly
run JUnit 3 tests just because groups are defined?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-974) Custom junit.framework.TestSuite subtypes ignored when excludedGroups defined
[
https://jira.codehaus.org/browse/SUREFIRE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322817#comment-322817
]
Jesse Glick commented on SUREFIRE-974:
--
The {{JUnit4TestAdapter}} workaround does not work when using
{{TestSuite.init()}} and {{.addTest(Test)}}, however. For that case
implementing {{Filterable}} to do nothing is acceptable since typically the
{{Test suite()}} computed a set of tests to add in a way that would not
intrinsically support filtering to begin with; in my case the test cases do not
correspond to methods.
I do notice some other differences in the result files between test runs using
{{excludedGroups}} and those without. For example, normally {{TEST-*.xml}} is
named according to the class defining the {{suite}} method, with {{classname}}
specifying the class extending {{TestSuite}}. But with {{excludedGroups}} the
result file is named according to the suite class ({{classname}} also
specifying this), and there is no indication anywhere of the name of the class
defining {{suite}}. Not sure if this is fixable on the Surefire side.
Custom junit.framework.TestSuite subtypes ignored when excludedGroups defined
-
Key: SUREFIRE-974
URL: https://jira.codehaus.org/browse/SUREFIRE-974
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.14
Reporter: Jesse Glick
Assignee: Andreas Gudian
Fix For: 2.15
Attachments: SUREFIRE-974.zip
In Jenkins sources @ 919bab8, run:
{{mvn -f test/pom.xml -Dtest=CoreJellyTest
-Dtest.excluded.groups=org.jvnet.hudson.test.FailsOnCloud test}}
You will get errors from every test case in this suite. When
{{test.excluded.groups}} is not defined, it passes.
This property just sets {{excludedGroups}} for the benefit of some unrelated
JUnit 4 tests in the same module which use {{@Category}}. But turning it on
apparently changes how JUnit 3 tests are run, too. The named suite has a
{{public static Test suite()}} method which creates a subclass of
{{TestSuite}} that overrides {{void run(TestResult)}}; when
{{excludedGroups}} is defined, a plain {{TestSuite}} is created which fails
to set the proper context for test cases and fails utterly.
Refactoring this test suite to use JUnit 4 idioms is probably not an option
at the moment for compatibility reasons. Why is Surefire failing to correctly
run JUnit 3 tests just because groups are defined?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-974) Custom junit.framework.TestSuite subtypes ignored when excludedGroups defined
Jesse Glick created SUREFIRE-974:
Summary: Custom junit.framework.TestSuite subtypes ignored when
excludedGroups defined
Key: SUREFIRE-974
URL: https://jira.codehaus.org/browse/SUREFIRE-974
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.14
Reporter: Jesse Glick
In Jenkins sources @ 919bab8, run:
{{mvn -f test/pom.xml -Dtest=CoreJellyTest
-Dtest.excluded.groups=org.jvnet.hudson.test.FailsOnCloud test}}
You will get errors from every test case in this suite. When
{{test.excluded.groups}} is not defined, it passes.
This property just sets {{excludedGroups}} for the benefit of some unrelated
JUnit 4 tests in the same module which use {{@Category}}. But turning it on
apparently changes how JUnit 3 tests are run, too. The named suite has a
{{public static Test suite()}} method which creates a subclass of {{TestSuite}}
that overrides {{void run(TestResult)}}; when {{excludedGroups}} is defined, a
plain {{TestSuite}} is created which fails to set the proper context for test
cases and fails utterly.
Refactoring this test suite to use JUnit 4 idioms is probably not an option at
the moment for compatibility reasons. Why is Surefire failing to correctly run
JUnit 3 tests just because groups are defined?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-974) Custom junit.framework.TestSuite subtypes ignored when excludedGroups defined
[
https://jira.codehaus.org/browse/SUREFIRE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jesse Glick updated SUREFIRE-974:
-
Attachment: SUREFIRE-974.zip
Attaching a demo project. {{mvn test}} works as expected. {{mvn -Pbug test}}
excludes {{Complex4Test.two}} as expected, but also makes {{Complex3Test}}
fails.
Custom junit.framework.TestSuite subtypes ignored when excludedGroups defined
-
Key: SUREFIRE-974
URL: https://jira.codehaus.org/browse/SUREFIRE-974
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.14
Reporter: Jesse Glick
Attachments: SUREFIRE-974.zip
In Jenkins sources @ 919bab8, run:
{{mvn -f test/pom.xml -Dtest=CoreJellyTest
-Dtest.excluded.groups=org.jvnet.hudson.test.FailsOnCloud test}}
You will get errors from every test case in this suite. When
{{test.excluded.groups}} is not defined, it passes.
This property just sets {{excludedGroups}} for the benefit of some unrelated
JUnit 4 tests in the same module which use {{@Category}}. But turning it on
apparently changes how JUnit 3 tests are run, too. The named suite has a
{{public static Test suite()}} method which creates a subclass of
{{TestSuite}} that overrides {{void run(TestResult)}}; when
{{excludedGroups}} is defined, a plain {{TestSuite}} is created which fails
to set the proper context for test cases and fails utterly.
Refactoring this test suite to use JUnit 4 idioms is probably not an option
at the moment for compatibility reasons. Why is Surefire failing to correctly
run JUnit 3 tests just because groups are defined?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-974) Custom junit.framework.TestSuite subtypes ignored when excludedGroups defined
[
https://jira.codehaus.org/browse/SUREFIRE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322102#comment-322102
]
Jesse Glick commented on SUREFIRE-974:
--
If there is a bug in JUnit itself, I cannot find it:
{code}
System.err.println(surefire-junit4);
RunNotifier notifier = new RunNotifier();
notifier.addListener(new TextListener(System.err));
Request.aClass(Complex3Test.class).getRunner().run(notifier);
System.err.println(surefire-junit47);
JUnitCore core = new JUnitCore();
core.addListener(new TextListener(System.err));
System.err.println(failures: + core.run(Request.classes(new Computer(),
Complex3Test.class)).getFailureCount());
{code}
Custom junit.framework.TestSuite subtypes ignored when excludedGroups defined
-
Key: SUREFIRE-974
URL: https://jira.codehaus.org/browse/SUREFIRE-974
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.14
Reporter: Jesse Glick
Attachments: SUREFIRE-974.zip
In Jenkins sources @ 919bab8, run:
{{mvn -f test/pom.xml -Dtest=CoreJellyTest
-Dtest.excluded.groups=org.jvnet.hudson.test.FailsOnCloud test}}
You will get errors from every test case in this suite. When
{{test.excluded.groups}} is not defined, it passes.
This property just sets {{excludedGroups}} for the benefit of some unrelated
JUnit 4 tests in the same module which use {{@Category}}. But turning it on
apparently changes how JUnit 3 tests are run, too. The named suite has a
{{public static Test suite()}} method which creates a subclass of
{{TestSuite}} that overrides {{void run(TestResult)}}; when
{{excludedGroups}} is defined, a plain {{TestSuite}} is created which fails
to set the proper context for test cases and fails utterly.
Refactoring this test suite to use JUnit 4 idioms is probably not an option
at the moment for compatibility reasons. Why is Surefire failing to correctly
run JUnit 3 tests just because groups are defined?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-66) Compiler swallows messages from annotation processors
[
https://jira.codehaus.org/browse/MCOMPILER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321854#comment-321854
]
Jesse Glick commented on MCOMPILER-66:
--
Seems that with the 3.0 version of the plugin, {{Kind.NOTE}} messages are
finally being displayed?but as Maven warnings!
Compiler swallows messages from annotation processors
-
Key: MCOMPILER-66
URL: https://jira.codehaus.org/browse/MCOMPILER-66
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.0.2, 2.1
Reporter: Evan Cowden
Attachments: AnnotationProcessorMessagerBug.zip
When using the annotation processor API to print messages through the
javax.annotation.processing.Messager object, only messagesspecified by levels
javax.tools.Diagnostic.Kind.ERROR and
javax.tools.Diagnostic.Kind.MANDATORY_WARNING are displayed (and cause the
build to fail). All other messages are swallowed.
Note that while the attached JUnit test case is necessary to help expose the
problem, passing it will not imply that the bug is fixed. The only way to
confirm the fix (that I know of) is to examine console output.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-751) Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/
[ https://jira.codehaus.org/browse/SUREFIRE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321675#comment-321675 ] Jesse Glick commented on SUREFIRE-751: -- @agudian: any progress on your examples page? Struggling the digest the implications of SUREFIRE-949. Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/ -- Key: SUREFIRE-751 URL: https://jira.codehaus.org/browse/SUREFIRE-751 Project: Maven Surefire Issue Type: New Feature Components: process forking Affects Versions: 2.9 Reporter: Stephen Connolly Assignee: Kristian Rosenvold Fix For: 2.13 Attachments: SUREFIRE-751-part1.patch, SUREFIRE-751-part2.patch The current parallel execution spawns one thread _per_class_ When there is a large disparity between the number of tests in different classes, this can result in a longer execution time. This can often happen in GUI testing, where a couple of classes will contain a lot of long running (but low cpu) test cases, and the remaining classes run fast. See http://maven-junit-plugin.kenai.com/ for an attempt at solving this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-968) Test summary line does not indicate what was being run when using concurrency
Jesse Glick created SUREFIRE-968:
Summary: Test summary line does not indicate what was being run
when using concurrency
Key: SUREFIRE-968
URL: https://jira.codehaus.org/browse/SUREFIRE-968
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.14
Environment: Ubuntu, JDK 7
Reporter: Jesse Glick
Priority: Minor
When running multiple test suites in parallel, Surefire prints summaries of
ongoing test counts, but it is not at all clear which results are being
summarized. E.g. with {{forkCount=1C}}:
{code:none}
Running CoreJellyTest
Running org.jvnet.hudson.main.AppTest
Running org.jvnet.hudson.main.UseRecipesWithJenkinsRuleTest
Running org.jvnet.hudson.test.MemoryAssertTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
Running org.jvnet.hudson.test.MockFolderTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.719 sec
Running hudson.bugs.DateConversionTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.867 sec
Running hudson.bugs.LoginRedirectTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 21.208 sec
Running hudson.bugs.JnlpAccessWithSecuredHudsonTest
Tests run: 538, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.847 sec
â¦
{code}
It is impossible to tell which results correspond to which test, since there is
no way to know which test will finish first. At best you can guess based on the
number of test case methods known to be in each class.
The {{Tests run}} summary line should give the suite name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-751) Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/
[ https://jira.codehaus.org/browse/SUREFIRE-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321682#comment-321682 ] Jesse Glick commented on SUREFIRE-751: -- Thanks, this makes it much clearer. Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/ -- Key: SUREFIRE-751 URL: https://jira.codehaus.org/browse/SUREFIRE-751 Project: Maven Surefire Issue Type: New Feature Components: process forking Affects Versions: 2.9 Reporter: Stephen Connolly Assignee: Kristian Rosenvold Fix For: 2.13 Attachments: SUREFIRE-751-part1.patch, SUREFIRE-751-part2.patch The current parallel execution spawns one thread _per_class_ When there is a large disparity between the number of tests in different classes, this can result in a longer execution time. This can often happen in GUI testing, where a couple of classes will contain a lot of long running (but low cpu) test cases, and the remaining classes run fast. See http://maven-junit-plugin.kenai.com/ for an attempt at solving this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-392) Maven 3.0.5 regression in release:perform: Host name may not be null
[
https://jira.codehaus.org/browse/WAGON-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321363#comment-321363
]
Jesse Glick commented on WAGON-392:
---
Some research e.g. in http://www.ietf.org/rfc/rfc2396.txt shows that underscore
({{_}}) is in fact not a valid character in host names. ({{URI.getAuthority}}
returns the host name but {{getHost}} correctly refuses to interpret it.) So
the deployment repository is in fact invalid, and the wagon just needs to emit
a more helpful error message. Can downgrade the priority here.
Maven 3.0.5 regression in release:perform: Host name may not be null
--
Key: WAGON-392
URL: https://jira.codehaus.org/browse/WAGON-392
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Environment: Ubuntu 12.04 32-bit, JDK 7u15
Reporter: Jesse Glick
Priority: Blocker
Attachments: ssl.png
With Maven 3.0.4 deploying to our Artifactory server from {{release:perform}}
works fine:
{code:none}
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ ... ---
Uploading: https://artifactoryonline.com/.../releases/.../8/...-8.pom
Uploaded: https://artifactoryonline.com/.../releases/.../8/...-8.pom (16
KB at 11.1 KB/sec)
{code}
But the same command in Maven 3.0.5 fails:
{code:none}
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ ... ---
Uploading: https://artifactoryonline.com/.../releases/.../8/...-8.pom
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] ...
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project ...: Failed to deploy artifacts: Could not transfer artifact
...:...:pom:8 from/to ... (https://artifactoryonline.com/.../releases):
Host name may not be null - [Help 1]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-392) Maven 3.0.5 regression in release:perform: Host name may not be null
[
https://jira.codehaus.org/browse/WAGON-392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321366#comment-321366
]
Jesse Glick commented on WAGON-392:
---
The problem is with the host name {{ACCOUNTNAME_jfrog.artifactoryonline.com}}.
JFrog also seems to accept {{ACCOUNTNAME-jfrog.artifactoryonline.com}} which is
a legitimate hostname that Maven 3.0.5 can deploy to.
Maven 3.0.5 regression in release:perform: Host name may not be null
--
Key: WAGON-392
URL: https://jira.codehaus.org/browse/WAGON-392
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http
Environment: Ubuntu 12.04 32-bit, JDK 7u15
Reporter: Jesse Glick
Attachments: ssl.png
With Maven 3.0.4 deploying to our Artifactory server from {{release:perform}}
works fine:
{code:none}
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ ... ---
Uploading: https://artifactoryonline.com/.../releases/.../8/...-8.pom
Uploaded: https://artifactoryonline.com/.../releases/.../8/...-8.pom (16
KB at 11.1 KB/sec)
{code}
But the same command in Maven 3.0.5 fails:
{code:none}
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ ... ---
Uploading: https://artifactoryonline.com/.../releases/.../8/...-8.pom
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] ...
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project ...: Failed to deploy artifacts: Could not transfer artifact
...:...:pom:8 from/to ... (https://artifactoryonline.com/.../releases):
Host name may not be null - [Help 1]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5443) Maven 3.0.5 regression in release:perform: Host name may not be null
[
https://jira.codehaus.org/browse/MNG-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=320683#comment-320683
]
Jesse Glick commented on MNG-5443:
--
With {{-e}}:
{code:none}
java.lang.IllegalArgumentException: Host name may not be null
at
org.apache.maven.wagon.providers.http.httpclient.HttpHost.init(HttpHost.java:79)
at
org.apache.maven.wagon.providers.http.httpclient.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:501)
at
org.apache.maven.wagon.providers.http.httpclient.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
at
org.apache.maven.wagon.providers.http.httpclient.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
at
org.apache.maven.wagon.shared.http4.AbstractHttpClientWagon.execute(AbstractHttpClientWagon.java:746)
?
{code}
Debugging made considerably more complicated by lack of deployed
{{*-sources.jar}} for shaded artifacts, but everything looks fine at line 746
at least. Using {{-X}} turned up nothing more of interest.
Setting {{-Dmaven.wagon.http.ssl.insecure=true}} (either on {{mvn}} command
line, or in {{$MAVEN_OPTS}}) as per WAGON-385 did not help. I also tried
{{.allowall}} and {{.ignore.validity.dates}} without luck.
Maven 3.0.5 regression in release:perform: Host name may not be null
--
Key: MNG-5443
URL: https://jira.codehaus.org/browse/MNG-5443
Project: Maven 2 3
Issue Type: Bug
Components: Deployment
Environment: Ubuntu 12.04 32-bit, JDK 7u15
Reporter: Jesse Glick
Priority: Blocker
Attachments: ssl.png
With Maven 3.0.4 deploying to our Artifactory server from {{release:perform}}
works fine:
{code:none}
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ ... ---
Uploading: https://artifactoryonline.com/.../releases/.../8/...-8.pom
Uploaded: https://artifactoryonline.com/.../releases/.../8/...-8.pom (16
KB at 11.1 KB/sec)
{code}
But the same command in Maven 3.0.5 fails:
{code:none}
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ ... ---
Uploading: https://artifactoryonline.com/.../releases/.../8/...-8.pom
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] ...
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project ...: Failed to deploy artifacts: Could not transfer artifact
...:...:pom:8 from/to ... (https://artifactoryonline.com/.../releases):
Host name may not be null - [Help 1]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5443) Maven 3.0.5 regression in release:perform: Host name may not be null
[
https://jira.codehaus.org/browse/MNG-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=320697#comment-320697
]
Jesse Glick commented on MNG-5443:
--
The actual host name, repo name, and group/artifactId are elided with ? since
they are not publicly readable anyway.
Maven 3.0.5 regression in release:perform: Host name may not be null
--
Key: MNG-5443
URL: https://jira.codehaus.org/browse/MNG-5443
Project: Maven 2 3
Issue Type: Bug
Components: Deployment
Environment: Ubuntu 12.04 32-bit, JDK 7u15
Reporter: Jesse Glick
Priority: Blocker
Attachments: ssl.png
With Maven 3.0.4 deploying to our Artifactory server from {{release:perform}}
works fine:
{code:none}
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ ... ---
Uploading: https://artifactoryonline.com/.../releases/.../8/...-8.pom
Uploaded: https://artifactoryonline.com/.../releases/.../8/...-8.pom (16
KB at 11.1 KB/sec)
{code}
But the same command in Maven 3.0.5 fails:
{code:none}
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ ... ---
Uploading: https://artifactoryonline.com/.../releases/.../8/...-8.pom
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] ...
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project ...: Failed to deploy artifacts: Could not transfer artifact
...:...:pom:8 from/to ... (https://artifactoryonline.com/.../releases):
Host name may not be null - [Help 1]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
