[jira] (SUREFIRE-956) Let ${surefire.forkNumber} deliver unique values when used in parallel mvn builds
Andreas Gudian created SUREFIRE-956:
---
Summary: Let ${surefire.forkNumber} deliver unique values when
used in parallel mvn builds
Key: SUREFIRE-956
URL: https://jira.codehaus.org/browse/SUREFIRE-956
Project: Maven Surefire
Issue Type: Improvement
Reporter: Andreas Gudian
Currently, ${surefire.forkNumber} is resolved to a unique value only for a
single instance of the surefire execution. E.g. With {{forkCount=1}}, the place
holder will always be resolved as {{1}}, even if tests are being executed
concurrently by multiple instances of surefire within a {{mvn -T...}} build.
I'll start creating a path within the next couple of days... :)
--
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-955) Surefire top-level website has obscure navigation (at least in Chrome)
[ https://jira.codehaus.org/browse/SUREFIRE-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318226#comment-318226 ] Kristian Rosenvold commented on SUREFIRE-955: - I think the issue here is really why we have this page, and if we're linking to it from anywhere and what we can do to get rid of this page ;) Surefire top-level website has obscure navigation (at least in Chrome) -- Key: SUREFIRE-955 URL: https://jira.codehaus.org/browse/SUREFIRE-955 Project: Maven Surefire Issue Type: Bug Components: documentation Affects Versions: 2.13 Reporter: Benson Margulies Browse to http://maven.apache.org/surefire And you will find yourself at an 'about' page with the only navigation being top-level dropdown menus. Maybe this JIRA needs to be redirected to a skin, but it took me several minutes to see how I could get from this page to anywhere else, and I bet others will have the same problem. It also does not comply with Apache trademark guidelines; there are no trademark notices for Maven or Surefire. -- 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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318227#comment-318227
]
Benson Margulies commented on SUREFIRE-954:
---
The intelliJ debugger cannot show me a value for 't' at all.
Any attempt to poke at it results in 'Invalid JNI Signature'
However, if I crawl up the stack to ForkedBooter line 104, I see that t is an
InvocationTargetException.
t.getClass().getClassLoader() is null (!).
Here ends the first dispatch from the front.
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318232#comment-318232
]
Benson Margulies commented on SUREFIRE-954:
---
Now I've got a breakpoint on InvocationTargetException. Last hit before the
problem, backtrace:
{noformat}
main@1, prio=5, in group 'main', status: 'RUNNING'
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:93)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95)
{noformat}
Which purports to be on line:
{code}
System.setErr( orgSystemErr );
{code}
Which is a bit hard to believe. I think I'm being fooled by the shade
technology.
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318233#comment-318233
]
Kristian Rosenvold commented on SUREFIRE-954:
-
It may help you to check out the tag of the surefire version you are running.
Sorry for forgetting to mention ;
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318235#comment-318235
]
Benson Margulies commented on SUREFIRE-954:
---
Kristian,
I pulled from git, I built, and I changed my pom to look for 2.14-SNAPSHOT. And
the debugger is fine except for ForkedBooter.
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318234#comment-318234
]
Kristian Rosenvold commented on SUREFIRE-954:
-
Are you running with a security manager installed ?
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318236#comment-318236
]
Benson Margulies commented on SUREFIRE-954:
---
And I have no security manager. Plain old 'mvn' command line.
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318237#comment-318237
]
Benson Margulies commented on SUREFIRE-954:
---
ProviderFactory confuses the debugger as well as ForkedBooter.
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318238#comment-318238
]
Kristian Rosenvold commented on SUREFIRE-954:
-
I know intellij gets confused by classloaders/different sometimes. An alternate
solution which will involve a little keypressing is to simply set exception
breakpoints for ANy exception or Invocation target exception in the forked
process to try to get to the source of the problem
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318239#comment-318239
]
Kristian Rosenvold commented on SUREFIRE-954:
-
If you suspect this happens in one of your @BeforeClass methods (which makes
sense), you might consider attaching a debugger with your OWN code and set
breakpoints in ALL the @BeforeClass methods and step through them.
You can *also* try to force the JUnittCore provider just to smoke out the
problem, since that has different exception handling for @BeforeClass stuff.
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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] (MCHECKSTYLE-172) Checkstyle Plugin 2.8+ generates an additional aggregate report
[
https://jira.codehaus.org/browse/MCHECKSTYLE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318240#comment-318240
]
Justin Ye commented on MCHECKSTYLE-172:
---
So is it possible to have the new version this week? I just want to have a
rough date to help me plan the upgrade. Thanks.
Checkstyle Plugin 2.8+ generates an additional aggregate report
---
Key: MCHECKSTYLE-172
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-172
Project: Maven 2.x Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.8, 2.9
Environment: mvn --version
Apache Maven 3.0.4 (r1206075; 2011-11-25 09:20:29+0100)
Maven home: /usr/local/Cellar/maven/current/libexec
Java version: 1.6.0_29, vendor: Apple Inc.
Java home:
/Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
Default locale: de_DE, platform encoding: MacRoman
OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac
Reporter: SebbASF
Assignee: Dennis Lundberg
Fix For: 2.10
Using a very simple single module project, the aggregated report is created
by default.
Both the {{checkstyle}} and {{checkstyle-aggregate}} report are generated.
--
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] (WAGON-386) build failure with jdk 1.7
[ https://jira.codehaus.org/browse/WAGON-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318241#comment-318241 ] Olivier Lamy commented on WAGON-386: A unit rely on the fact that inputstream#read(byte[] b, int off, int len) will read all byte in once but with 1.7 (in our unit test): 18 bytes are read in 2 read 1 byte then 17 bytes. So a transferprogess is triggered twice which break the assert. But as said in InputStream javadocs: ... An attempt is made to read as many as len bytes, but a smaller number may be read. ... build failure with jdk 1.7 -- Key: WAGON-386 URL: https://jira.codehaus.org/browse/WAGON-386 Project: Maven Wagon Issue Type: Bug Components: wagon-http, wagon-http-lightweight Affects Versions: 2.4 Environment: jdk 1.7 Reporter: Olivier Lamy -- 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] (MPMD-89) Having an equivalent for auxclasspath option
[
https://jira.codehaus.org/browse/MPMD-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MPMD-89.
-
Resolution: Fixed
Fix Version/s: 3.0
Assignee: Benjamin Bentmann
Added {{typeResolution}} parameter in
[r1439834|http://svn.apache.org/viewvc?view=revisionrevision=1439834].
Having an equivalent for auxclasspath option
Key: MPMD-89
URL: https://jira.codehaus.org/browse/MPMD-89
Project: Maven 2.x PMD Plugin
Issue Type: New Feature
Components: PMD
Affects Versions: 2.4
Environment: PMD 4.2.3
Reporter: Benjamin Pochat
Assignee: Benjamin Bentmann
Fix For: 3.0
Attachments: MPMD-89.patch
Hi,
PMD 4.2.3 introduced the option auxclasspath described as follows in the
PMD help :
-auxclasspath: specifies the classpath for libraries used by the source code
(used by type resolution)
Currently, there seems to be no way to use this very useful option in the PMD
maven2 plugin.
I either found no workaround to deal with type resolution inside the project
that has just been built through the compile maven goal.
This would be great !
Benjamin
--
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] (MEAR-168) Use build final name as default context root
José Volmei Dal Prá Junior created MEAR-168:
---
Summary: Use build final name as default context root
Key: MEAR-168
URL: https://jira.codehaus.org/browse/MEAR-168
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.8.1, 2.9
Environment: all
Reporter: José Volmei Dal Prá Junior
Sometimes we need to make some conventions when dealing with several modules.
We need to use the ${project.build.finalName} as the default contextRoot
mapping.
The suggestion is: make a global configuration parameter with name
mustUseBuildFinalNameAsDefaultWebContextRoot. If this is set to true then the
WebModule.getDefaultContextRoot method must use the build final name as
context root.
The global configuration parameter should have false as default value.
Thanks.
--
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] (MCHANGES-303) Add an option to enable tls
Benoit Guerin created MCHANGES-303: -- Summary: Add an option to enable tls Key: MCHANGES-303 URL: https://jira.codehaus.org/browse/MCHANGES-303 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: announcement Affects Versions: 2.8 Reporter: Benoit Guerin Attachments: enableTls.patch Add an option to set ProjectJavamailMailSender.tlsEnabled to true, to allow to use as an example GMail to send announcement emails -- 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] (MCHANGES-303) Add an option to enable tls
[ https://jira.codehaus.org/browse/MCHANGES-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benoit Guerin updated MCHANGES-303: --- Attachment: enableTls.patch Add an option to enable tls --- Key: MCHANGES-303 URL: https://jira.codehaus.org/browse/MCHANGES-303 Project: Maven 2.x Changes Plugin Issue Type: Improvement Components: announcement Affects Versions: 2.8 Reporter: Benoit Guerin Attachments: enableTls.patch Add an option to set ProjectJavamailMailSender.tlsEnabled to true, to allow to use as an example GMail to send announcement emails -- 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] (MENFORCER-147) RequireSamePluginVersions
Robert Scholte created MENFORCER-147: Summary: RequireSamePluginVersions Key: MENFORCER-147 URL: https://jira.codehaus.org/browse/MENFORCER-147 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Components: Standard Rules Affects Versions: 1.2 Reporter: Robert Scholte When plugins are specified as both a build plugin and a reporting plugin, their versions should be the same. This way it is not required to introduce another property just to keep these versions in sync. Add several predefined plugins, which versions should match. For instance: maven-surefire-plugin, maven-failsafe-plugin, maven-surefire-report-plugin. -- 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] (MSITE-669) site:stage creates incorrect structure when module paths contains sets of ../
[
https://jira.codehaus.org/browse/MSITE-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lennart Jorelid updated MSITE-669:
--
Attachment: msite_669_v3.patch
Version 3 of the patch permits users to supply a configurable URL to use for
siteRootURL.
Could we please slate this patch for inclusion in the next release of the site
plugin?
site:stage creates incorrect structure when module paths contains sets of
../
---
Key: MSITE-669
URL: https://jira.codehaus.org/browse/MSITE-669
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: multi module, relative links, site:stage(-deploy)
Affects Versions: 3.1, 3.2
Reporter: Lennart Jorelid
Assignee: Lukas Theussl
Attachments: msite_669.patch, msite_669_v2.patch, msite_669_v3.patch,
nazgul_tools_project_dependencies.png, nazgul_tools_project_dependencies.png,
nazgul_tools_reactor_structure.png, sample.zip
Given the module definitions given below, the site:stage goal produces sets
of maps relative to the staging directory - i.e. outside of the target
directory.
{code:xml}
modules
module../../validation/validation-api/module
module../../validation/validation-aspect/module
module../parent/module
/modules
{code}
The staged site should be fully included within the staging directory. It
would appear that relativization of links for site:stage should take special
links into consideration.
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318265#comment-318265
]
Benson Margulies commented on SUREFIRE-954:
---
I put a test case on a branch:
surefire-954-test
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318266#comment-318266
]
Benson Margulies commented on SUREFIRE-954:
---
By the way, I was able to see enough contents of Method objects to identify my
@BeforeClass method.
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318270#comment-318270
]
Benson Margulies commented on SUREFIRE-954:
---
Unfortunately, I have an additional frustration here. I can't repro the
exception outside of Maven! If I run from IntelliJ, the test works fine. Also
not that we get the exception trace after the Tests run: line.
It appears that attaching a debugger results in the inability to debug
exceptions thrown inside of methods invoked with Method.invoke. My next attempt
will be to set forkMode to never and try to just run mvnDebug and see what I
see.
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318285#comment-318285
]
Benson Margulies commented on SUREFIRE-954:
---
My attempt at an IT to show this problem fails to show this problem, now that I
look at it when I'm awake.
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=318286#comment-318286
]
Kristian Rosenvold commented on SUREFIRE-954:
-
Yeah; we have a fairly decent IT coverage in surefire. Expect most of the easy
ones to be taken ;)
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
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
