[jira] (MCHECKSTYLE-167) Unconfigured checkstyle plugin duplicates entries in aggregated report
[
https://jira.codehaus.org/browse/MCHECKSTYLE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297602#comment-297602
]
Andrew Hunt commented on MCHECKSTYLE-167:
-
Not sure that the reported fix to the count problem MCHECKSTYLE-167 has been
fixed in the checkstyle-aggregate report. If you have a look at
http://maven.apache.org/plugins/maven-checkstyle-plugin/project-reports.html,
you will see the report repetition AND that the first report has double the
issues of the second report. In the checkstyle-aggregate report, each error is
reported twice.
> Unconfigured checkstyle plugin duplicates entries in aggregated report
> --
>
> Key: MCHECKSTYLE-167
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-167
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.8
> 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: Mirko Friedenhagen
>Assignee: Olivier Lamy
> Fix For: 2.9
>
> Attachments: checkstyle-report-duplicates-errors-in-aggregate.zip,
> checkstyle.zip
>
>
> Using a very simple single module project, the aggregated report is created
> by default and reports an incorrect number of violations, it just doubles the
> numbers. I checked out
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-checkstyle-plugin-2.8
> and modified the integration test project {{checkstyle-report}} a little bit:
> * I deleted the {{reportSets}} configuration from the {{pom.xml}}.
> * I modified {{src/main/java/org/MyClass.java}} to actually have errors.
> The build log looks like this:
> {code}
> [mirko@borg checkstyle-report]$ mvn clean site
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building check-pass 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ check-pass ---
> [INFO] Deleting
> /Users/mirko/Documents/workspace/maven-checkstyle-plugin/target/it/checkstyle-report/target
> [INFO]
> [INFO] --- maven-site-plugin:3.0:site (default-site) @ check-pass ---
> [INFO] configuring report plugin
> org.apache.maven.plugins:maven-checkstyle-plugin:2.8
> [INFO] Relativizing decoration links with respect to project URL:
> http://maven.apache.org/
> [INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0
> skin.
> [INFO] Generating "Checkstyle" report--- maven-checkstyle-plugin:2.8
> [INFO]
> [INFO] There are 2 checkstyle errors.
> [WARNING] Unable to locate Source XRef to link to - DISABLED
> [INFO] Generating "Checkstyle" report--- maven-checkstyle-plugin:2.8
> [INFO]
> [INFO] There are 4 checkstyle errors.
> [WARNING] Unable to locate Source XRef to link to - DISABLED
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 4.847s
> [INFO] Finished at: Tue Nov 29 21:13:40 CET 2011
> [INFO] Final Memory: 12M/81M
> [INFO]
>
> {code}
> {{target/checkstyle-result.xml}} looks like this and reports the same errors
> twice:
> {code}
>
>
> name="/Users/mirko/Documents/workspace/maven-checkstyle-plugin/target/it/checkstyle-report/src/main/java/org/MyClass.java">
> source="com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck"/>
> source="com.puppycrawl.tools.checkstyle.checks.FinalParametersCheck"/>
>
> name="/Users/mirko/Documents/workspace/maven-checkstyle-plugin/target/it/checkstyle-report/src/main/java/org/MyClass.java">
> source="com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocMethodCheck"/>
> source="com.puppycrawl.tools.checkstyle.checks.FinalParametersCheck"/>
>
>
> {code}
> Both the {{checkstyle}} and {{checkstyle-aggregate}} report are generated and
> {{checkstyle-aggregate}} reports the same errors twice. I attach the patched
> project which includes a check in {{verify.groovy}} to assert that only one
> {{file}} entry is present in the created {{target/checkstyle-result.xml}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please c
[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=297601#comment-297601
]
Andrew Hunt commented on MCHECKSTYLE-172:
-
Not sure that the reported fix to the count problem MCHECKSTYLE-167 has been
fixed in the checkstyle-aggregate report. If you have a look at
http://maven.apache.org/plugins/maven-checkstyle-plugin/project-reports.html,
you will see the report repetition AND that the first report has double the
issues of the second report. In the checkstyle-aggregate report, each error is
reported twice.
> 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
>
> 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] (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=297601#comment-297601
]
Andrew Hunt edited comment on MCHECKSTYLE-172 at 5/1/12 3:11 AM:
-
Not sure that the reported fix to the count problem MCHECKSTYLE-167 has been
fixed in the checkstyle-aggregate report. If you have a look at
http://maven.apache.org/plugins/maven-checkstyle-plugin/project-reports.html,
you will see the report repetition AND that the first report has double the
issues of the second report. In the checkstyle-aggregate report, each error is
reported twice.
The workaround works great!
was (Author: andrew.hunt):
Not sure that the reported fix to the count problem MCHECKSTYLE-167 has
been fixed in the checkstyle-aggregate report. If you have a look at
http://maven.apache.org/plugins/maven-checkstyle-plugin/project-reports.html,
you will see the report repetition AND that the first report has double the
issues of the second report. In the checkstyle-aggregate report, each error is
reported twice.
> 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
>
> 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] (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=297601#comment-297601
]
Andrew Hunt edited comment on MCHECKSTYLE-172 at 5/1/12 3:14 AM:
-
Not sure that the reported fix to the count problem MCHECKSTYLE-167 has been
fixed in the checkstyle-aggregate report. If you have a look at
http://maven.apache.org/plugins/maven-checkstyle-plugin/project-reports.html,
you will see the report repetition AND that the first report has double the
issues of the second report. In the checkstyle-aggregate report, each error is
reported twice.
The workaround works great, though with this minor adjustment...
{panel}
...
org.apache.maven.plugins
maven-checkstyle-plugin
2.9
false
checkstyle
group_default_checkstyles.xml
...
{panel}
was (Author: andrew.hunt):
Not sure that the reported fix to the count problem MCHECKSTYLE-167 has
been fixed in the checkstyle-aggregate report. If you have a look at
http://maven.apache.org/plugins/maven-checkstyle-plugin/project-reports.html,
you will see the report repetition AND that the first report has double the
issues of the second report. In the checkstyle-aggregate report, each error is
reported twice.
The workaround works great!
> 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
>
> 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] (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=297601#comment-297601
]
Andrew Hunt edited comment on MCHECKSTYLE-172 at 5/1/12 3:16 AM:
-
Not sure that the reported fix to the count problem MCHECKSTYLE-167 has been
fixed in the checkstyle-aggregate report. If you have a look at
http://maven.apache.org/plugins/maven-checkstyle-plugin/project-reports.html,
you will see the report repetition AND that the first report has double the
issues of the second report. In the checkstyle-aggregate report, each error is
reported twice.
The workaround works great, though with this minor adjustment...
{code}
...
org.apache.maven.plugins
maven-checkstyle-plugin
2.9
false
checkstyle
group_default_checkstyles.xml
...
{code}
was (Author: andrew.hunt):
Not sure that the reported fix to the count problem MCHECKSTYLE-167 has
been fixed in the checkstyle-aggregate report. If you have a look at
http://maven.apache.org/plugins/maven-checkstyle-plugin/project-reports.html,
you will see the report repetition AND that the first report has double the
issues of the second report. In the checkstyle-aggregate report, each error is
reported twice.
The workaround works great, though with this minor adjustment...
{panel}
...
org.apache.maven.plugins
maven-checkstyle-plugin
2.9
false
checkstyle
group_default_checkstyles.xml
...
{panel}
> 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
>
> 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] (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=297601#comment-297601
]
Andrew Hunt edited comment on MCHECKSTYLE-172 at 5/1/12 3:18 AM:
-
Not sure that the reported fix to the count problem MCHECKSTYLE-167 has been
fixed in the checkstyle-aggregate report. If you have a look at
http://maven.apache.org/plugins/maven-checkstyle-plugin/project-reports.html,
you will see the report repetition AND that the first report has double the
issues of the second report. In the checkstyle-aggregate report, each error is
reported twice.
The workaround works great, though with this minor adjustment (full
definition)...
{code}
...
org.apache.maven.plugins
maven-checkstyle-plugin
2.9
false
checkstyle
group_default_checkstyles.xml
...
{code}
was (Author: andrew.hunt):
Not sure that the reported fix to the count problem MCHECKSTYLE-167 has
been fixed in the checkstyle-aggregate report. If you have a look at
http://maven.apache.org/plugins/maven-checkstyle-plugin/project-reports.html,
you will see the report repetition AND that the first report has double the
issues of the second report. In the checkstyle-aggregate report, each error is
reported twice.
The workaround works great, though with this minor adjustment...
{code}
...
org.apache.maven.plugins
maven-checkstyle-plugin
2.9
false
checkstyle
group_default_checkstyles.xml
...
{code}
> 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
>
> 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] (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=297601#comment-297601
]
Andrew Hunt edited comment on MCHECKSTYLE-172 at 5/1/12 3:19 AM:
-
Not sure that the reported fix to the count problem MCHECKSTYLE-167 has been
fixed in the checkstyle-aggregate report. If you have a look at
http://maven.apache.org/plugins/maven-checkstyle-plugin/project-reports.html,
you will see the report repetition AND that the first report has double the
issues of the second report. In the checkstyle-aggregate report, each error is
reported twice.
The workaround works great (in terms of providing one report and removing the
repeats), though I had to make a minor adjustment (my full config shown)...
{code}
...
org.apache.maven.plugins
maven-checkstyle-plugin
2.9
false
checkstyle
group_default_checkstyles.xml
...
{code}
was (Author: andrew.hunt):
Not sure that the reported fix to the count problem MCHECKSTYLE-167 has
been fixed in the checkstyle-aggregate report. If you have a look at
http://maven.apache.org/plugins/maven-checkstyle-plugin/project-reports.html,
you will see the report repetition AND that the first report has double the
issues of the second report. In the checkstyle-aggregate report, each error is
reported twice.
The workaround works great, though with this minor adjustment (full
definition)...
{code}
...
org.apache.maven.plugins
maven-checkstyle-plugin
2.9
false
checkstyle
group_default_checkstyles.xml
...
{code}
> 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
>
> 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] (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=296447#comment-296447
]
SebbASF edited comment on MCHECKSTYLE-172 at 5/1/12 4:52 AM:
-
Work-round (see [1]):
{code}
.
org.apache.maven.plugins
maven-checkstyle-plugin
2.8
false
checkstyle
...
{code}
[1]
http://www.mailinglistarchive.com/html/us...@maven.apache.org/2011-12/msg00134.html
was (Author: sebbasf):
Work-round (see [1]):
{code}
.
org.apache.maven.plugins
maven-checkstyle-plugin
2.8
false
checkstyle-aggregate
...
{code}
[1]
http://www.mailinglistarchive.com/html/us...@maven.apache.org/2011-12/msg00134.html
> 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
>
> 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] (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=297608#comment-297608
]
SebbASF commented on MCHECKSTYLE-172:
-
@Andrew: thanks, fixed incorrect copy-paste in my earlier comment.
> 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
>
> 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] (SUREFIRE-863) NPE in ConcurrentReporterManager
Mark Struberg created SUREFIRE-863: -- Summary: NPE in ConcurrentReporterManager Key: SUREFIRE-863 URL: https://jira.codehaus.org/browse/SUREFIRE-863 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12 Reporter: Mark Struberg I have a wird NPE in surefire with one of my projects: Caused by: java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) at org.apache.maven.surefire.junitcore.ConcurrentReporterManager.getTestSet(ConcurrentReporterManager.java:157) at org.apache.maven.surefire.junitcore.ConcurrentReporterManager.getOrCreateTestMethod(ConcurrentReporterManager.java:127) at org.apache.maven.surefire.junitcore.ConcurrentReporterManager.testError(ConcurrentReporterManager.java:83) at org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:110) at org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100) -- 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-863) NPE in ConcurrentReporterManager
[ https://jira.codehaus.org/browse/SUREFIRE-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297609#comment-297609 ] Mark Struberg commented on SUREFIRE-863: How to reproduce: I did hit this problem when updating Apache DeltaSpike from surefire-2.11 to 2.12. $> git clone https://git-wip-us.apache.org/repos/asf/incubator-deltaspike.git $> cd incubator-deltaspike/deltaspike $> mvn clean install -PWeld -Dweld.version=1.1.4.Final -Dmaven.surefire.plugin.version=2.13-SNAPSHOT The funny thing is that the same project works with another container (just remove the -PWeld and you'll get OpenWebBeans as CDI container) and even with another version of Weld. Compiling with -Dweld.version=1.1.5.Final works, but 1.1.7.Final is broken again. > NPE in ConcurrentReporterManager > > > Key: SUREFIRE-863 > URL: https://jira.codehaus.org/browse/SUREFIRE-863 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12 >Reporter: Mark Struberg > > I have a wird NPE in surefire with one of my projects: > Caused by: java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.getTestSet(ConcurrentReporterManager.java:157) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.getOrCreateTestMethod(ConcurrentReporterManager.java:127) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.testError(ConcurrentReporterManager.java:83) > at > org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:110) > at > org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100) -- 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-863) NPE in ConcurrentReporterManager
[ https://jira.codehaus.org/browse/SUREFIRE-863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297611#comment-297611 ] Mark Struberg commented on SUREFIRE-863: it seems this problem happens if the test setup hits a NoClassDefFound or similar: In ConcurrentReporterManager#testError I get failure set to: "Could not create a new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor see cause." Will try to create a unit test for it. > NPE in ConcurrentReporterManager > > > Key: SUREFIRE-863 > URL: https://jira.codehaus.org/browse/SUREFIRE-863 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12 >Reporter: Mark Struberg > > I have a wird NPE in surefire with one of my projects: > Caused by: java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.getTestSet(ConcurrentReporterManager.java:157) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.getOrCreateTestMethod(ConcurrentReporterManager.java:127) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.testError(ConcurrentReporterManager.java:83) > at > org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:110) > at > org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100) -- 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-863) NPE in ConcurrentReporterManager
[ https://jira.codehaus.org/browse/SUREFIRE-863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated SUREFIRE-863: --- Attachment: SUREFIRE-863.patch This patch fixes the bug. Our test now runs fine even with the missing class as it will get properly handled by the Arquillian runner. I do not like to apply it yet before having a proper unit test though... > NPE in ConcurrentReporterManager > > > Key: SUREFIRE-863 > URL: https://jira.codehaus.org/browse/SUREFIRE-863 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12 >Reporter: Mark Struberg > Attachments: SUREFIRE-863.patch > > > I have a wird NPE in surefire with one of my projects: > Caused by: java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.getTestSet(ConcurrentReporterManager.java:157) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.getOrCreateTestMethod(ConcurrentReporterManager.java:127) > at > org.apache.maven.surefire.junitcore.ConcurrentReporterManager.testError(ConcurrentReporterManager.java:83) > at > org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:110) > at > org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100) -- 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-640) Maven searches only central repository for imported dependencies
[
https://jira.codehaus.org/browse/MSITE-640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297616#comment-297616
]
Edward Winston commented on MSITE-640:
--
We recently ran into this problem as well. It was confusing because it was
working on my local machine and not on the server. As a work around, it
appears that if the parent pom in question is installed in your local
repository instead of retrieved from a remote repository things will work.
This means that in you ${HOME}/.m2/repository directory find the artifact in
question. Then change the file _maven.repositories to not have the location
from where the pom was downloaded. In our case the file went from this :
bq. parent-pom-1.pom>central=
to this :
bq. parent-pom-1.pom>=
After this change it all worked.
> Maven searches only central repository for imported dependencies
>
>
> Key: MSITE-640
> URL: https://jira.codehaus.org/browse/MSITE-640
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: Maven 3
>Affects Versions: 3.0
> Environment: Windows 7
>Reporter: Markus Tippmann
> Attachments: stacktrace.txt
>
>
> We are using dependencyManagement with "import" scope like described here:
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
> Problem occurs only at site generation, not at build time, where it works
> perfectly.
> The site plugin tries to find the imported artifacts, but searches only the
> central repository and ignores the repositories in settings.xml
> configuration. Mirror settings work, if "central" is mirrored, but
> dependencies need to be resolved from two repositories, so one mirror does
> not help here.
> I try to attach the relevant parts of the stacktrace.
--
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] (MDEP-194) ArchiverException when using maven dependency plugin in multi-module projects
[
https://jira.codehaus.org/browse/MDEP-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297639#comment-297639
]
Gili commented on MDEP-194:
---
Four years and counting. If you're not going to fix it anytime soon, please
provide a workaround! What are we supposed to do?
> ArchiverException when using maven dependency plugin in multi-module projects
> -
>
> Key: MDEP-194
> URL: https://jira.codehaus.org/browse/MDEP-194
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sascha Hofer
> Attachments:
> maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact2.patch,
> maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact.patch,
> plexus-archiver-1.0-alpha-9-DirectoryUnArchiver.diff
>
>
> Having the following module hierarchy the _unpack-dependencies_ goal of the
> _maven-dependency-plugin_ produces an _ArchiverException_.
> * A
> ** B
> ** C (depends on B)
> I took a quick look into the code and found that when unpacking the
> dependencies of module *C* the method _unpack(File, File, String, String)_ of
> class _org.apache.maven.plugin.dependency.AbstractDependencyMojo_ gets passed
> the *target/classes* directory of *B* as source file (instead of the created
> jar).
> part of the pom.xml which caused the error:
> {noformat}
>
> multi-module-coverage
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> unpack-dependencies
> process-classes
>
> unpack-dependencies
>
>
>
> ${project.build.directory}/classes
> tests
>
>
>
>
>
>
>
> {noformat}
> exception:
> {noformat}
> org.codehaus.plexus.archiver.ArchiverException: The source must not be a
> directory.
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:174)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:107)
> at
> org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:266)
> at
> org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {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] (MDEP-194) ArchiverException when using maven dependency plugin in multi-module projects
[
https://jira.codehaus.org/browse/MDEP-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297640#comment-297640
]
Gili commented on MDEP-194:
---
Grr. Note to self, this error also occurs if you attempt to unpack a dependency
that requires a classifier but you omit it. Meaning, if you have:
* A
** B (classifier = foo)
** C (attempts to unpack B but without a classifier)
then C will throw an exception. If you add the classifier, however, it works.
> ArchiverException when using maven dependency plugin in multi-module projects
> -
>
> Key: MDEP-194
> URL: https://jira.codehaus.org/browse/MDEP-194
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Sascha Hofer
> Attachments:
> maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact2.patch,
> maven-dependency-plugin-2.5-SNAPSHOT-copy-artifact.patch,
> plexus-archiver-1.0-alpha-9-DirectoryUnArchiver.diff
>
>
> Having the following module hierarchy the _unpack-dependencies_ goal of the
> _maven-dependency-plugin_ produces an _ArchiverException_.
> * A
> ** B
> ** C (depends on B)
> I took a quick look into the code and found that when unpacking the
> dependencies of module *C* the method _unpack(File, File, String, String)_ of
> class _org.apache.maven.plugin.dependency.AbstractDependencyMojo_ gets passed
> the *target/classes* directory of *B* as source file (instead of the created
> jar).
> part of the pom.xml which caused the error:
> {noformat}
>
> multi-module-coverage
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> unpack-dependencies
> process-classes
>
> unpack-dependencies
>
>
>
> ${project.build.directory}/classes
> tests
>
>
>
>
>
>
>
> {noformat}
> exception:
> {noformat}
> org.codehaus.plexus.archiver.ArchiverException: The source must not be a
> directory.
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:174)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:107)
> at
> org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:266)
> at
> org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {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] (MRELEASE-719) No error when release:prepare with an already existing scm tag
[ https://jira.codehaus.org/browse/MRELEASE-719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRELEASE-719: Fix Version/s: (was: 2.3) 2.4 > No error when release:prepare with an already existing scm tag > -- > > Key: MRELEASE-719 > URL: https://jira.codehaus.org/browse/MRELEASE-719 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.2.1 >Reporter: Tony Chemit >Assignee: Olivier Lamy > Fix For: 2.4 > > > When releasing the mojo-parent (codehaus), I had to do the release twice but > I forgot to remove the scm tag. > The release:prepare did not complain about it (should have). -- 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] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.
[
https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-723:
Fix Version/s: (was: 2.3)
2.4
I've done some extra investigation: The git-scm-provider supports it, but
there's no {{GitScmTranslator}} and so the rewrite is skipped. So I can agree
with Mark that your proposal isn't the right solution.
I'll push this forward to 2.4, so we start preparing a new release.
> DCVS tagging commands should store the tag-name (or hash) in the the
> //project/scm/tag element.
> ---
>
> Key: MRELEASE-723
> URL: https://jira.codehaus.org/browse/MRELEASE-723
> Project: Maven 2.x Release Plugin
> Issue Type: New Feature
> Components: Git, Mercurial, Subversion
> Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05
> 14:58:54+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: Mirko Friedenhagen
> Fix For: 2.4
>
> Attachments: add-tag-to-release-poms-1329108.patch,
> add-tag-to-release-poms.patch
>
>
> With SVN the developerConnection and connection are
> updated to the "real" release URL, that is when I invoke release:prepare with
> a URL like:
> https://SVNSERVER/svn/REPO/myproject/branches/release it will be
> replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0
> which is fine because now you know which revision to checkout for
> building the release.
> With git there is no such possibility to realize this with rewriting
> the URL AFAIK. So I would have expected however, that maybe the
> //project/scm/tag
> element would be updated to reflect the fact, that the pom is the one
> of release, either to the "symbolic name" myproject-1.0 or to the hash
> of the tag.
> See http://markmail.org/thread/m77cvhqqq56krzzd as well.
--
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] (MRELEASE-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.
[ https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297647#comment-297647 ] Mirko Friedenhagen commented on MRELEASE-723: - Now I am confused :-) : my patch adds an GitScmTranslator (and HgScmTranslator). > DCVS tagging commands should store the tag-name (or hash) in the the > //project/scm/tag element. > --- > > Key: MRELEASE-723 > URL: https://jira.codehaus.org/browse/MRELEASE-723 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: Git, Mercurial, Subversion > Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 > 14:58:54+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: Mirko Friedenhagen > Fix For: 2.4 > > Attachments: add-tag-to-release-poms-1329108.patch, > add-tag-to-release-poms.patch > > > With SVN the developerConnection and connection are > updated to the "real" release URL, that is when I invoke release:prepare with > a URL like: > https://SVNSERVER/svn/REPO/myproject/branches/release it will be > replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0 > which is fine because now you know which revision to checkout for > building the release. > With git there is no such possibility to realize this with rewriting > the URL AFAIK. So I would have expected however, that maybe the > //project/scm/tag > element would be updated to reflect the fact, that the pom is the one > of release, either to the "symbolic name" myproject-1.0 or to the hash > of the tag. > See http://markmail.org/thread/m77cvhqqq56krzzd as well. -- 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] (MCOMPILER-136) The description of the skip parameter of the testCompile mojo is incorrect
[
https://jira.codehaus.org/browse/MCOMPILER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297648#comment-297648
]
Jesse Glick commented on MCOMPILER-136:
---
Probably it should mention {{-DskipTests}} interpreted by Surefire, which is
generally preferable: at least checks that tests compile, which does not take
much time and can be expected to be reliable on all platforms, while not
actually running them which might take a long time and be flaky.
> The description of the skip parameter of the testCompile mojo is incorrect
> --
>
> Key: MCOMPILER-136
> URL: https://jira.codehaus.org/browse/MCOMPILER-136
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Affects Versions: 2.3.2
> Environment: n/a
>Reporter: Anders Hammar
>Assignee: Benjamin Bentmann
>Priority: Trivial
> Fix For: 2.4
>
>
> The description of the skip parameter of TestCompilerMojo should read:
> "Set this to 'true' to bypass compilation of test sources."
> I also think that the text "Its use is NOT RECOMMENDED, but quite convenient
> on occasion." should be removed.
--
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] (MECLIPSE-682) Directory-shaped bundles are not unpacked
[
https://jira.codehaus.org/browse/MECLIPSE-682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=297652#comment-297652
]
Barrie Treloar commented on MECLIPSE-682:
-
I suspect this will be marked WONT_FIX.
eclipse:to-maven and eclipse:install-plugins are hacks to get Maven and Eclipse
PDE development working together.
And it never really panned out well.
I recommend migrating to Tycho for Maven Eclipse PDE development.
> Directory-shaped bundles are not unpacked
> -
>
> Key: MECLIPSE-682
> URL: https://jira.codehaus.org/browse/MECLIPSE-682
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.8
> Environment: Maven 3.0.2.
>Reporter: Giedrius Noreikis
>
> Steps to reproduce:
> 1. Install a directory-shaped bundle (e.g.
> {{org.eclipse.equinox.launcher.win32.win32.x86_1.1.2.R36x_v20101222}}) to a
> remote repository:
> {{mvn eclipse:to-maven -DeclipseDir=eclipse
> -DdeployTo=central::default::}}
> 2. Delete the bundle from the local {{eclipse/plugins}} directory.
> 3. Now get back the plugin from the Maven repository:
> {{mvn eclipse:install-plugins -DeclipseDir=eclipse}}
> Normally, one should end up with a directory (because {{Eclipse-BundleShape:
> dir}} was specifed in the bundle's manifest, and thus the generated pom has a
> {{true}} property), but a .jar file is
> created instead.
> This seems to be a compatibility with Maven 3 issue - I can't reproduce it on
> Maven 2.2.1.
--
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
