[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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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=revision&revision=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}
>
> ../../validation/validation-api
> ../../validation/validation-aspect
> ../parent
>
> {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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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
