[jira] (MNG-5510) Maven causing ClassCastException with container plugins when project is using other SLF4J implementation than slf4j-simple
Juan Pablo Santos RodrÃguez created MNG-5510: Summary: Maven causing ClassCastException with container plugins when project is using other SLF4J implementation than slf4j-simple Key: MNG-5510 URL: https://jira.codehaus.org/browse/MNG-5510 Project: Maven 2 & 3 Issue Type: Bug Components: Bootstrap & Build, Logging Affects Versions: 3.1.0 Reporter: Juan Pablo Santos RodrÃguez On our project we're using directly logback to start up a custom mbean to be able to change log levels dynamically, among other things. Most of these operations are Logback-specific, they're not available via SLF4J API For testing we use Jetty, so when we're doing an mvn jetty:run, the mbean gets init'd and we get an Exception stating "ClassCastException: org.slf4j.impl.SimpleLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext", due to slf4j-simple being on maven's lib. This is very likely to happen with other container plugins (tomcat7 et al) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2802) Concurrent-safe access to local Maven repository
[ https://jira.codehaus.org/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332341#comment-332341 ] Marc Guenther commented on MNG-2802: Is this still needed for Maven 3.0.5 or 3.1.0? Also I found a newer version of tesla-concurrent-localrepo (0.0.4), is that the one we should use? > Concurrent-safe access to local Maven repository > > > Key: MNG-2802 > URL: https://jira.codehaus.org/browse/MNG-2802 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Stepan Roh >Assignee: John Casey > Fix For: Issues to be reviewed for 3.x > > > It seems that access to local Maven repository is not concurrent-safe that is > multiple Mavens running in parallel may damage contents of local Maven > repository. It would be a nice improvement, because sharing of local > repository will lower the need for contacting any other repository. I know > that Maven proxy can be used, but that adds another layer which may > unnecessarily stress the machine it runs on. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-213) maven compiler plugin doesn't detect change in pom.xml
[
https://jira.codehaus.org/browse/MCOMPILER-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332355#comment-332355
]
Jigar Joshi commented on MCOMPILER-213:
---
For time being if I want to fix it against what should I compare pom.xml's file
modified timestamp ?
> maven compiler plugin doesn't detect change in pom.xml
> --
>
> Key: MCOMPILER-213
> URL: https://jira.codehaus.org/browse/MCOMPILER-213
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.0, 3.1
> Environment: any
>Reporter: Jigar Joshi
>Priority: Minor
>
> Background:
> we are using maven build to build around 200 project tree, change in one
> single module costs building whole tree, to avoid it we switched to
> incremental build and I wrote a plugin that will periodically do full clean
> build after configurable period of time
> Issue:
> maven-compiler-plugin supports incremental compilation and only compiles the
> source that was modified that is nice feature, however it is not quite
> working well in following cases
> - if there is a change in pom.xml (for example:change in dependency scope),
> it doesn't detect it as change and doesn't recompile that and all effecting
> projects
> {{org.apache.maven.plugin.compiler.AbstractCompilerMojo.isDependencyChanged()}}
> should cover it
> Verified this on revision {{1495788}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-213) maven compiler plugin doesn't detect change in pom.xml
[
https://jira.codehaus.org/browse/MCOMPILER-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332355#comment-332355
]
Jigar Joshi edited comment on MCOMPILER-213 at 9/4/13 1:08 PM:
---
For a quick fix (dirty way) if I want to fix it against what should I compare
pom.xml's file modified timestamp ?
was (Author: jigar.joshi):
For time being if I want to fix it against what should I compare pom.xml's
file modified timestamp ?
> maven compiler plugin doesn't detect change in pom.xml
> --
>
> Key: MCOMPILER-213
> URL: https://jira.codehaus.org/browse/MCOMPILER-213
> Project: Maven Compiler Plugin
> Issue Type: Bug
>Affects Versions: 3.0, 3.1
> Environment: any
>Reporter: Jigar Joshi
>Priority: Minor
>
> Background:
> we are using maven build to build around 200 project tree, change in one
> single module costs building whole tree, to avoid it we switched to
> incremental build and I wrote a plugin that will periodically do full clean
> build after configurable period of time
> Issue:
> maven-compiler-plugin supports incremental compilation and only compiles the
> source that was modified that is nice feature, however it is not quite
> working well in following cases
> - if there is a change in pom.xml (for example:change in dependency scope),
> it doesn't detect it as change and doesn't recompile that and all effecting
> projects
> {{org.apache.maven.plugin.compiler.AbstractCompilerMojo.isDependencyChanged()}}
> should cover it
> Verified this on revision {{1495788}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-846) m2 release plugin exposes SCM password in release.properties file
[ https://jira.codehaus.org/browse/MRELEASE-846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332370#comment-332370 ] Robert Scholte commented on MRELEASE-846: - I would expect that this is possible if the Jenkins instance has a [master-password|http://maven.apache.org/guides/mini/guide-encryption.html#How_to_create_a_master_password]. This plugin still needs to implement the encryption/decryption methods, but that's not too hard. I even think this should always be done if there's a master-password. > m2 release plugin exposes SCM password in release.properties file > - > > Key: MRELEASE-846 > URL: https://jira.codehaus.org/browse/MRELEASE-846 > Project: Maven Release Plugin > Issue Type: Bug >Reporter: Mark Maun > > When executing a maven release build using the m2 release plugin in Jenkins a > release.properties file is created in the workspace that has the SCM > user/password credentials in plain text. In our jenkins instance this is a > problem since we have multiple users with access to release the same job. The > release.properties is removed after the release build is successful. If the > release build fails the release.properties stays in the workspace until it's > manually deleted. This allows other users to see SCM passwords in our > organization if they view the workspace during a release build or after one > fails. > 4 > If anyone has viable workarounds/solutions we can use in the meantime that > would also be appreciated. > Note I have a ticket open with Jenkins dev but they deferred me here: > https://issues.jenkins-ci.org/browse/JENKINS-19416 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1029) Report suppressed exceptions
Andrew Gaul created SUREFIRE-1029: - Summary: Report suppressed exceptions Key: SUREFIRE-1029 URL: https://jira.codehaus.org/browse/SUREFIRE-1029 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Affects Versions: 2.16 Reporter: Andrew Gaul Attachments: AutoCloseableMain.java, AutoCloseableTest.java Surefire only reports the exception from a try-with-resources body, not any suppressed exceptions from close methods. I see this behavior from the attached AutoCloseableMain.java: Exception in thread "main" java.io.IOException: from body at AutoCloseableMain.main(AutoCloseableMain.java:9) Suppressed: java.io.IOException: from close at ThrowIOExceptionOnClose.close(AutoCloseableMain.java:17) at AutoCloseableMain.main(AutoCloseableMain.java:10) I see a different behavior from the attached AutoCloseableTest.java: java.io.IOException: from body at com.maginatics.AutoCloseableTest.testAutoCloseable(AutoCloseableTest.java:14) Surefire could call Throwable.getSuppressed via reflection to maintain compatibility with earlier versions of Java. Refer to Guava Closer which does something similar. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1029) Report suppressed exceptions
[
https://jira.codehaus.org/browse/SUREFIRE-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Gaul updated SUREFIRE-1029:
--
Affects Version/s: 2.15
> Report suppressed exceptions
>
>
> Key: SUREFIRE-1029
> URL: https://jira.codehaus.org/browse/SUREFIRE-1029
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.15, 2.16
>Reporter: Andrew Gaul
> Attachments: AutoCloseableMain.java, AutoCloseableTest.java
>
>
> Surefire only reports the exception from a try-with-resources body, not any
> suppressed exceptions from close methods. I see this behavior from the
> attached AutoCloseableMain.java:
> {code}
> Exception in thread "main" java.io.IOException: from body
> at AutoCloseableMain.main(AutoCloseableMain.java:9)
> Suppressed: java.io.IOException: from close
> at ThrowIOExceptionOnClose.close(AutoCloseableMain.java:17)
> at AutoCloseableMain.main(AutoCloseableMain.java:10)
> {code}
> I see a different behavior from the attached AutoCloseableTest.java:
> {code}
> java.io.IOException: from body
> at
> com.maginatics.AutoCloseableTest.testAutoCloseable(AutoCloseableTest.java:14)
> {code}
> Surefire could call Throwable.getSuppressed via reflection to maintain
> compatibility with earlier versions of Java. Refer to Guava Closer which
> does something similar.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1029) Report suppressed exceptions
[
https://jira.codehaus.org/browse/SUREFIRE-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Gaul updated SUREFIRE-1029:
--
Description:
Surefire only reports the exception from a try-with-resources body, not any
suppressed exceptions from close methods. I see this behavior from the
attached AutoCloseableMain.java:
{code}
Exception in thread "main" java.io.IOException: from body
at AutoCloseableMain.main(AutoCloseableMain.java:9)
Suppressed: java.io.IOException: from close
at ThrowIOExceptionOnClose.close(AutoCloseableMain.java:17)
at AutoCloseableMain.main(AutoCloseableMain.java:10)
{code}
I see a different behavior from the attached AutoCloseableTest.java:
{code}
java.io.IOException: from body
at
com.maginatics.AutoCloseableTest.testAutoCloseable(AutoCloseableTest.java:14)
{code}
Surefire could call Throwable.getSuppressed via reflection to maintain
compatibility with earlier versions of Java. Refer to Guava Closer which does
something similar.
was:
Surefire only reports the exception from a try-with-resources body, not any
suppressed exceptions from close methods. I see this behavior from the
attached AutoCloseableMain.java:
{{
Exception in thread "main" java.io.IOException: from body
at AutoCloseableMain.main(AutoCloseableMain.java:9)
Suppressed: java.io.IOException: from close
at ThrowIOExceptionOnClose.close(AutoCloseableMain.java:17)
at AutoCloseableMain.main(AutoCloseableMain.java:10)
}}
I see a different behavior from the attached AutoCloseableTest.java:
{{
java.io.IOException: from body
at
com.maginatics.AutoCloseableTest.testAutoCloseable(AutoCloseableTest.java:14)
}}
Surefire could call Throwable.getSuppressed via reflection to maintain
compatibility with earlier versions of Java. Refer to Guava Closer which does
something similar.
> Report suppressed exceptions
>
>
> Key: SUREFIRE-1029
> URL: https://jira.codehaus.org/browse/SUREFIRE-1029
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Andrew Gaul
> Attachments: AutoCloseableMain.java, AutoCloseableTest.java
>
>
> Surefire only reports the exception from a try-with-resources body, not any
> suppressed exceptions from close methods. I see this behavior from the
> attached AutoCloseableMain.java:
> {code}
> Exception in thread "main" java.io.IOException: from body
> at AutoCloseableMain.main(AutoCloseableMain.java:9)
> Suppressed: java.io.IOException: from close
> at ThrowIOExceptionOnClose.close(AutoCloseableMain.java:17)
> at AutoCloseableMain.main(AutoCloseableMain.java:10)
> {code}
> I see a different behavior from the attached AutoCloseableTest.java:
> {code}
> java.io.IOException: from body
> at
> com.maginatics.AutoCloseableTest.testAutoCloseable(AutoCloseableTest.java:14)
> {code}
> Surefire could call Throwable.getSuppressed via reflection to maintain
> compatibility with earlier versions of Java. Refer to Guava Closer which
> does something similar.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1029) Report suppressed exceptions
[
https://jira.codehaus.org/browse/SUREFIRE-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Gaul updated SUREFIRE-1029:
--
Description:
Surefire only reports the exception from a try-with-resources body, not any
suppressed exceptions from close methods. I see this behavior from the
attached AutoCloseableMain.java:
{{
Exception in thread "main" java.io.IOException: from body
at AutoCloseableMain.main(AutoCloseableMain.java:9)
Suppressed: java.io.IOException: from close
at ThrowIOExceptionOnClose.close(AutoCloseableMain.java:17)
at AutoCloseableMain.main(AutoCloseableMain.java:10)
}}
I see a different behavior from the attached AutoCloseableTest.java:
{{
java.io.IOException: from body
at
com.maginatics.AutoCloseableTest.testAutoCloseable(AutoCloseableTest.java:14)
}}
Surefire could call Throwable.getSuppressed via reflection to maintain
compatibility with earlier versions of Java. Refer to Guava Closer which does
something similar.
was:
Surefire only reports the exception from a try-with-resources body, not any
suppressed exceptions from close methods. I see this behavior from the
attached AutoCloseableMain.java:
Exception in thread "main" java.io.IOException: from body
at AutoCloseableMain.main(AutoCloseableMain.java:9)
Suppressed: java.io.IOException: from close
at ThrowIOExceptionOnClose.close(AutoCloseableMain.java:17)
at AutoCloseableMain.main(AutoCloseableMain.java:10)
I see a different behavior from the attached AutoCloseableTest.java:
java.io.IOException: from body
at
com.maginatics.AutoCloseableTest.testAutoCloseable(AutoCloseableTest.java:14)
Surefire could call Throwable.getSuppressed via reflection to maintain
compatibility with earlier versions of Java. Refer to Guava Closer which does
something similar.
> Report suppressed exceptions
>
>
> Key: SUREFIRE-1029
> URL: https://jira.codehaus.org/browse/SUREFIRE-1029
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Andrew Gaul
> Attachments: AutoCloseableMain.java, AutoCloseableTest.java
>
>
> Surefire only reports the exception from a try-with-resources body, not any
> suppressed exceptions from close methods. I see this behavior from the
> attached AutoCloseableMain.java:
> {{
> Exception in thread "main" java.io.IOException: from body
> at AutoCloseableMain.main(AutoCloseableMain.java:9)
> Suppressed: java.io.IOException: from close
> at ThrowIOExceptionOnClose.close(AutoCloseableMain.java:17)
> at AutoCloseableMain.main(AutoCloseableMain.java:10)
> }}
> I see a different behavior from the attached AutoCloseableTest.java:
> {{
> java.io.IOException: from body
> at
> com.maginatics.AutoCloseableTest.testAutoCloseable(AutoCloseableTest.java:14)
> }}
> Surefire could call Throwable.getSuppressed via reflection to maintain
> compatibility with earlier versions of Java. Refer to Guava Closer which
> does something similar.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-139) Change the default output file name so that it does not replace the ordinary jar
[ https://jira.codehaus.org/browse/MSHADE-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MSHADE-139: Attachment: patch.txt This patch file on the 2.1 release adds a parameter called "replaceOriginalArtifact", which defaults to true, but when false tells shade not to overwrite the original artifact. It also adds a check to see if the classifier parameter is set to blank when building the shaded artifact's id - the two features combined allow you to run shade with an output alternative artifact id (and no classifier) and the corresponding dependency-reduced-pom, which the installer plugin can then add to the repository with the specified alternative coordinates. > Change the default output file name so that it does not replace the ordinary > jar > > > Key: MSHADE-139 > URL: https://jira.codehaus.org/browse/MSHADE-139 > Project: Maven Shade Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Benson Margulies > Attachments: patch.txt > > > See http://markmail.org/message/kqbvju36nusvydwt > We could make incremental builds work righter by not overwriting the base jar > by default. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-154) Add ability for shade to find primary artifact from attached artifacts (similar to assembly-plugin)
[ https://jira.codehaus.org/browse/MSHADE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Sand updated MSHADE-154: Attachment: patch139and154.txt A patch file combining my submission for MSHADE-139 and this issue > Add ability for shade to find primary artifact from attached artifacts > (similar to assembly-plugin) > --- > > Key: MSHADE-154 > URL: https://jira.codehaus.org/browse/MSHADE-154 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 2.0 > Environment: all >Reporter: Richard Sand > Attachments: patch139and154.txt, patch.txt > > > When switching from assembly-plugin to shade-plugin for a given project, I > discovered that the shade plugin did not have the capability of using an > attached artifact as the primary artifact - only the project's main artifact > was supported. > I've attached changes to add a configuration parameter > "alternativeInputClassifier", which, when specified, tells the plugin to look > for an artifact with the specified classifier in the project attachments, and > to use that as the primary artifact. This makes shade behave similar to > assembly-plugin, and allows shade to recognize attached artifacts generated > by previous plugins in a maven execution. > This was a trivial change, but required modifying several other classes and > methods to accept the "primary" artifact as a parameter instead of a global > variable. IMHO these changes are good for the plugin as a whole, as it will > allow for future flexibility and logic for determining the entrypoint for the > plugin (e.g. being able to run as a standalone goal with a specific artifact > as input). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-154) Add ability for shade to find primary artifact from attached artifacts (similar to assembly-plugin)
[ https://jira.codehaus.org/browse/MSHADE-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332379#comment-332379 ] Richard Sand commented on MSHADE-154: - I also submitted a patch for MSHADE-139, so added a second patch file here with both my 139 and 154 changes. Thanks! > Add ability for shade to find primary artifact from attached artifacts > (similar to assembly-plugin) > --- > > Key: MSHADE-154 > URL: https://jira.codehaus.org/browse/MSHADE-154 > Project: Maven Shade Plugin > Issue Type: New Feature >Affects Versions: 2.0 > Environment: all >Reporter: Richard Sand > Attachments: patch139and154.txt, patch.txt > > > When switching from assembly-plugin to shade-plugin for a given project, I > discovered that the shade plugin did not have the capability of using an > attached artifact as the primary artifact - only the project's main artifact > was supported. > I've attached changes to add a configuration parameter > "alternativeInputClassifier", which, when specified, tells the plugin to look > for an artifact with the specified classifier in the project attachments, and > to use that as the primary artifact. This makes shade behave similar to > assembly-plugin, and allows shade to recognize attached artifacts generated > by previous plugins in a maven execution. > This was a trivial change, but required modifying several other classes and > methods to accept the "primary" artifact as a parameter instead of a global > variable. IMHO these changes are good for the plugin as a whole, as it will > allow for future flexibility and logic for determining the entrypoint for the > plugin (e.g. being able to run as a standalone goal with a specific artifact > as input). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-134) Shade plugin does not seem to be aware of the classifier setting for the jar plugin
[ https://jira.codehaus.org/browse/MSHADE-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332382#comment-332382 ] Richard Sand commented on MSHADE-134: - the patch I submitted in 154 solves this, sorry for the duplicate > Shade plugin does not seem to be aware of the classifier setting for the jar > plugin > --- > > Key: MSHADE-134 > URL: https://jira.codehaus.org/browse/MSHADE-134 > Project: Maven Shade Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Thomas Dudziak > > When using the classifier configuration for the jar plugin, e.g. > > org.apache.maven.plugins > maven-jar-plugin > 2.4 > > foo > > > then the shade plugin (in both attach or replace modes) complains about a > missing main artifact: > [ERROR] The project main artifact does not exist. This could have the > following > [ERROR] reasons: > [ERROR] - You have invoked the goal directly from the command line. This is > not > [ERROR] supported. Please add the goal to the default lifecycle via an > [ERROR]element in your POM and use "mvn package" to have it > run. > [ERROR] - You have bound the goal to a lifecycle phase before "package". > Please > [ERROR] remove this binding from your POM such that the goal will be run in > [ERROR] the proper phase. > [ERROR] - You removed the configuration of the maven-jar-plugin that produces > the main artifact. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1030) Remove nested exception wrappers
Andrew Gaul created SUREFIRE-1030: - Summary: Remove nested exception wrappers Key: SUREFIRE-1030 URL: https://jira.codehaus.org/browse/SUREFIRE-1030 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.16 Reporter: Andrew Gaul Priority: Minor Java 1.5 dependency is sufficient to get Throwable.getCause. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1030) Remove nested exception wrappers
[ https://jira.codehaus.org/browse/SUREFIRE-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332384#comment-332384 ] Andrew Gaul commented on SUREFIRE-1030: --- Pull request: https://github.com/apache/maven-surefire/pull/27 > Remove nested exception wrappers > > > Key: SUREFIRE-1030 > URL: https://jira.codehaus.org/browse/SUREFIRE-1030 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.16 >Reporter: Andrew Gaul >Priority: Minor > Attachments: SUREFIRE-1030.patch > > > Java 1.5 dependency is sufficient to get Throwable.getCause. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1030) Remove nested exception wrappers
[ https://jira.codehaus.org/browse/SUREFIRE-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Gaul updated SUREFIRE-1030: -- Attachment: SUREFIRE-1030.patch > Remove nested exception wrappers > > > Key: SUREFIRE-1030 > URL: https://jira.codehaus.org/browse/SUREFIRE-1030 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.16 >Reporter: Andrew Gaul >Priority: Minor > Attachments: SUREFIRE-1030.patch > > > Java 1.5 dependency is sufficient to get Throwable.getCause. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1029) Report suppressed exceptions
[
https://jira.codehaus.org/browse/SUREFIRE-1029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Gaul closed SUREFIRE-1029.
-
Resolution: Not A Bug
Setting trimStackTrace to false displays any cause or suppressed exceptions.
Unfortunately this emits stacks frames underneath the test method, limiting its
usefulness.
> Report suppressed exceptions
>
>
> Key: SUREFIRE-1029
> URL: https://jira.codehaus.org/browse/SUREFIRE-1029
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Plugin
>Affects Versions: 2.15, 2.16
>Reporter: Andrew Gaul
> Attachments: AutoCloseableMain.java, AutoCloseableTest.java
>
>
> Surefire only reports the exception from a try-with-resources body, not any
> suppressed exceptions from close methods. I see this behavior from the
> attached AutoCloseableMain.java:
> {code}
> Exception in thread "main" java.io.IOException: from body
> at AutoCloseableMain.main(AutoCloseableMain.java:9)
> Suppressed: java.io.IOException: from close
> at ThrowIOExceptionOnClose.close(AutoCloseableMain.java:17)
> at AutoCloseableMain.main(AutoCloseableMain.java:10)
> {code}
> I see a different behavior from the attached AutoCloseableTest.java:
> {code}
> java.io.IOException: from body
> at
> com.maginatics.AutoCloseableTest.testAutoCloseable(AutoCloseableTest.java:14)
> {code}
> Surefire could call Throwable.getSuppressed via reflection to maintain
> compatibility with earlier versions of Java. Refer to Guava Closer which
> does something similar.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-155) dependency-reduced-pom should use shadedArtifactId
Richard Sand created MSHADE-155: --- Summary: dependency-reduced-pom should use shadedArtifactId Key: MSHADE-155 URL: https://jira.codehaus.org/browse/MSHADE-155 Project: Maven Shade Plugin Issue Type: Bug Affects Versions: 2.0 Environment: version 2.1, maven 3.0.5 Reporter: Richard Sand When supplying the shadedArtifactId parameter and generate a dependency-reduced-pom, the reduced pom should use this artifactId. This is a 1-line fix in ShadeMojo.createDependencyReducedPom() - simply add: model.setArtifactId(shadedArtifactId); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1030) Remove nested exception wrappers
[ https://jira.codehaus.org/browse/SUREFIRE-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian updated SUREFIRE-1030: - Fix Version/s: 2.17 > Remove nested exception wrappers > > > Key: SUREFIRE-1030 > URL: https://jira.codehaus.org/browse/SUREFIRE-1030 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.16 >Reporter: Andrew Gaul >Priority: Minor > Fix For: 2.17 > > Attachments: SUREFIRE-1030.patch > > > Java 1.5 dependency is sufficient to get Throwable.getCause. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1028) Unable to run single test (junit)
[
https://jira.codehaus.org/browse/SUREFIRE-1028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1028:
-
Fix Version/s: 2.17
> Unable to run single test (junit)
> -
>
> Key: SUREFIRE-1028
> URL: https://jira.codehaus.org/browse/SUREFIRE-1028
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Diwaker Gupta
>Priority: Critical
> Fix For: 2.17
>
>
> This is a regression from 2.15. It also looks like Surefire keeps regressing
> on this feature (e.g. see SUREFIRE-827) -- are there no unit or integration
> tests to prevent such regressions?
> With Surefire 2.15
> {noformat}
> $ mvn test -Dtest=MyTest#testFoo
> ...
> Results :
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> With Surefire 2.16
> {noformat}
> $ mvn test -Dtest=MyTest#testFoo
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1030) Remove nested exception wrappers
[ https://jira.codehaus.org/browse/SUREFIRE-1030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=332387#comment-332387 ] Andreas Gudian commented on SUREFIRE-1030: -- Yeah, Code-cleanup for president! > Remove nested exception wrappers > > > Key: SUREFIRE-1030 > URL: https://jira.codehaus.org/browse/SUREFIRE-1030 > Project: Maven Surefire > Issue Type: Improvement >Affects Versions: 2.16 >Reporter: Andrew Gaul >Priority: Minor > Fix For: 2.17 > > Attachments: SUREFIRE-1030.patch > > > Java 1.5 dependency is sufficient to get Throwable.getCause. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
