[jira] Created: (SUREFIRE-561) after running test, when tests fail, it's hard to the find the failure reason
after running test, when tests fail, it's hard to the find the failure reason - Key: SUREFIRE-561 URL: http://jira.codehaus.org/browse/SUREFIRE-561 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.4.3 Reporter: Szczepan Faber Maven surefire has been here for a while but still I'm missing this feature. When my tests fail, I'd like to know exact failure reason. 1. Surefire summary does not show the stack trace / line number / assertion. Browsing results files in target dir is frustrating time consuming. 2. It is impossible to use surefire-report plugin in fully automated way. If I plug report-only goal to phase test, this goal is not executed when phase test fails Current workaround in my project is that every maven submodule has a handy batch file with 'mvn surefire-report:report-only'. One of the ways of implementing it is adding stacktrace/assertion information in test summary. What do you guys think about this idea? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-561) after running test, when tests fail, it's hard to the find the failure reason
[ http://jira.codehaus.org/browse/SUREFIRE-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=185155#action_185155 ] Szczepan Faber commented on SUREFIRE-561: - No I haven't - it didn't occur me at all that this option can be any helpful. Thanks for the hint! Anyway, I will see how useful it is and get back. after running test, when tests fail, it's hard to the find the failure reason - Key: SUREFIRE-561 URL: http://jira.codehaus.org/browse/SUREFIRE-561 Project: Maven Surefire Issue Type: Improvement Affects Versions: 2.4.3 Reporter: Szczepan Faber Maven surefire has been here for a while but still I'm missing this feature. When my tests fail, I'd like to know exact failure reason. 1. Surefire summary does not show the stack trace / line number / assertion. Browsing results files in target dir is frustrating time consuming. 2. It is impossible to use surefire-report plugin in fully automated way. If I plug report-only goal to phase test, this goal is not executed when phase test fails Current workaround in my project is that every maven submodule has a handy batch file with 'mvn surefire-report:report-only'. One of the ways of implementing it is adding stacktrace/assertion information in test summary. What do you guys think about this idea? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPMD-96) Invalid pom.xml generated due to stale version of PMD
Invalid pom.xml generated due to stale version of PMD - Key: MPMD-96 URL: http://jira.codehaus.org/browse/MPMD-96 Project: Maven 2.x PMD Plugin Issue Type: Bug Components: PMD Affects Versions: 2.4 Reporter: Szczepan Faber PMD 4.2.2 seems to have a bug: pom.xml sometimes is incorrect - empty pmd/f...@name attribute and therefore how one knows where to fix the violation? See more information in this thread [hudson mailing list] https://hudson.dev.java.net/servlets/ReadMsg?listName=usersmsgNo=18907 PMD 4.2.5 does not have this problem therefore you might consider releasing new version of maven pmd plugin that uses pmd 4.2.5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-714) When artifact not found on mirror the real site isn't checked
[ http://jira.codehaus.org/browse/MNG-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158471#action_158471 ] Szczepan Faber commented on MNG-714: There are number reasons this is a valuable feature: -ability to implement simple fail-over system with two mirrors mirroring the same repo(s) -currently, if there are mirrors with the same value of mirrorOf, last mirror wins and previous mirrors are silently ignored. Not very nice... -some folks from my company have to change the settings file every time they go home because at home they don't have proxy. Quite annoying... Is it going to be released into maven? Is improving maven in the agenda of maven roadmap? When artifact not found on mirror the real site isn't checked - Key: MNG-714 URL: http://jira.codehaus.org/browse/MNG-714 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0-beta-1 Reporter: Kenney Westerhof Assignee: Jason van Zyl Fix For: 3.x Attachments: MNG-714-maven-artifact-manager.patch Original Estimate: 3 hours Remaining Estimate: 3 hours I'm using the settings.xml mirror feature as a local cache. Periodically I upload my local repo to the webserver specified as mirror. When an artifact cannot be found on the mirror, the original site isn't checked (and possibly the rest of the sites). I'm not sure what the exact function of the mirror is (except caching?), but repo1 is checked often regardless of mirror presence, so I figure it's not meant to totally disable checking the central repo's. Simple reproduction: define a few mirrors in your settings.xml for central, central-plugins and snapshots, pointing to say file://tmp/empty/dir/. Stacktrace: [DEBUG] Error resolving artifact version from metadata. org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate resource in repository at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:81) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:70) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:343) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:263) at org.apache.maven.artifact.metadata.AbstractVersionArtifactMetadata.retrieveFromRemoteRepository(AbstractVersionArtifactMetadata.java:93) at org.apache.maven.artifact.transform.AbstractVersionTransformation.retrieveFromRemoteRepository(AbstractVersionTransformation.java:171) at org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion(AbstractVersionTransformation.java:96) at org.apache.maven.artifact.transform.SnapshotTransformation.transformForResolve(SnapshotTransformation.java:43) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:95) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:290) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:274) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:81) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:186) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:197) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:185) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:156) at org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:544) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:479) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:334) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:378) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:351) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:337)
[jira] Commented: (MAVENUPLOAD-2261) Automatic upload of mockito versions.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=154646#action_154646 ] Szczepan Faber commented on MAVENUPLOAD-2261: - Is there something missing in this request that makes executing it so slow? It seems upload request via rsync is not really faster Automatic upload of mockito versions. - Key: MAVENUPLOAD-2261 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2261 Project: Maven Upload Requests Issue Type: Wish Reporter: Erik Brakkee Authenticity = Please contact Szczepan Faber for information about the authenticity of this request. He is the owner of the mockito.org domain. Also, my name will appear shortly on the mockito wiki at http://code.google.com/p/mockito/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2261) Automatic upload of mockito versions.
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=153144#action_153144 ] Szczepan Faber commented on MAVENUPLOAD-2261: - Erik Brakkee helps us getting mockito jars quickly to maven central - as written at the bottom of http://mockito.org. Thanks a lot! Szczepan Faber Automatic upload of mockito versions. - Key: MAVENUPLOAD-2261 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2261 Project: Maven Upload Requests Issue Type: Wish Reporter: Erik Brakkee Authenticity = Please contact Szczepan Faber for information about the authenticity of this request. He is the owner of the mockito.org domain. Also, my name will appear shortly on the mockito wiki at http://code.google.com/p/mockito/. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3772) mirrors should allow specifying multiple alternate locations
mirrors should allow specifying multiple alternate locations Key: MNG-3772 URL: http://jira.codehaus.org/browse/MNG-3772 Project: Maven 2 Issue Type: Improvement Components: Settings Affects Versions: 2.0.9 Reporter: Szczepan Faber In maven 2.0.9, when multiple mirrors are specified with the same mirrorOf value, only the last mirror is used. I would like the mirrors to handle multiple alternate locations. Benefits: -ability to implement simple fail-over system with two mirrors mirroring the same repo(s) -increased intuitiveness. Currently, if you have 2 mirrors with the same mirrorOf then the first mirror is ignored. Last mirror wins but I couldn't find the info about it in the docs. I can provide a patch if maven guys are interested in merging this improvement to maven. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MPMD-32) Add minimumPriority parameter so maven runs rules with higher or equal priority
[ http://jira.codehaus.org/browse/MPMD-32?page=all ] Szczepan Faber updated MPMD-32: --- Attachment: MPMD-32-maven-pmd-plugin.patch Add minimumPriority parameter so maven runs rules with higher or equal priority --- Key: MPMD-32 URL: http://jira.codehaus.org/browse/MPMD-32 Project: Maven 2.x Pmd Plugin Type: New Feature Versions: 2.1 Reporter: Szczepan Faber Priority: Minor Fix For: 2.1 Attachments: MPMD-32-maven-pmd-plugin.patch Original Estimate: 1 hour Remaining: 1 hour Add minimumPriority parameter so maven runs rules with higher or equal priority. Implementation of pmd ant task property minimumPriority. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
