[jira] [Closed] (SUREFIRE-583) When forking and specifying a JVM, that JVM's security policy's JCE providers are not loaded, JAVA_HOME's are
[ https://issues.apache.org/jira/browse/SUREFIRE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-583. - Resolution: Won't Fix No answer and reproducible project available attached over three months. When forking and specifying a JVM, that JVM's security policy's JCE providers are not loaded, JAVA_HOME's are - Key: SUREFIRE-583 URL: https://issues.apache.org/jira/browse/SUREFIRE-583 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.4.2 Environment: Windows, JAVA_HOME is Sun JDK 1.6.0u16, forked JVM is IBM JDK for WAS 6.1 Reporter: Justin Searls Assignee: Tibor Digana Fix For: Backlog Premise: My test needs to run on the IBM JDK to work, but for other reasons I need to actually build on the Sun JVM. My application's tests are relying on libraries that use a message digest (SHA, not SHA1) that I can only find support for in the BouncyCastle JCE provider. Setup: 1. So I've identified in my plugin configuration something like jvm/path/to/ibm/jdk/jre/bin/javaw.exe/jvm 2. Added BouncyCastle JCE provider jar to /path/to/ibm/jdk/jre/lib/ext 3. Setup BouncyCastle as the sole JCE provider in /path/to/ibm/jdk/jre/lib/security/java.security Expected Result: Designated IBM JVM would look for its java.security file and load its jre/lib/ext JARs when executing tests Actual Result: No such effect. After going through the same setup on my Sun JDK (which I'm running Maven with), that did have the effect of actually providing that provider and getting past the error I was experiencing. It seems to me that if you fork to a different JVM, that JVM's security policy should be used. Given the complexity of this API, however, I wouldn't be surprised to hear that there's a major technical hurdle in implementing this, however. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-583) When forking and specifying a JVM, that JVM's security policy's JCE providers are not loaded, JAVA_HOME's are
[ https://issues.apache.org/jira/browse/SUREFIRE-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585778#comment-14585778 ] Tibor Digana edited comment on SUREFIRE-583 at 6/15/15 11:01 AM: - No answer and reproducible project attached after over three months. was (Author: tibor17): No answer and reproducible project available attached over three months. When forking and specifying a JVM, that JVM's security policy's JCE providers are not loaded, JAVA_HOME's are - Key: SUREFIRE-583 URL: https://issues.apache.org/jira/browse/SUREFIRE-583 Project: Maven Surefire Issue Type: Bug Components: process forking Affects Versions: 2.4.2 Environment: Windows, JAVA_HOME is Sun JDK 1.6.0u16, forked JVM is IBM JDK for WAS 6.1 Reporter: Justin Searls Assignee: Tibor Digana Fix For: Backlog Premise: My test needs to run on the IBM JDK to work, but for other reasons I need to actually build on the Sun JVM. My application's tests are relying on libraries that use a message digest (SHA, not SHA1) that I can only find support for in the BouncyCastle JCE provider. Setup: 1. So I've identified in my plugin configuration something like jvm/path/to/ibm/jdk/jre/bin/javaw.exe/jvm 2. Added BouncyCastle JCE provider jar to /path/to/ibm/jdk/jre/lib/ext 3. Setup BouncyCastle as the sole JCE provider in /path/to/ibm/jdk/jre/lib/security/java.security Expected Result: Designated IBM JVM would look for its java.security file and load its jre/lib/ext JARs when executing tests Actual Result: No such effect. After going through the same setup on my Sun JDK (which I'm running Maven with), that did have the effect of actually providing that provider and getting past the error I was experiencing. It seems to me that if you fork to a different JVM, that JVM's security policy should be used. Given the complexity of this API, however, I wouldn't be surprised to hear that there's a major technical hurdle in implementing this, however. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5842) java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter with jetty plugin
Jean-Christophe Gay created MNG-5842:
Summary: java.lang.NoClassDefFoundError:
org/slf4j/helpers/MessageFormatter with jetty plugin
Key: MNG-5842
URL: https://issues.apache.org/jira/browse/MNG-5842
Project: Maven
Issue Type: Bug
Components: Class Loading
Affects Versions: 3.3.3, 3.3.1
Reporter: Jean-Christophe Gay
When Maven is used with a different SLF4J implementation than slf4j-simple (in
my case logback to have colored logs), running jetty-maven-plugin fails.
{code}
Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
2015-04-22T13:57:37+02:00)
Maven home: /usr/local/Cellar/maven/3.3.3/libexec
Java version: 1.8.0_40, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre
Default locale: fr_FR, platform encoding: UTF-8
OS name: mac os x, version: 10.10.3, arch: x86_64, family: mac
{code}
{code}
[WARNING] FAILED org.mortbay.jetty.plugin.JettyServer@66c4005:
java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
java.lang.ClassNotFoundException: org.slf4j.helpers.MessageFormatter
at
org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
~[plexus-classworlds-2.5.2.jar:na]
at
org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:271)
~[plexus-classworlds-2.5.2.jar:na]
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:247)
~[plexus-classworlds-2.5.2.jar:na]
at
org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:239)
~[plexus-classworlds-2.5.2.jar:na]
... 21 common frames omitted
Wrapped by: java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
at
org.eclipse.jetty.util.log.JettyAwareLogger.log(JettyAwareLogger.java:619)
~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
at
org.eclipse.jetty.util.log.JettyAwareLogger.info(JettyAwareLogger.java:314)
~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
at org.eclipse.jetty.util.log.Slf4jLog.info(Slf4jLog.java:74)
~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
at org.eclipse.jetty.server.Server.doStart(Server.java:271)
~[jetty-server-7.6.16.v20140903.jar:7.6.16.v20140903]
at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:65)
~[jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
at
org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:520)
[jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
at
org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:365)
[jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
at org.mortbay.jetty.plugin.JettyRunMojo.execute(JettyRunMojo.java:521)
[jetty-maven-plugin-7.6.16.v20140903.jar:7.6.16.v20140903]
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
[maven-core-3.3.1.jar:3.3.1]
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
[maven-core-3.3.1.jar:3.3.1]
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
[maven-core-3.3.1.jar:3.3.1]
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
[maven-core-3.3.1.jar:3.3.1]
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
[maven-core-3.3.1.jar:3.3.1]
at
io.takari.maven.builder.smart.SmartBuilderImpl.buildProject(SmartBuilderImpl.java:275)
[takari-smart-builder-0.4.0.jar:0.4.0]
at
io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run(SmartBuilderImpl.java:101)
[takari-smart-builder-0.4.0.jar:0.4.0]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[na:1.8.0_40]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[na:1.8.0_40]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0_40]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0_40]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_40]
java.lang.NoClassDefFoundError: org/slf4j/helpers/MessageFormatter
at
org.eclipse.jetty.util.log.JettyAwareLogger.log(JettyAwareLogger.java:619)
~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
at
org.eclipse.jetty.util.log.JettyAwareLogger.info(JettyAwareLogger.java:314)
~[jetty-util-7.6.16.v20140903.jar:7.6.16.v20140903]
at org.eclipse.jetty.util.log.Slf4jLog.info(Slf4jLog.java:74)
[jira] [Commented] (MNG-5830) maven.multiModuleProjectDirectory system propery is not set
[
https://issues.apache.org/jira/browse/MNG-5830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587489#comment-14587489
]
Ralph Goers commented on MNG-5830:
--
We are seeing this error building the site for Log4j 2 with buildbot. I can't
find any documentation on this property. What is it for and why does its
absence now cause builds to fail?
maven.multiModuleProjectDirectory system propery is not set
---
Key: MNG-5830
URL: https://issues.apache.org/jira/browse/MNG-5830
Project: Maven
Issue Type: Bug
Components: Bootstrap Build, Command Line
Affects Versions: 3.3.1, 3.3.3
Reporter: Krzysztof Sobkowiak
Priority: Critical
Labels: Linux
I have downloaded the newest Maven 3.3.3 and point the M2_HOME to the
directory with unpacked Maven. {{mvn -v}} produces following error (whereas
the versions prior to 3.1.1 worked correctly)
{code}
kso@lenovo:/tmp$ export
M2_HOME=/home/kso/work/pde/dev/maven/apache-maven-3.3.3/
kso@lenovo:/tmp$ mvn -v
-Dmaven.multiModuleProjectDirectory system propery is not set. Check $M2_HOME
environment variable and mvn script match.kso@lenovo:/tmp$
{code}
The same problem when I want to build any maven project.
Below the same output with Maven 3.2.5 to give you informations about my
environment
{code}
kso@lenovo:/tmp$ export
M2_HOME=/home/kso/work/pde/dev/maven/apache-maven-3.2.5/
kso@lenovo:/tmp$ mvn -v
Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1;
2014-12-14T18:29:23+01:00)
Maven home: /home/kso/work/pde/dev/maven/apache-maven-3.2.5
Java version: 1.7.0_71, vendor: Oracle Corporation
Java home: /home/kso/work/pde/run/jvm/jdk1.7.0_71/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 3.16.0-38-generic, arch: amd64, family: unix
{code}
--
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] [Updated] (MCHANGES-354) The plugin should fail to execute if the changes.xml file cannot be parsed
[ https://issues.apache.org/jira/browse/MCHANGES-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gabor Szabo updated MCHANGES-354: - Attachment: MCHANGES-354-maven-changes-plugin.patch The patch contains a slight modification: the ChangesXML class throws a ChangesXMLException which is an unchecked RuntimeException. This way the plugin execution fails, but no other code must catch this error. I also added a unit test that verifies this behavior. The plugin should fail to execute if the changes.xml file cannot be parsed -- Key: MCHANGES-354 URL: https://issues.apache.org/jira/browse/MCHANGES-354 Project: Maven Changes Plugin Issue Type: Bug Reporter: Gabor Szabo Attachments: MCHANGES-354-maven-changes-plugin.patch Currently if there is a problem during changes.xml parsing, the exception is caught and logged, but the changes-report goal is executed successfully. This is misleading as from the result it seems everything was fine, however a fatal error occurred. There is also a FIXME comment here that suggests an exception should be thrown: https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-changes-plugin/src/main/java/org/apache/maven/plugin/changes/ChangesXML.java (line 101) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MCHANGES-354) The plugin should fail to execute if the changes.xml file cannot be parsed
Gabor Szabo created MCHANGES-354: Summary: The plugin should fail to execute if the changes.xml file cannot be parsed Key: MCHANGES-354 URL: https://issues.apache.org/jira/browse/MCHANGES-354 Project: Maven Changes Plugin Issue Type: Bug Reporter: Gabor Szabo Currently if there is a problem during changes.xml parsing, the exception is caught and logged, but the changes-report goal is executed successfully. This is misleading as from the result it seems everything was fine, however a fatal error occurred. There is also a FIXME comment here that suggests an exception should be thrown: https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-changes-plugin/src/main/java/org/apache/maven/plugin/changes/ChangesXML.java (line 101) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5297) Site should tell 'prerequisites.maven is deprecated'
[ https://issues.apache.org/jira/browse/MNG-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586641#comment-14586641 ] ASF GitHub Bot commented on MNG-5297: - Github user mosabua commented on the pull request: https://github.com/apache/maven/pull/51#issuecomment-112198560 Enforcer plugin is for build time enforcement. Prerequisite is build time as well as plugin runtime requirement. As such it should not be deprecated. Documentation update would however be useful. Site should tell 'prerequisites.maven is deprecated' Key: MNG-5297 URL: https://issues.apache.org/jira/browse/MNG-5297 Project: Maven Issue Type: Bug Components: Sites Reporting Affects Versions: 3.0.4 Reporter: Kengo TODA Priority: Minor MNG-4840 said 'enforcement of the build environment is left to the Maven Enforcer Plugin'. http://jira.codehaus.org/browse/MNG-4840?focusedCommentId=253900page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253900 But currently, there is no 'deprecated' mark at Maven site. http://maven.apache.org/ref/3.0.4/maven-model/maven.html#prerequisites I think site should has 'deprecated' mark like 'reports' element. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://issues.apache.org/jira/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1134.
--
Resolution: Fixed
Fixed in SUREFIRE-1065. Use the system properties
-Dsurefire.includesFile=include.txt
-Dsurefire.excludesFile=exclude.txt
-Dfailsafe.includesFile=include.txt
-Dfailsafe.excludesFile=exclude.txt
Take list of tests from file (-Dtest has upper limits for comma-separated
list of tests)
Key: SUREFIRE-1134
URL: https://issues.apache.org/jira/browse/SUREFIRE-1134
Project: Maven Surefire
Issue Type: New Feature
Reporter: Paul Hammant
Assignee: Tibor Digana
Priority: Minor
Fix For: 2.19
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
list of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-DtestListFile=testsToRun.txt
{panel}
Also for Failsafe:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-Dit.testListFile=testsToRun.txt
{panel}
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1134) Take list of tests from file (-Dtest has upper limits for comma-separated list of tests)
[
https://issues.apache.org/jira/browse/SUREFIRE-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1134:
---
Fix Version/s: 2.19
Take list of tests from file (-Dtest has upper limits for comma-separated
list of tests)
Key: SUREFIRE-1134
URL: https://issues.apache.org/jira/browse/SUREFIRE-1134
Project: Maven Surefire
Issue Type: New Feature
Reporter: Paul Hammant
Assignee: Tibor Digana
Priority: Minor
Fix For: 2.19
-Dtest=TestOne,foo.BarTest is the way to go for constraining surefire to a
list of tests. There are upper limits to that in the context of command line
arguments.
Could we additionally have:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-DtestListFile=testsToRun.txt
{panel}
Also for Failsafe:
{panel:title=Example mvn
param|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1|bgColor=#CE}
-Dit.testListFile=testsToRun.txt
{panel}
Yes, I'd be rewriting testsToRun.txt for my use case, just before invoking
Maven.
Refer
http://paulhammant.com/2015/01/11/reducing-test-times-by-only-running-impacted-tests/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCHANGES-354) The plugin should fail to execute if the changes.xml file cannot be parsed
[
https://issues.apache.org/jira/browse/MCHANGES-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586531#comment-14586531
]
Karl Heinz Marbaise commented on MCHANGES-354:
--
Maybe i mistaken something or what ever ...but when i try to apply your patch
on the current trunk...it does not change anything...Can you please recheck the
patch and how you have created...Have you created it on command line or via IDE
?
{code}
maven-changes-plugin$ svn patch MCHANGES-354-maven-changes-plugin.patch
maven-changes-plugin$ svn st
? MCHANGES-354-maven-changes-plugin.patch
{code}
Can you created it by {{svn diff x.patch}} ?
The plugin should fail to execute if the changes.xml file cannot be parsed
--
Key: MCHANGES-354
URL: https://issues.apache.org/jira/browse/MCHANGES-354
Project: Maven Changes Plugin
Issue Type: Bug
Reporter: Gabor Szabo
Attachments: MCHANGES-354-maven-changes-plugin.patch
Currently if there is a problem during changes.xml parsing, the exception is
caught and logged, but the changes-report goal is executed successfully.
This is misleading as from the result it seems everything was fine, however a
fatal error occurred.
There is also a FIXME comment here that suggests an exception should be
thrown:
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-changes-plugin/src/main/java/org/apache/maven/plugin/changes/ChangesXML.java
(line 101)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-597) Surefire report creation fails on processing absent optional JUnit xml attributes
[ https://issues.apache.org/jira/browse/SUREFIRE-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-597: -- Fix Version/s: 2.19 Surefire report creation fails on processing absent optional JUnit xml attributes - Key: SUREFIRE-597 URL: https://issues.apache.org/jira/browse/SUREFIRE-597 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Report Plugin Affects Versions: 2.4.3 Reporter: Maksym Symonov Assignee: Tibor Digana Priority: Minor Fix For: 2.19 Surefire report creation fails when JUnit XML source for report doesn't contain optional attributes. I use Clojure with junit xml output, it produces xml with failure subnode of testcase. It has no message and type attributes specified for it. But has error message as nested text. Plugin processes this xml and fails with NullPointerException SurefireReportGenerator.java:676, as i see in the code, it's not possible for it to have failure node without type attribute. Maybe it would be better to add null checking at that method? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5297) Site should tell 'prerequisites.maven is deprecated'
[ https://issues.apache.org/jira/browse/MNG-5297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14586588#comment-14586588 ] ASF GitHub Bot commented on MNG-5297: - Github user kwin commented on a diff in the pull request: https://github.com/apache/maven/pull/51#discussion_r32460741 --- Diff: maven-model/src/main/mdo/maven.mdo --- @@ -3459,6 +3459,7 @@ typeString/type defaultValue2.0/defaultValue description![CDATA[ +bDeprecated/b. Use the Maven Enforcer Plugin's a href=https://maven.apache.org/enforcer/enforcer-rules/requireMavenVersion.html;coderequireMavenVersion/code/a rule instead.br --- End diff -- This prerequisites is still supported for Maven Plugins (https://issues.apache.org/jira/browse/MNG-5501?focusedCommentId=14419813page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14419813), therefore rather than deprecating that I would add a hint, that this should only be used for packaging plugin. Site should tell 'prerequisites.maven is deprecated' Key: MNG-5297 URL: https://issues.apache.org/jira/browse/MNG-5297 Project: Maven Issue Type: Bug Components: Sites Reporting Affects Versions: 3.0.4 Reporter: Kengo TODA Priority: Minor MNG-4840 said 'enforcement of the build environment is left to the Maven Enforcer Plugin'. http://jira.codehaus.org/browse/MNG-4840?focusedCommentId=253900page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253900 But currently, there is no 'deprecated' mark at Maven site. http://maven.apache.org/ref/3.0.4/maven-model/maven.html#prerequisites I think site should has 'deprecated' mark like 'reports' element. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SUREFIRE-597) Surefire report creation fails on processing absent optional JUnit xml attributes
[ https://issues.apache.org/jira/browse/SUREFIRE-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-597. - Resolution: Fixed Introduced unit test Surefire597Test in maven-surefire-report-plugin module. Surefire report creation fails on processing absent optional JUnit xml attributes - Key: SUREFIRE-597 URL: https://issues.apache.org/jira/browse/SUREFIRE-597 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Report Plugin Affects Versions: 2.4.3 Reporter: Maksym Symonov Assignee: Tibor Digana Priority: Minor Fix For: 2.19 Surefire report creation fails when JUnit XML source for report doesn't contain optional attributes. I use Clojure with junit xml output, it produces xml with failure subnode of testcase. It has no message and type attributes specified for it. But has error message as nested text. Plugin processes this xml and fails with NullPointerException SurefireReportGenerator.java:676, as i see in the code, it's not possible for it to have failure node without type attribute. Maybe it would be better to add null checking at that method? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1127) Failsafe project does not fail in verify phase when a test case object errors during initialization
[
https://issues.apache.org/jira/browse/SUREFIRE-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1127:
---
Fix Version/s: 2.19
Failsafe project does not fail in verify phase when a test case object errors
during initialization
---
Key: SUREFIRE-1127
URL: https://issues.apache.org/jira/browse/SUREFIRE-1127
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin
Affects Versions: 2.18
Environment: JDK 1.8.0_05 on Windows 7 used to recreate
Reporter: Bret Goldsmith
Assignee: Tibor Digana
Fix For: 2.19
Attachments: failsafe-test.zip
Sample project attached.
When running a mvn verify - the attached project will succeed, even though
there is an integration test that should obviously fail.
The integration test case does not initialize correctly (it will throw a null
pointer exception in one of its object initializers), which should be a test
failure and therefore a project failure.
I've traced this down to the fact that the generated failsafe-summary.xml
file contains an empty failureMessage element:
{code:xml}
?xml version=1.0 encoding=UTF-8?
failsafe-summary result=254 timeout=false
completed0/completed
errors0/errors
failures0/failures
skipped0/skipped
failureMessage/failureMessage
/failsafe-summary
{code}
And so the failsafe verifier doesn't consider the project a failure. The
message seems to be blank because when the failsafe plugin is writing the
results, it uses the
org.apache.maven.plugins.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
method to write out the first forked exception, which then calls
org.apache.maven.surefire.suite.RunResult.failure() method, which then calls
getStackTrace() on the exception.
The getStackTrace() method looks like this:
{code:java}
private static String getStackTrace( Exception e )
{
if ( e == null )
{
return null;
}
ByteArrayOutputStream out = new ByteArrayOutputStream();
PrintWriter pw = new PrintWriter( out );
e.printStackTrace( pw );
return new String( out.toByteArray() );
}
{code}
And it specifically is doing a toBytearray on the output stream without
flushing or closing the printwriter first. At least with my JVM 1.8.0_05
version, this seems to be a problem as the printwriter still maintains the
trace description in a buffer.
When I put a breakpoint on this and specifically flush or close the
printwriter before the toByteArray, the project fails as expected.
I'm not sure why this is failsafe specific, but a surefire version test case
(also included in the attachment project) fails appropriately.
I think a simple patch is to update RunResult.java to close the printwriter
before getting the resulting stacktrace string. i.e.
{code:java}
private static String getStackTrace( Exception e )
{
if ( e == null )
{
return null;
}
ByteArrayOutputStream out = new ByteArrayOutputStream();
PrintWriter pw = new PrintWriter( out );
try {
e.printStackTrace( pw );
} finally {
pw.close();
}
return new String( out.toByteArray() );
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SUREFIRE-826) maven-surefire-plugin does not add its own plugin dependencies to the classpath
[
https://issues.apache.org/jira/browse/SUREFIRE-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-826:
-
Assignee: Tibor Digana
maven-surefire-plugin does not add its own plugin dependencies to the
classpath
---
Key: SUREFIRE-826
URL: https://issues.apache.org/jira/browse/SUREFIRE-826
Project: Maven Surefire
Issue Type: Improvement
Components: classloading, Maven Surefire Plugin
Affects Versions: 2.11
Environment: Maven 3.0.3
Java 6
Reporter: René Zanner
Assignee: Tibor Digana
Currently some JAR containing a RunListener for JUnit must be located in the
project's classpath (and pollutes the classpath with most likely unwanted
transitive dependencies).
An alternative is to use the 'additionalClasspathElements' configuration
element in the maven-surefire-plugin's configuration. Unfortunately this
cannot be used to specify another maven artifact directly - only JARs or
class folders in the file system.
It would be consistent to enable the usage of plugin dependencies
({{dependencies}} element in the {{plugin}} section of the POM) to load
such classes:
{code:xml}
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
properties
property
namelistener/name
valuesome.RunListener/value
/property
/properties
/configuration
!--
reference the JAR containing the class some.RunListener as plugin
dependency
(this is possible from the Maven point of view, but currently does
not work)
--
dependencies
dependency
groupIdsome.group.id/groupId
artifactIdsome-artifact-id/artifactId
version${some.version}/version
/dependency
/dependencies
/plugin
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MDEP-492) Maven3 - GAC Dependency resolution appears to be happening too late
Greg Domjan created MDEP-492:
Summary: Maven3 - GAC Dependency resolution appears to be
happening too late
Key: MDEP-492
URL: https://issues.apache.org/jira/browse/MDEP-492
Project: Maven Dependency Plugin
Issue Type: Bug
Reporter: Greg Domjan
This is an NPANDAY issue - project is no longer listed for raising new issues.
Using other plugins that require dependency resolution in phases compile or
earlier - such as
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.10/version
executions
execution
idunpack-dependencies/id
phasecompile/phase !-- any phase compile or earlier --
goals
goalunpack-dependencies/goal
/goals
{code}
in combination with items from the GAC such as
{code:xml}
dependency
groupIdWindowsBase/groupId
artifactIdWindowsBase/artifactId
version3.0.0.0/version
typegac_msil/type
classifier31bf3856ad364e35/classifier
scopeprovided/scope
/dependency
{code}
Leads to failure to resolve these dependencies
{noformat}
\apache-maven-3.2\bin\mvn compile
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building example 0.1-SNAPSHOT
[INFO]
[WARNING] The POM for WindowsBase:WindowsBase:dll:31bf3856ad364e35:3.0.0.0 is
missing, no dependency information available
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 0.927 s
[INFO] Finished at: 2015-06-15T15:39:12-06:00
[INFO] Final Memory: 8M/489M
[INFO]
[ERROR] Failed to execute goal on project example: Could not resolve
dependencies for project net.example:example:dotnet-library:0.1-SNAPSHOT:
Failure to find WindowsBase:WindowsBase:dll:31bf3856ad364e35:3.0.0.0 in ... was
cached in the local repository, resolution will not be reattempted until the
update interval of ... has elapsed or updates are forced - [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
{noformat}
A workaround seems to be to reference the dependency as a system item
{code:xml}
dependency
groupIdWindowsBase/groupId
artifactIdWindowsBase/artifactId
version3.0.0.0/version
typegac_msil/type
classifier31bf3856ad364e35/classifier
scopesystem/scope
systemPath${env.SYSTEMROOT}\Assembly\GAC_MSIL\WindowsBase\3.0.0.0__31bf3856ad364e35\WindowsBase.dll/systemPath
/dependency
{code}
Or avoid goals that will cause dependency resolution scope of compile -
goalunpack-dependencies/goal change to ?? goalunpack/goal
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1144) Time for testsuite on commandline does not suit with the time value given in the report file
[
https://issues.apache.org/jira/browse/SUREFIRE-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14587016#comment-14587016
]
ASF GitHub Bot commented on SUREFIRE-1144:
--
GitHub user lamyaa opened a pull request:
https://github.com/apache/maven-surefire/pull/98
[Surefire-1144] Time for testsuite on commandline does not suit with the
time value given in the report file
https://issues.apache.org/jira/browse/SUREFIRE-1144
This pull request modifies the XML reporter such that it shows time
computed as `endTime - startTime` rather than summing up the method execution
times through `getRunTimeForAllTests()`.
I have tested this patch with the project provided by Karl in the bug
report thread:
https://github.com/khmarbaise/supose/
The time shown in the XML report is now consistent with the one shown in
the console.
@Tibor17 I would appreciate your input on a couple of things:
1) Initially, I deleted line 111/122 (`elapsedForTestSet +=
elapsedForThis;`) in TestSetStats and line 100 (` elapsedForTestSet =
testSetEndAt - testSetStartAt;)` was not within an if-block. However, that made
XmlReporterRunTimeIT fail. The IT runs test methods in parallel and
`testSetEndAt - testSetStartAt` ends up being abnormally small, smaller than
the sleep times of any of the test methods. I don't understand enough of how
the parallelism and fork code is implemented to properly debug that so I left
line 111/122 and wrapped line 100 within an if-block. Please let me know if you
have a better idea of how to deal with this.
2) The XML report now prints `elapsedForTestSet = testSetEndAt -
testSetStartAt` but the console (which I have not changed) prints
`elapsedSinceTestSetStart = currentTime - testSetStartAt`. This means the
console time may be 1 or 2ms more than the XML report time. Do you think it
would be good to have the console also print `elapsedForTestSet`? If not, I
probably need to change Surefire1144XmlRunTimeIT to accept a 1 or 2ms
difference.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/lamyaa/maven-surefire surefire-1144
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/maven-surefire/pull/98.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #98
commit 9d4931b9ccd82e9305efe1405a56083b6023e84e
Author: lamyaa elous...@illinois.edu
Date: 2015-06-12T19:29:58Z
[Surefire-1144] Time for testsuite on commandline does not suit with the
time value given in the report file
Time for testsuite on commandline does not suit with the time value given in
the report file
Key: SUREFIRE-1144
URL: https://issues.apache.org/jira/browse/SUREFIRE-1144
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.18
Reporter: Karl Heinz Marbaise
Assignee: Tibor Digana
Priority: Critical
Fix For: 2.19
Attachments: mvn.log, surefire.reports.tar.gz
Currently i have a build where i got printed out the following:
{noformat}
[INFO] --- maven-surefire-plugin:2.18:test (default-test) @ supose-cli ---
[INFO] Surefire report directory:
/Users/kama/ws-git/supose/supose-cli/target/surefire-reports
---
T E S T S
---
Running com.soebes.supose.cli.SuposeCLITest
Configuring TestNG with: TestNG652Configurator
Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.562 sec -
in com.soebes.supose.cli.SuposeCLITest
Results :
Tests run: 22, Failures: 0, Errors: 0, Skipped: 0
[INFO]
{noformat}
So if i take a look into the appropriate surefire-report file
{{supose-cli/target/surefire-reports/TEST-com.soebes.supose.cli.SuposeCLITest.xml}}
i see the following in the first lines:
{code:xml}
?xml version=1.0 encoding=UTF-8?
testsuite name=com.soebes.supose.cli.SuposeCLITest time=0.142 tests=22
errors=0 skipped=0 failures=0
properties
{code}
which shows a complete different time {{0.142}} instead of {{0.562}}.
I have had expected to see the same time in the xml file as well as on the
print out on console...
So the question is: Where does this difference come frome? Do i misundestand
a thing here?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-826) maven-surefire-plugin does not add its own plugin dependencies to the classpath
[
https://issues.apache.org/jira/browse/SUREFIRE-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585605#comment-14585605
]
Tibor Digana commented on SUREFIRE-826:
---
[~sverhagen]
Are you going to update the documentation?
maven-surefire-plugin does not add its own plugin dependencies to the
classpath
---
Key: SUREFIRE-826
URL: https://issues.apache.org/jira/browse/SUREFIRE-826
Project: Maven Surefire
Issue Type: Improvement
Components: classloading, Maven Surefire Plugin
Affects Versions: 2.11
Environment: Maven 3.0.3
Java 6
Reporter: René Zanner
Currently some JAR containing a RunListener for JUnit must be located in the
project's classpath (and pollutes the classpath with most likely unwanted
transitive dependencies).
An alternative is to use the 'additionalClasspathElements' configuration
element in the maven-surefire-plugin's configuration. Unfortunately this
cannot be used to specify another maven artifact directly - only JARs or
class folders in the file system.
It would be consistent to enable the usage of plugin dependencies
({{dependencies}} element in the {{plugin}} section of the POM) to load
such classes:
{code:xml}
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
properties
property
namelistener/name
valuesome.RunListener/value
/property
/properties
/configuration
!--
reference the JAR containing the class some.RunListener as plugin
dependency
(this is possible from the Maven point of view, but currently does
not work)
--
dependencies
dependency
groupIdsome.group.id/groupId
artifactIdsome-artifact-id/artifactId
version${some.version}/version
/dependency
/dependencies
/plugin
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SUREFIRE-1127) Failsafe project does not fail in verify phase when a test case object errors during initialization
[
https://issues.apache.org/jira/browse/SUREFIRE-1127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1127.
--
Resolution: Fixed
commit e9e0bbe52c49f4f9cbd321824c39d849ee866b94
Failsafe project does not fail in verify phase when a test case object errors
during initialization
---
Key: SUREFIRE-1127
URL: https://issues.apache.org/jira/browse/SUREFIRE-1127
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin
Affects Versions: 2.18
Environment: JDK 1.8.0_05 on Windows 7 used to recreate
Reporter: Bret Goldsmith
Assignee: Tibor Digana
Fix For: 2.19
Attachments: failsafe-test.zip
Sample project attached.
When running a mvn verify - the attached project will succeed, even though
there is an integration test that should obviously fail.
The integration test case does not initialize correctly (it will throw a null
pointer exception in one of its object initializers), which should be a test
failure and therefore a project failure.
I've traced this down to the fact that the generated failsafe-summary.xml
file contains an empty failureMessage element:
{code:xml}
?xml version=1.0 encoding=UTF-8?
failsafe-summary result=254 timeout=false
completed0/completed
errors0/errors
failures0/failures
skipped0/skipped
failureMessage/failureMessage
/failsafe-summary
{code}
And so the failsafe verifier doesn't consider the project a failure. The
message seems to be blank because when the failsafe plugin is writing the
results, it uses the
org.apache.maven.plugins.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked
method to write out the first forked exception, which then calls
org.apache.maven.surefire.suite.RunResult.failure() method, which then calls
getStackTrace() on the exception.
The getStackTrace() method looks like this:
{code:java}
private static String getStackTrace( Exception e )
{
if ( e == null )
{
return null;
}
ByteArrayOutputStream out = new ByteArrayOutputStream();
PrintWriter pw = new PrintWriter( out );
e.printStackTrace( pw );
return new String( out.toByteArray() );
}
{code}
And it specifically is doing a toBytearray on the output stream without
flushing or closing the printwriter first. At least with my JVM 1.8.0_05
version, this seems to be a problem as the printwriter still maintains the
trace description in a buffer.
When I put a breakpoint on this and specifically flush or close the
printwriter before the toByteArray, the project fails as expected.
I'm not sure why this is failsafe specific, but a surefire version test case
(also included in the attachment project) fails appropriately.
I think a simple patch is to update RunResult.java to close the printwriter
before getting the resulting stacktrace string. i.e.
{code:java}
private static String getStackTrace( Exception e )
{
if ( e == null )
{
return null;
}
ByteArrayOutputStream out = new ByteArrayOutputStream();
PrintWriter pw = new PrintWriter( out );
try {
e.printStackTrace( pw );
} finally {
pw.close();
}
return new String( out.toByteArray() );
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
