[jira] [Commented] (MCOMPILER-269) Support modulepath (Java9/Jigsaw)
[ https://issues.apache.org/jira/browse/MCOMPILER-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15521339#comment-15521339 ] Hudson commented on MCOMPILER-269: -- FAILURE: Integrated in Jenkins build maven-plugins #7313 (See [https://builds.apache.org/job/maven-plugins/7313/]) [MCOMPILER-269] Support modulepath (Java9/Jigsaw) Improve detection when modulePath should be used. (rfscholte: [http://svn.apache.org/viewvc/?view=rev&rev=1762228]) * (edit) maven-compiler-plugin/pom.xml * (edit) maven-compiler-plugin/src/it/MCOMPILER-268_modulepath/pom.xml * (edit) maven-compiler-plugin/src/it/MCOMPILER-268_modulepath/verify.groovy * (edit) maven-compiler-plugin/src/it/MCOMPILER-270_release/verify.groovy * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/invoker.properties * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/pom.xml * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/src * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/src/main * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/src/main/java * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/src/main/java/com * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/src/main/java/com/foo * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/src/main/java/com/foo/MyClass.java * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/src/main/java/module-info.java * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/src/test * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/src/test/java * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/src/test/java/com * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/src/test/java/com/foo * (add) maven-compiler-plugin/src/it/MCOMPILER-275_separate-moduleinfo/src/test/java/com/foo/MyTest.java * (edit) maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java * (edit) maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java * (edit) maven-compiler-plugin/src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java * (edit) maven-compiler-plugin/src/test/java/org/apache/maven/plugin/compiler/CompilerMojoTestCase.java > Support modulepath (Java9/Jigsaw) > - > > Key: MCOMPILER-269 > URL: https://issues.apache.org/jira/browse/MCOMPILER-269 > Project: Maven Compiler Plugin > Issue Type: Bug >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 3.6 > > > http://openjdk.java.net/jeps/261 describes which arguments to use to make > proper use of modules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSITE-783) Bad modules links when 'distributionManagement.site.url' comes from settings.xml
[
https://issues.apache.org/jira/browse/MSITE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15521183#comment-15521183
]
Alix Lourme commented on MSITE-783:
---
Fully agree
> Bad modules links when 'distributionManagement.site.url' comes from
> settings.xml
>
>
> Key: MSITE-783
> URL: https://issues.apache.org/jira/browse/MSITE-783
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: multi module, property interpolation, relative links
>Affects Versions: 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.5.1
>Reporter: Alix Lourme
>Assignee: Hervé Boutemy
> Fix For: 3.6
>
> Attachments: variableSettingsSubLinkMenu.zip
>
>
> When the _distributionManagement.site.url_ contains a property filled in
> _settings.xml_ like :
> _pom.xml_ :
> {code}
>
>
> projectSite
> ${sitePublishLocation}/foo/${project.artifactId}
>
>
> {code}
> _settings.xml_:
> {code}
>
>
>
>
> site-location
>
>
> file://tmp/sitePublish
>
>
>
>
> site-location
>
>
> {code}
> The modules link menu in *target/site/index.html* are not interpolated:
> {code}
> ../../../../${sitePublishLocation}/foo/test-module-hierarchical/index.html
> {code}
> Problem can be reproduced with [^variableSettingsSubLinkMenu.zip] project.
> This command fails:
> {code}
> mvn site -s settings-site-location.xml
> {code}
> This command works:
> {code}
> mvn site -s settings-site-location.xml
> -DsitePublishLocation="/tmp/sitePublish"
> {code}
> Probably a link with MSITE-604, but the v3.5 doesn't fix this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-783) Bad modules links when 'distributionManagement.site.url' comes from settings.xml
[
https://issues.apache.org/jira/browse/MSITE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15521133#comment-15521133
]
Hervé Boutemy commented on MSITE-783:
-
not so logic: the links are there, but wrong since not interpolated. Ideally,
when Doxia reads pom.xml, it could do it without this limitation, but I could
not find any way to do it (that's why I use reactor...)
but at least, in normal use case, you don't run "-N", then I thikn we can live
with this limitation
> Bad modules links when 'distributionManagement.site.url' comes from
> settings.xml
>
>
> Key: MSITE-783
> URL: https://issues.apache.org/jira/browse/MSITE-783
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: multi module, property interpolation, relative links
>Affects Versions: 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.5.1
>Reporter: Alix Lourme
>Assignee: Hervé Boutemy
> Fix For: 3.6
>
> Attachments: variableSettingsSubLinkMenu.zip
>
>
> When the _distributionManagement.site.url_ contains a property filled in
> _settings.xml_ like :
> _pom.xml_ :
> {code}
>
>
> projectSite
> ${sitePublishLocation}/foo/${project.artifactId}
>
>
> {code}
> _settings.xml_:
> {code}
>
>
>
>
> site-location
>
>
> file://tmp/sitePublish
>
>
>
>
> site-location
>
>
> {code}
> The modules link menu in *target/site/index.html* are not interpolated:
> {code}
> ../../../../${sitePublishLocation}/foo/test-module-hierarchical/index.html
> {code}
> Problem can be reproduced with [^variableSettingsSubLinkMenu.zip] project.
> This command fails:
> {code}
> mvn site -s settings-site-location.xml
> {code}
> This command works:
> {code}
> mvn site -s settings-site-location.xml
> -DsitePublishLocation="/tmp/sitePublish"
> {code}
> Probably a link with MSITE-604, but the v3.5 doesn't fix this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-783) Bad modules links when 'distributionManagement.site.url' comes from settings.xml
[
https://issues.apache.org/jira/browse/MSITE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15521093#comment-15521093
]
Alix Lourme commented on MSITE-783:
---
@[~hboutemy] : Many thanks again for the fix. I will test it tomorrow in "real"
condition with SNAPSHOT build.
{quote}
FYI this won't fix when using "mvn -N" (a warning will be displayed)
{quote}
Logic IMO :)
> Bad modules links when 'distributionManagement.site.url' comes from
> settings.xml
>
>
> Key: MSITE-783
> URL: https://issues.apache.org/jira/browse/MSITE-783
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: multi module, property interpolation, relative links
>Affects Versions: 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.5.1
>Reporter: Alix Lourme
>Assignee: Hervé Boutemy
> Fix For: 3.6
>
> Attachments: variableSettingsSubLinkMenu.zip
>
>
> When the _distributionManagement.site.url_ contains a property filled in
> _settings.xml_ like :
> _pom.xml_ :
> {code}
>
>
> projectSite
> ${sitePublishLocation}/foo/${project.artifactId}
>
>
> {code}
> _settings.xml_:
> {code}
>
>
>
>
> site-location
>
>
> file://tmp/sitePublish
>
>
>
>
> site-location
>
>
> {code}
> The modules link menu in *target/site/index.html* are not interpolated:
> {code}
> ../../../../${sitePublishLocation}/foo/test-module-hierarchical/index.html
> {code}
> Problem can be reproduced with [^variableSettingsSubLinkMenu.zip] project.
> This command fails:
> {code}
> mvn site -s settings-site-location.xml
> {code}
> This command works:
> {code}
> mvn site -s settings-site-location.xml
> -DsitePublishLocation="/tmp/sitePublish"
> {code}
> Probably a link with MSITE-604, but the v3.5 doesn't fix this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MSITE-783) Bad modules links when 'distributionManagement.site.url' comes from settings.xml
[
https://issues.apache.org/jira/browse/MSITE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15521095#comment-15521095
]
Alix Lourme commented on MSITE-783:
---
@[~hboutemy] : Many thanks again for the fix. I will test it tomorrow in "real"
condition with SNAPSHOT build.
{quote}
FYI this won't fix when using "mvn -N" (a warning will be displayed)
{quote}
Logic IMO :)
> Bad modules links when 'distributionManagement.site.url' comes from
> settings.xml
>
>
> Key: MSITE-783
> URL: https://issues.apache.org/jira/browse/MSITE-783
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: multi module, property interpolation, relative links
>Affects Versions: 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.5.1
>Reporter: Alix Lourme
>Assignee: Hervé Boutemy
> Fix For: 3.6
>
> Attachments: variableSettingsSubLinkMenu.zip
>
>
> When the _distributionManagement.site.url_ contains a property filled in
> _settings.xml_ like :
> _pom.xml_ :
> {code}
>
>
> projectSite
> ${sitePublishLocation}/foo/${project.artifactId}
>
>
> {code}
> _settings.xml_:
> {code}
>
>
>
>
> site-location
>
>
> file://tmp/sitePublish
>
>
>
>
> site-location
>
>
> {code}
> The modules link menu in *target/site/index.html* are not interpolated:
> {code}
> ../../../../${sitePublishLocation}/foo/test-module-hierarchical/index.html
> {code}
> Problem can be reproduced with [^variableSettingsSubLinkMenu.zip] project.
> This command fails:
> {code}
> mvn site -s settings-site-location.xml
> {code}
> This command works:
> {code}
> mvn site -s settings-site-location.xml
> -DsitePublishLocation="/tmp/sitePublish"
> {code}
> Probably a link with MSITE-604, but the v3.5 doesn't fix this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (MSITE-783) Bad modules links when 'distributionManagement.site.url' comes from settings.xml
[
https://issues.apache.org/jira/browse/MSITE-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alix Lourme updated MSITE-783:
--
Comment: was deleted
(was: @[~hboutemy] : Many thanks again for the fix. I will test it tomorrow in
"real" condition with SNAPSHOT build.
{quote}
FYI this won't fix when using "mvn -N" (a warning will be displayed)
{quote}
Logic IMO :))
> Bad modules links when 'distributionManagement.site.url' comes from
> settings.xml
>
>
> Key: MSITE-783
> URL: https://issues.apache.org/jira/browse/MSITE-783
> Project: Maven Site Plugin
> Issue Type: Bug
> Components: multi module, property interpolation, relative links
>Affects Versions: 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.5.1
>Reporter: Alix Lourme
>Assignee: Hervé Boutemy
> Fix For: 3.6
>
> Attachments: variableSettingsSubLinkMenu.zip
>
>
> When the _distributionManagement.site.url_ contains a property filled in
> _settings.xml_ like :
> _pom.xml_ :
> {code}
>
>
> projectSite
> ${sitePublishLocation}/foo/${project.artifactId}
>
>
> {code}
> _settings.xml_:
> {code}
>
>
>
>
> site-location
>
>
> file://tmp/sitePublish
>
>
>
>
> site-location
>
>
> {code}
> The modules link menu in *target/site/index.html* are not interpolated:
> {code}
> ../../../../${sitePublishLocation}/foo/test-module-hierarchical/index.html
> {code}
> Problem can be reproduced with [^variableSettingsSubLinkMenu.zip] project.
> This command fails:
> {code}
> mvn site -s settings-site-location.xml
> {code}
> This command works:
> {code}
> mvn site -s settings-site-location.xml
> -DsitePublishLocation="/tmp/sitePublish"
> {code}
> Probably a link with MSITE-604, but the v3.5 doesn't fix this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (ARCHETYPE-510) Achetype 1.0.x descriptor documentation is not generated any more
[ https://issues.apache.org/jira/browse/ARCHETYPE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed ARCHETYPE-510. --- Resolution: Fixed https://maven.apache.org/archetype-archives/archetype-LATEST/archetype-common/archetype.html > Achetype 1.0.x descriptor documentation is not generated any more > - > > Key: ARCHETYPE-510 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-510 > Project: Maven Archetype > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2, 2.4 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 2.5 > > > it was there in 2.1 release but not in 2.2 > found that the modello site generation had been removed (by inadvertance > probably) when fixing ARCHETYPE-471 > this descriptor is deprecated, but keeping its documentation is useful, for > example when people find an old mini-guide describing vesion 1.0.x: > MNGSITE-292 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARCHETYPE-510) Achetype 1.0.x descriptor documentation is not generated any more
[ https://issues.apache.org/jira/browse/ARCHETYPE-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520896#comment-15520896 ] Hudson commented on ARCHETYPE-510: -- FAILURE: Integrated in Jenkins build maven-archetype-m3 #237 (See [https://builds.apache.org/job/maven-archetype-m3/237/]) ARCHETYPE-510 enable Archetype 1.0.x descriptor documentation back (hboutemy: rev c28aed853795448a6b1ca6553219015105280ba5) * (edit) archetype-common/pom.xml > Achetype 1.0.x descriptor documentation is not generated any more > - > > Key: ARCHETYPE-510 > URL: https://issues.apache.org/jira/browse/ARCHETYPE-510 > Project: Maven Archetype > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2, 2.4 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 2.5 > > > it was there in 2.1 release but not in 2.2 > found that the modello site generation had been removed (by inadvertance > probably) when fixing ARCHETYPE-471 > this descriptor is deprecated, but keeping its documentation is useful, for > example when people find an old mini-guide describing vesion 1.0.x: > MNGSITE-292 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARCHETYPE-510) Achetype 1.0.x descriptor documentation is not generated any more
Hervé Boutemy created ARCHETYPE-510: --- Summary: Achetype 1.0.x descriptor documentation is not generated any more Key: ARCHETYPE-510 URL: https://issues.apache.org/jira/browse/ARCHETYPE-510 Project: Maven Archetype Issue Type: Bug Components: Documentation Affects Versions: 2.4, 2.2 Reporter: Hervé Boutemy Assignee: Hervé Boutemy Fix For: 2.5 it was there in 2.1 release but not in 2.2 found that the modello site generation had been removed (by inadvertance probably) when fixing ARCHETYPE-471 this descriptor is deprecated, but keeping its documentation is useful, for example when people find an old mini-guide describing vesion 1.0.x: MNGSITE-292 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-683) Xref link generation regression with Maven 3
[ https://issues.apache.org/jira/browse/SUREFIRE-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520814#comment-15520814 ] Tibor Digana commented on SUREFIRE-683: --- [~hboutemy] I agree with you. I also do not like hardcodings. > Xref link generation regression with Maven 3 > > > Key: SUREFIRE-683 > URL: https://issues.apache.org/jira/browse/SUREFIRE-683 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Report Plugin >Affects Versions: 2.7.1 > Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100) > Java version: 1.6.0_20 > Java home: /usr/lib/jvm/java-6-openjdk/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-27-generic" arch: "i386" Family: "unix" >Reporter: Marc Rohlfs >Priority: Minor > Attachments: SUREFIRE-683_sample.zip > > > When the site reports are created with Maven 3, the this plugin doesn't > generate the links to the Source Xref pages, when the JXR Plugin hasn't been > executed before. > The plugin looks for the xrefLocation directory and if it doesn't exist, it > checks if the JXR plugin is configured for the project (see > http://maven.apache.org/plugins/maven-surefire-report-plugin/xref/org/apache/maven/plugins/surefire/report/SurefireReportMojo.html#203). > To properly generate the Xref links when the report is created with Maven 3, > the plugin should also check the reportPlugins paramerter of the Site plugin > configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-683) Xref link generation regression with Maven 3
[ https://issues.apache.org/jira/browse/SUREFIRE-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520802#comment-15520802 ] Hervé Boutemy edited comment on SUREFIRE-683 at 9/25/16 1:12 PM: - the way it is explained, I see "hard-coding some specific cases", then I don't like it this way but yes, we can improve the reporting mecanism if we need: maven-reporting-exec is responsible of preparing reporting plugins I suppose it could inject a parameter telling that jxr will be run, then the plugin can count on it, even if jxr hasn't been run yet Or even more generic: I suppose we could inject the list of reports Notice: since the report has to be able to run as a normal plugin, not during site generation, this may be problematic perhaps we could make some code from maven-reporting-exec public, to be able to read reporting section of MavenProject (notice I changed the issue type from bug to improvement: this is not really a bug) (notice 2: the comment "As there's no reliable order for the report plugin execution" is wrong, there is reliable order for report plugins execution, it is just hard to explain when inheritance is at play and you want to insert a plugin somewhere else than after everything else) was (Author: hboutemy): the way it is explained, I see "hard-coding some specific cases", then I don't like it this way but yes, we can improve the reporting mecanism if we need: maven-reporting-exec is responsible of preparing reporting plugins I suppose it could inject a parameter telling that jxr will be run, then the plugin can count on it, even if jxr hasn't been run yet Or even more generic: I suppose we could inject the list of reports Notice: since the report has to be able to run as a normal plugin, not during site generation, this may be problematic perhaps we could make some code from maven-reporting-exec public, to be able to read reporting section of MavenProject (notice I changed the issue type from bug to improvement: this is not really a bug) > Xref link generation regression with Maven 3 > > > Key: SUREFIRE-683 > URL: https://issues.apache.org/jira/browse/SUREFIRE-683 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Report Plugin >Affects Versions: 2.7.1 > Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100) > Java version: 1.6.0_20 > Java home: /usr/lib/jvm/java-6-openjdk/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-27-generic" arch: "i386" Family: "unix" >Reporter: Marc Rohlfs >Priority: Minor > Attachments: SUREFIRE-683_sample.zip > > > When the site reports are created with Maven 3, the this plugin doesn't > generate the links to the Source Xref pages, when the JXR Plugin hasn't been > executed before. > The plugin looks for the xrefLocation directory and if it doesn't exist, it > checks if the JXR plugin is configured for the project (see > http://maven.apache.org/plugins/maven-surefire-report-plugin/xref/org/apache/maven/plugins/surefire/report/SurefireReportMojo.html#203). > To properly generate the Xref links when the report is created with Maven 3, > the plugin should also check the reportPlugins paramerter of the Site plugin > configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SUREFIRE-683) Xref link generation regression with Maven 3
[ https://issues.apache.org/jira/browse/SUREFIRE-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520802#comment-15520802 ] Hervé Boutemy edited comment on SUREFIRE-683 at 9/25/16 1:08 PM: - the way it is explained, I see "hard-coding some specific cases", then I don't like it this way but yes, we can improve the reporting mecanism if we need: maven-reporting-exec is responsible of preparing reporting plugins I suppose it could inject a parameter telling that jxr will be run, then the plugin can count on it, even if jxr hasn't been run yet Or even more generic: I suppose we could inject the list of reports Notice: since the report has to be able to run as a normal plugin, not during site generation, this may be problematic perhaps we could make some code from maven-reporting-exec public, to be able to read reporting section of MavenProject (notice I changed the issue type from bug to improvement: this is not really a bug) was (Author: hboutemy): the way it is explained, I see "hard-coding some specific cases", then I don't like it this way but yes, we can improve the reporting mecanism if we need: maven-reporting-exec is responsible of preparing reporting plugins I suppose it could inject a parameter telling that jxr will be run, then the plugin can count on it, even if jxr hasn't been run yet Or even more generic: I suppose we could inject the list of reports Notice: since the report has to be able to run as a normal plugin, not during site generation, this may be problematic perhaps we could make some code from maven-reporting-exec public, to be able to read reporting section of MavenProject > Xref link generation regression with Maven 3 > > > Key: SUREFIRE-683 > URL: https://issues.apache.org/jira/browse/SUREFIRE-683 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Report Plugin >Affects Versions: 2.7.1 > Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100) > Java version: 1.6.0_20 > Java home: /usr/lib/jvm/java-6-openjdk/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-27-generic" arch: "i386" Family: "unix" >Reporter: Marc Rohlfs >Priority: Minor > Attachments: SUREFIRE-683_sample.zip > > > When the site reports are created with Maven 3, the this plugin doesn't > generate the links to the Source Xref pages, when the JXR Plugin hasn't been > executed before. > The plugin looks for the xrefLocation directory and if it doesn't exist, it > checks if the JXR plugin is configured for the project (see > http://maven.apache.org/plugins/maven-surefire-report-plugin/xref/org/apache/maven/plugins/surefire/report/SurefireReportMojo.html#203). > To properly generate the Xref links when the report is created with Maven 3, > the plugin should also check the reportPlugins paramerter of the Site plugin > configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-683) Xref link generation regression with Maven 3
[ https://issues.apache.org/jira/browse/SUREFIRE-683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated SUREFIRE-683: --- Issue Type: Improvement (was: Bug) > Xref link generation regression with Maven 3 > > > Key: SUREFIRE-683 > URL: https://issues.apache.org/jira/browse/SUREFIRE-683 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Report Plugin >Affects Versions: 2.7.1 > Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100) > Java version: 1.6.0_20 > Java home: /usr/lib/jvm/java-6-openjdk/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-27-generic" arch: "i386" Family: "unix" >Reporter: Marc Rohlfs >Priority: Minor > Attachments: SUREFIRE-683_sample.zip > > > When the site reports are created with Maven 3, the this plugin doesn't > generate the links to the Source Xref pages, when the JXR Plugin hasn't been > executed before. > The plugin looks for the xrefLocation directory and if it doesn't exist, it > checks if the JXR plugin is configured for the project (see > http://maven.apache.org/plugins/maven-surefire-report-plugin/xref/org/apache/maven/plugins/surefire/report/SurefireReportMojo.html#203). > To properly generate the Xref links when the report is created with Maven 3, > the plugin should also check the reportPlugins paramerter of the Site plugin > configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-683) Xref link generation regression with Maven 3
[ https://issues.apache.org/jira/browse/SUREFIRE-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520802#comment-15520802 ] Hervé Boutemy commented on SUREFIRE-683: the way it is explained, I see "hard-coding some specific cases", then I don't like it this way but yes, we can improve the reporting mecanism if we need: maven-reporting-exec is responsible of preparing reporting plugins I suppose it could inject a parameter telling that jxr will be run, then the plugin can count on it, even if jxr hasn't been run yet Or even more generic: I suppose we could inject the list of reports Notice: since the report has to be able to run as a normal plugin, not during site generation, this may be problematic perhaps we could make some code from maven-reporting-exec public, to be able to read reporting section of MavenProject > Xref link generation regression with Maven 3 > > > Key: SUREFIRE-683 > URL: https://issues.apache.org/jira/browse/SUREFIRE-683 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin >Affects Versions: 2.7.1 > Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100) > Java version: 1.6.0_20 > Java home: /usr/lib/jvm/java-6-openjdk/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-27-generic" arch: "i386" Family: "unix" >Reporter: Marc Rohlfs >Priority: Minor > Attachments: SUREFIRE-683_sample.zip > > > When the site reports are created with Maven 3, the this plugin doesn't > generate the links to the Source Xref pages, when the JXR Plugin hasn't been > executed before. > The plugin looks for the xrefLocation directory and if it doesn't exist, it > checks if the JXR plugin is configured for the project (see > http://maven.apache.org/plugins/maven-surefire-report-plugin/xref/org/apache/maven/plugins/surefire/report/SurefireReportMojo.html#203). > To properly generate the Xref links when the report is created with Maven 3, > the plugin should also check the reportPlugins paramerter of the Site plugin > configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1183) Custom Test Report Titles and Descriptions
[ https://issues.apache.org/jira/browse/SUREFIRE-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1183: --- Fix Version/s: Backlog > Custom Test Report Titles and Descriptions > -- > > Key: SUREFIRE-1183 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1183 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Report Plugin >Affects Versions: 2.18.1 >Reporter: Gerald Mücke >Priority: Minor > Fix For: Backlog > > > Hi, > I'd like to add the possibility to customize the name and descriptions of the > test reports, in order to define report sets with not only custom outputNames > but custom titles and descriptions as well so that they appear in the report > with a self-describing name and description. > Motivation: > At a customer project we have several automated tests (unit tests, > integration tests, automated acceptance tests, performance tests) and each of > those are run either using surefire or failsafe. > We have different report sets for each of these tests and separate output > files. But in the Project Reports Overview each Report is named either > "Surefire Report" or "Failsafe Report" with the corresponding default > description. Further, the title of the Report page itself is always "Surefire > Reports" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (SUREFIRE-737) Report any extra attributes attached to a test
[
https://issues.apache.org/jira/browse/SUREFIRE-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-737.
-
Resolution: Won't Fix
Assignee: Tibor Digana
The patch is too old. Looking for a more generic approach in Version 3.x where
more than title is customized.
> Report any extra attributes attached to a test
> --
>
> Key: SUREFIRE-737
> URL: https://issues.apache.org/jira/browse/SUREFIRE-737
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Report Plugin
>Reporter: Rex Hoffman
>Assignee: Tibor Digana
>Priority: Minor
> Attachments: extra_attributes_patch.txt
>
>
> So if there are any extra attributes on a junit test result (possible, due to
> lack of schema) print them out in the html report.
> Useful for adding in links, and image tags.
> Umm attached an extra bit of functionality, allows a user to set a name for
> the report, useful if you do something like:
> ...
>
>
> org.apache.maven.plugins
> maven-surefire-report-plugin
> 2.8.1
>
>
> integration-test-report
>
> report-only
>
>
> Surefire (Integration)
> true
> true
>
> integration-test-report
>
> ${basedir}/target/failsafe-reports/junitreport
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-report-plugin
> 2.8.1
>
>
> unit-test-report
>
> report-only
>
>
> Surefire (Unit)
> true
>
> unit-test-report
>
> ${basedir}/target/surefire-reports/junitreport
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1220) Surefire never outputs UTF-8 under Windows
[
https://issues.apache.org/jira/browse/SUREFIRE-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520777#comment-15520777
]
Tibor Digana commented on SUREFIRE-1220:
In SUREFIRE-1222 I see the possibility to support UTF8.
> Surefire never outputs UTF-8 under Windows
> --
>
> Key: SUREFIRE-1220
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1220
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.19.1
> Environment: Windows 10, 64-bit
> DejaVu Sans font
>Reporter: Gili
> Attachments: 2016-01-29_113906.png, exec_exec.png, output.exec.txt,
> output.test.txt, surefire-1220.zip, test.png
>
>
> I'm having problems getting Surefire to output UTF-8 fonts under Windows.
> When I run a unit test that outputs a Guava Range ("10‥20") the TWO DOT
> LEADER unicode character always gets rendered as a question mark.
> If I run the exact same code outside of Surefire (using a main() entry point)
> the UTF-8 character renders just fine. The repro steps are quite simple:
> # Create a Maven project.
> # Run {code}System.out.println(Range.closed(10, 30));{code} in a Java class
> with a main() entry point, and from a JUnit test.
> # The main() entry point will output UTF-8 just fine. The JUnit test will
> output a question mark in place of the unicode.
> Here is my pom.xml file:
> {code}
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
> com.mycompany
> mavenproject1
> 1.0-SNAPSHOT
> jar
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.19.1
>
> -Dfile.encoding=UTF-8
>
>
>
> org.codehaus.mojo
> exec-maven-plugin
> 1.4.0
>
>
>
> java
>
>
>
>
> foo.Main
>
>
>
>
>
>
> com.google.guava
> guava
> 19.0
>
>
> junit
> junit
> 4.12
> test
>
>
>
> UTF-8
> 1.8
> 1.8
>
>
> {code}
> I tried the same thing using TestNG tests and noticed that although output to
> console was still wrong, the outputted testng-results.xml file contained the
> correct character.
> Can you reproduce this on your end?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1280) Replace "http://jira.codehaus.org" with "https://issues.apache.org/jira"
[ https://issues.apache.org/jira/browse/SUREFIRE-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520773#comment-15520773 ] Hudson commented on SUREFIRE-1280: -- SUCCESS: Integrated in Jenkins build maven-surefire #1628 (See [https://builds.apache.org/job/maven-surefire/1628/]) [SUREFIRE-1280] Replace "http://jira.codehaus.org"; with (guillaume_boue: rev 308d941c9b6ebb695aba9630f81fc5b400f21322) * (edit) maven-surefire-plugin/src/site/apt/examples/fork-options-and-parallel-execution.apt.vm * (edit) maven-surefire-plugin/src/site/markdown/multilineexceptions.md > Replace "http://jira.codehaus.org"; with "https://issues.apache.org/jira"; > > > Key: SUREFIRE-1280 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1280 > Project: Maven Surefire > Issue Type: Documentation > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MASSEMBLY-829) fileMode on a dependencySet with unpack does not work
[
https://issues.apache.org/jira/browse/MASSEMBLY-829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Boué closed MASSEMBLY-829.
Resolution: Fixed
Assignee: Guillaume Boué
Fix Version/s: 3.0.0
I don't have an ETA for the release of 3.0.0, there is a dependency on
maven-artifact-transfer which isn't released yet, see also
http://maven.40175.n5.nabble.com/maven-assembly-plugin-release-td5871112.html
> fileMode on a dependencySet with unpack does not work
> -
>
> Key: MASSEMBLY-829
> URL: https://issues.apache.org/jira/browse/MASSEMBLY-829
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: dependencySet
>Affects Versions: 2.6
> Environment: linux
>Reporter: Christophe Marchand
>Assignee: Guillaume Boué
>Priority: Blocker
> Fix For: 3.0.0
>
> Attachments: bug-maven-assembly-plugin.tar.gz
>
>
> {code:xml}
>
>
> false
> 775
>
> top.marchand.mvn.bug:assembly-fileMode-shells
>
> true
>
>
> META-INF/**
> META-INF
>
>
> runtime
>
> {code}
> Files from {{top.marchand.mvn.bug:assembly-fileMode-shells}} should be
> runnable by everyone, and they are not.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SUREFIRE-790) Allow forked process to access the Maven session of parent
[ https://issues.apache.org/jira/browse/SUREFIRE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-790. - Resolution: Not A Problem Closing this issue as nowadays Arquillian does not have problem to run in forked JMV surefire process. > Allow forked process to access the Maven session of parent > -- > > Key: SUREFIRE-790 > URL: https://issues.apache.org/jira/browse/SUREFIRE-790 > Project: Maven Surefire > Issue Type: New Feature > Components: process forking >Affects Versions: 2.10 >Reporter: Karel Piwko >Assignee: Tibor Digana > > Forked process should be able to get information from a "parent process", > which is a Maven build execution. > This will allow the test to access information like which pom.xml file being > processed, settings.xml and Maven Reactor plugin. > This feature is needed to any test which want to interfere with Maven > repositories with Aether, for instance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-737) Report any extra attributes attached to a test
[
https://issues.apache.org/jira/browse/SUREFIRE-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520754#comment-15520754
]
Tibor Digana commented on SUREFIRE-737:
---
It seems you are trying to customize title name, so I see this patch suitable
in another Jira issue and mark this duplicated.
> Report any extra attributes attached to a test
> --
>
> Key: SUREFIRE-737
> URL: https://issues.apache.org/jira/browse/SUREFIRE-737
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Surefire Report Plugin
>Reporter: Rex Hoffman
>Priority: Minor
> Attachments: extra_attributes_patch.txt
>
>
> So if there are any extra attributes on a junit test result (possible, due to
> lack of schema) print them out in the html report.
> Useful for adding in links, and image tags.
> Umm attached an extra bit of functionality, allows a user to set a name for
> the report, useful if you do something like:
> ...
>
>
> org.apache.maven.plugins
> maven-surefire-report-plugin
> 2.8.1
>
>
> integration-test-report
>
> report-only
>
>
> Surefire (Integration)
> true
> true
>
> integration-test-report
>
> ${basedir}/target/failsafe-reports/junitreport
>
>
>
>
>
> org.apache.maven.plugins
> maven-surefire-report-plugin
> 2.8.1
>
>
> unit-test-report
>
> report-only
>
>
> Surefire (Unit)
> true
>
> unit-test-report
>
> ${basedir}/target/surefire-reports/junitreport
>
>
>
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-683) Xref link generation regression with Maven 3
[ https://issues.apache.org/jira/browse/SUREFIRE-683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520751#comment-15520751 ] Tibor Digana commented on SUREFIRE-683: --- [~hboutemy] Do you think that m-site-p may check if checkstyle surefire-report or PMD present in reporting and generate jxr in prior? Would it be good a idea? > Xref link generation regression with Maven 3 > > > Key: SUREFIRE-683 > URL: https://issues.apache.org/jira/browse/SUREFIRE-683 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Report Plugin >Affects Versions: 2.7.1 > Environment: Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100) > Java version: 1.6.0_20 > Java home: /usr/lib/jvm/java-6-openjdk/jre > Default locale: en_GB, platform encoding: UTF-8 > OS name: "linux" version: "2.6.32-27-generic" arch: "i386" Family: "unix" >Reporter: Marc Rohlfs >Priority: Minor > Attachments: SUREFIRE-683_sample.zip > > > When the site reports are created with Maven 3, the this plugin doesn't > generate the links to the Source Xref pages, when the JXR Plugin hasn't been > executed before. > The plugin looks for the xrefLocation directory and if it doesn't exist, it > checks if the JXR plugin is configured for the project (see > http://maven.apache.org/plugins/maven-surefire-report-plugin/xref/org/apache/maven/plugins/surefire/report/SurefireReportMojo.html#203). > To properly generate the Xref links when the report is created with Maven 3, > the plugin should also check the reportPlugins paramerter of the Site plugin > configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1068) forkNumber in systemPropertyVariables requires prefix
[
https://issues.apache.org/jira/browse/SUREFIRE-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520728#comment-15520728
]
Tibor Digana commented on SUREFIRE-1068:
[~ericacm]
[~sourcedelica]
If it is still your interest, open a PR in GitHub and provide a patch.
Thx.
> forkNumber in systemPropertyVariables requires prefix
> -
>
> Key: SUREFIRE-1068
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1068
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.16
>Reporter: Eric Pederson
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0
>
>
> The {{$\{surefire.forkNumber\}}} placeholder cannot be used alone in a
> {{systemPropertyVariable}}. The workaround is to prefix the value.
> For example, this doesn't work (the {{surefire.forkNumber}} system property
> does not exist when running the test).
> {code:xml}
>
> ${surefire.forkNumber}
>
> {code}
> But this does:
> {code:xml}
>
> 0${surefire.forkNumber}
>
> {code}
> (note the leading *0*)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-756) Allow ability to capture executed random runOrder for re-play purposes
[ https://issues.apache.org/jira/browse/SUREFIRE-756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520726#comment-15520726 ] Tibor Digana commented on SUREFIRE-756: --- [~jspie...@axeda.com] [~jss] If it is still your interest, open a PR in GitHub and provide a patch. Thx. > Allow ability to capture executed random runOrder for re-play purposes > -- > > Key: SUREFIRE-756 > URL: https://issues.apache.org/jira/browse/SUREFIRE-756 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 2.9 >Reporter: Josh Spiewak >Assignee: Tibor Digana >Priority: Minor > > As a user of the runOrder=random feature, I would like to be able to capture > a given ordering of tests and re-play that order, so that if a particular > ordering exposes hidden dependencies between tests I can reproduce in my > development environment, fix the problem, and then runs the tests again to > confirm the fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1119) Run tests without order
[
https://issues.apache.org/jira/browse/SUREFIRE-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520718#comment-15520718
]
Tibor Digana commented on SUREFIRE-1119:
[~malahovskys]
The implementation in {{FileScanner}} is long time different.
The only way is to again reorder the list in {{DefaultScanResult}} upon
patterns in {{direct}}.
If it is your interest, open a pull request in GitHub with a patch.
> Run tests without order
> ---
>
> Key: SUREFIRE-1119
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1119
> Project: Maven Surefire
> Issue Type: Wish
>Affects Versions: 2.18
>Reporter: Sergey Malahovsky
>Assignee: Tibor Digana
>Priority: Minor
>
> It will be great to have ability to run tests in direct order without any
> sorting.
> For example:
>
>
> **/*CTestSuite*
> **/*ATestSuite*
> **/*BTestSuite*
>
>direct
>
> In current solution test suites will be sorted by alphabetical (or another
> order): **/*ATestSuite*, **/*BTestSuite*, **/*CTestSuite*.
> But sometimes it needs to run without any sorting in order as specified in
> / tags: **/*CTestSuite*, **/*ATestSuite*, **/*BTestSuite*.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (SUREFIRE-1139) TestNG parameters cannot be overridden when suite is used
[ https://issues.apache.org/jira/browse/SUREFIRE-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1139. -- Resolution: Not A Bug Assignee: Tibor Digana [~pkk82] >From my point of view this is a question to TestNG team and not to Surefire. > TestNG parameters cannot be overridden when suite is used > - > > Key: SUREFIRE-1139 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1139 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin >Affects Versions: 2.18 >Reporter: Piotr Kozak >Assignee: Tibor Digana >Priority: Minor > Attachments: testng-with-failsafe.zip > > > I try to override TestNG parameteres used in suite file testng.xml with > failsafe configuration . Analogous functionality > when testng.xml is triggered from Intellij Idea via TestNG runner works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1183) Custom Test Report Titles and Descriptions
[ https://issues.apache.org/jira/browse/SUREFIRE-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520695#comment-15520695 ] Tibor Digana commented on SUREFIRE-1183: [~gmuecke] Can you express the way how the title can be customized? > Custom Test Report Titles and Descriptions > -- > > Key: SUREFIRE-1183 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1183 > Project: Maven Surefire > Issue Type: Improvement > Components: Maven Surefire Report Plugin >Affects Versions: 2.18.1 >Reporter: Gerald Mücke >Priority: Minor > > Hi, > I'd like to add the possibility to customize the name and descriptions of the > test reports, in order to define report sets with not only custom outputNames > but custom titles and descriptions as well so that they appear in the report > with a self-describing name and description. > Motivation: > At a customer project we have several automated tests (unit tests, > integration tests, automated acceptance tests, performance tests) and each of > those are run either using surefire or failsafe. > We have different report sets for each of these tests and separate output > files. But in the Project Reports Overview each Report is named either > "Surefire Report" or "Failsafe Report" with the corresponding default > description. Further, the title of the Report page itself is always "Surefire > Reports" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SUREFIRE-1219) skipAfterFailureCount should not count flaky tests as failures when using rerunFailingTestsCount
[ https://issues.apache.org/jira/browse/SUREFIRE-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1219: -- Assignee: Tibor Digana > skipAfterFailureCount should not count flaky tests as failures when using > rerunFailingTestsCount > > > Key: SUREFIRE-1219 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1219 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.19.1 >Reporter: Sean Flanigan >Assignee: Tibor Digana > Attachments: SUREFIRE-1219-tests.zip > > > According to > https://maven.apache.org/surefire/maven-surefire-plugin/examples/rerun-failing-tests.html > "failed tests within re-run phase are not included in > skipAfterFailureCount". For instance, if skipAfterFailureCount is 1, but > every test passes on the second attempt, the tests are "flaky" but not > "failures". This should be reflected in summaries, in XML result files and > in fail fast (skipAfterFailureCount), but this is not the case. > If I have 10 flaky-but-not-failing tests, set rerunFailingTestsCount=1 and > skipAfterFailureCount=5: > 1. I would expect something like this to be printed on the console: > Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Flakes: 10 > 2. The XML report should list s but no . > 3. All tests should be run, not just 5 of them, in other words > skipAfterFailureCount should not count the flaky tests as part of the failure > count. > I have some tests demonstrating the problem, which I will attach to this > issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1263) No class name in log when running tests in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520654#comment-15520654
]
Tibor Digana commented on SUREFIRE-1263:
[~jderrien]
Please try to help us to fix it and open a pull request in GitHub with your
patch.
I want fix two other issues and start the Vote for release Version 2.19.2 by
the end of the week.
Thx.
> No class name in log when running tests in parallel with parameterized tests
>
>
> Key: SUREFIRE-1263
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1263
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
>
> Hello,
> Using surefire and Junit, the class names are not displayed in the output log
> when the tests are run in parallel with parameterized tests.
> According to this [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1], in
> parallel mode:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 7.799 s
> [INFO] Finished at: 2016-07-27T15:03:37+02:00
> [INFO] Final Memory: 18M/213M
> [INFO]
>
> {noformat}
> Without parallel mode (we have the 'Running #classname#' in the output):
> {noformat}
> ---
> T E S T S
> ---
> Running com.appnexus.viewability.core.surefireJunitTests.ATest
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 8.085 sec -
> in com.appnexus.viewability.core.surefireJunitTests.ATest
> Running com.appnexus.viewability.core.surefireJunitTests.BTest
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec -
> in com.appnexus.viewability.core.surefireJunitTests.BTest
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> It would be great to have the classname displayed when running tests in
> parallel.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520650#comment-15520650
]
Tibor Digana commented on SUREFIRE-1264:
[~jderrien]
Please try to help us to fix it and open a pull request in GitHub with your
patch.
Thx.
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
>
> Hello,
> It appears some tests can be lost when using the parallel mode with
> parameterized tests. Here is a [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.006 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec -
> in [p2]
> Results :
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> When tests have been lost (here one test lost according to the output):
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec -
> in [p2]
> Running [p2]
> Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec -
> in [p2]
> Results :
> Tests run: 11, Failures: 0, Errors: 0, Skipped: 0
> {noformat}
> Note: there are 3 test classes and 18 tests on the [master
> branch|https://github.com/jderrien/surefire-junit-tests/tree/master] and it's
> even more frequent/easy to reproduce.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MPMD-227) Document multimodule configuration example
[ https://issues.apache.org/jira/browse/MPMD-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520644#comment-15520644 ] Hudson commented on MPMD-227: - SUCCESS: Integrated in Jenkins build maven-plugins #7310 (See [https://builds.apache.org/job/maven-plugins/7310/]) [MPMD-227] Document multimodule configuration example (adangel: [http://svn.apache.org/viewvc/?view=rev&rev=1762188]) * (add) maven-pmd-plugin/src/site/apt/examples/multi-module-config.apt.vm * (edit) maven-pmd-plugin/src/site/apt/index.apt.vm * (edit) maven-pmd-plugin/src/site/site.xml > Document multimodule configuration example > -- > > Key: MPMD-227 > URL: https://issues.apache.org/jira/browse/MPMD-227 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Minor > Fix For: 3.7 > > > Document the multimodule configuration, similar to Checkstyle. See > https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1198) Failsafe does not allow to configure the jar file to use
[
https://issues.apache.org/jira/browse/SUREFIRE-1198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1198:
---
Issue Type: Bug (was: Improvement)
> Failsafe does not allow to configure the jar file to use
>
>
> Key: SUREFIRE-1198
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1198
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Stephane Nicoll
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> See [this Spring Boot
> issue|https://github.com/spring-projects/spring-boot/issues/4510#issuecomment-159448634]
> It seems that SUREFIRE-855 does not allow {{target/classes}} to be used
> anymore. Is there a reason why this behaviour was completely removed in
> favour of only the jar file?
> It would be nice if we had an option to chose between the two (defaulting to
> the jar)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1280) Replace "http://jira.codehaus.org" with "https://issues.apache.org/jira"
[ https://issues.apache.org/jira/browse/SUREFIRE-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1280: --- Issue Type: Documentation (was: Improvement) > Replace "http://jira.codehaus.org"; with "https://issues.apache.org/jira"; > > > Key: SUREFIRE-1280 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1280 > Project: Maven Surefire > Issue Type: Documentation > Components: Maven Failsafe Plugin, Maven Surefire Plugin, Maven > Surefire Report Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1283) Statistics file should not be determined as (directory of surefire-reports).getParentFile().getParentFile(). It is a problem if report directory is customized. Statist
[ https://issues.apache.org/jira/browse/SUREFIRE-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1283: --- Fix Version/s: (was: 2.19.2) > Statistics file should not be determined as (directory of > surefire-reports).getParentFile().getParentFile(). It is a problem if report > directory is customized. Statistics file should be located in project dir. > - > > Key: SUREFIRE-1283 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1283 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Reporter: Tibor Digana >Assignee: Tibor Digana > > Statistics file should not be determined as > (directory of surefire-reports).getParentFile().getParentFile(). > It is a problem if report directory is customized. > Statistics file should be located in project dir. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1276) Document handling of multiline exception messages
[
https://issues.apache.org/jira/browse/SUREFIRE-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1276:
---
Labels: (was: documentation)
> Document handling of multiline exception messages
> -
>
> Key: SUREFIRE-1276
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1276
> Project: Maven Surefire
> Issue Type: Documentation
> Components: Maven Surefire Plugin
>Reporter: Gili
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> I am throwing an exception whose message contains newlines for readability.
> When {{}} is true (the default value) Surefire is removing
> all newlines.
> Expected behavior: Consider moving this functionality out of
> {{}} into its own parameter. Regardless of which parameter
> enables this behavior, please document it at
> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html ...
> right now there is no mention of this behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1276) Document handling of multiline exception messages
[
https://issues.apache.org/jira/browse/SUREFIRE-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1276:
---
Issue Type: Documentation (was: Bug)
> Document handling of multiline exception messages
> -
>
> Key: SUREFIRE-1276
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1276
> Project: Maven Surefire
> Issue Type: Documentation
> Components: Maven Surefire Plugin
>Reporter: Gili
>Assignee: Tibor Digana
> Labels: documentation
> Fix For: 2.19.2
>
>
> I am throwing an exception whose message contains newlines for readability.
> When {{}} is true (the default value) Surefire is removing
> all newlines.
> Expected behavior: Consider moving this functionality out of
> {{}} into its own parameter. Regardless of which parameter
> enables this behavior, please document it at
> http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html ...
> right now there is no mention of this behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1230) Issue with config parameter 'redirectTestOutputToFile' when running cucumber parallel tests
[ https://issues.apache.org/jira/browse/SUREFIRE-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1230: --- Fix Version/s: 2.19.2 > Issue with config parameter 'redirectTestOutputToFile' when running cucumber > parallel tests > --- > > Key: SUREFIRE-1230 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1230 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 >Reporter: Manoj Palki >Assignee: Tibor Digana > Fix For: 2.19.2 > > Attachments: cucumber_java_skeleton.tar.gz > > > The config parameter redirectTestOutputToFile behaves differently based on > how parallelism is configured in the surefire plugin. > If the config is > 2 > false > true > then the output from the tests is directed correctly to 'xxxtest-output.txt' > file. > However, if the config is > 2 > classes > true > then the output from the tests is partially directed to the > 'xxxtest-output.txt file and partially to stdout. > Also the output files have different names in two cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (SUREFIRE-1236) Surefire 2.19.1 hangs when building maven on Win 2012 server
[ https://issues.apache.org/jira/browse/SUREFIRE-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana reassigned SUREFIRE-1236: -- Assignee: Tibor Digana > Surefire 2.19.1 hangs when building maven on Win 2012 server > > > Key: SUREFIRE-1236 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1236 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.19.1 > Environment: Windows 2012 server- 64 bit >Reporter: Vijay >Assignee: Tibor Digana > Attachments: Pom.zip, SUREFIRE-1236.zip > > > Description : Surefire 2.19.1 hangs when building maven on Win 2012 server > machine using TFS build process. Please find the stack results below. > Note : When I build it locally ( WIN 8.1, 64 bit), it works without any issue > 2016-03-09 15:02:36 > Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode): > "Thread-3" prio=6 tid=0x0a4d7000 nid=0x21e0 runnable > [0x0c5df000] >java.lang.Thread.State: RUNNABLE > at java.io.FileInputStream.readBytes(Native Method) > at java.io.FileInputStream.read(FileInputStream.java:272) > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) > - locked <0xf394cc38> (a java.io.InputStreamReader) > at java.io.InputStreamReader.read(InputStreamReader.java:184) > at java.io.BufferedReader.fill(BufferedReader.java:154) > at java.io.BufferedReader.readLine(BufferedReader.java:317) > - locked <0xf394cc38> (a java.io.InputStreamReader) > at java.io.BufferedReader.readLine(BufferedReader.java:382) > at > org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76) >Locked ownable synchronizers: > - None > "Thread-2" prio=6 tid=0x0a7b8800 nid=0xaa0 runnable > [0x0c4de000] >java.lang.Thread.State: RUNNABLE > at java.io.FileInputStream.readBytes(Native Method) > at java.io.FileInputStream.read(FileInputStream.java:272) > at java.io.BufferedInputStream.read1(BufferedInputStream.java:273) > at java.io.BufferedInputStream.read(BufferedInputStream.java:334) > - locked <0xf3973da0> (a java.io.BufferedInputStream) > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177) > - locked <0xf3973d88> (a java.io.InputStreamReader) > at java.io.InputStreamReader.read(InputStreamReader.java:184) > at java.io.BufferedReader.fill(BufferedReader.java:154) > at java.io.BufferedReader.readLine(BufferedReader.java:317) > - locked <0xf3973d88> (a java.io.InputStreamReader) > at java.io.BufferedReader.readLine(BufferedReader.java:382) > at > org.apache.maven.surefire.shade.org.apache.maven.shared.utils.cli.StreamPumper.run(StreamPumper.java:76) >Locked ownable synchronizers: > - None > "ThreadedStreamConsumer" daemon prio=6 tid=0x0a7b7800 nid=0x18d0 > waiting on condition [0x0c2df000] >java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf394f620> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) > at > java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:71) > at java.lang.Thread.run(Thread.java:744) >Locked ownable synchronizers: > - None > "ping-timer-10sec" daemon prio=6 tid=0x0a7b3000 nid=0x1aa0 waiting on > condition [0x0befe000] >java.lang.Thread.State: TIMED_WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0xf3981d20> (a > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082) > at > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090) > at > java.util.concurrent.ScheduledThreadPoolEx
[jira] [Updated] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines
[
https://issues.apache.org/jira/browse/SUREFIRE-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1222:
---
Fix Version/s: 2.19.2
> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> This month the [Weld
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: -1
> at java.lang.String.substring(String.java:1911)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}}
> operation.
> I think the protocol should be robust enough to avoid similar collisions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (SUREFIRE-1222) ForkClient attempts to consume unrelated lines
[
https://issues.apache.org/jira/browse/SUREFIRE-1222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-1222:
--
Assignee: Tibor Digana
> ForkClient attempts to consume unrelated lines
> --
>
> Key: SUREFIRE-1222
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1222
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
>Affects Versions: 2.17
> Environment: Oracle JDK7 (build 1.7.0_79-b15)
> Linux 3.13 x86_64 with default locale cs_CZ
>Reporter: Martin Kouba
>Assignee: Tibor Digana
> Fix For: 2.19.2
>
>
> This month the [Weld
> SE|https://github.com/weld/core/tree/2.3/environments/se/tests] test suite
> suddenly started to fail on a Linux machine with Oracle JDK7 and the default
> locale {{cs_CZ}}:
> {code}
> Caused by: java.lang.StringIndexOutOfBoundsException: String index out of
> range: -1
> at java.lang.String.substring(String.java:1911)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:128)
> at
> org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> A {{java.util.logging.Logger}} is used in the forked process. The exception
> occurs when the following log message is written to the standard output:
> {code}
> I 29, 2016 2:01:43 ODP. org.jboss.arquillian.container.se.server.Main main
> {code}
> We have found out that the timestamp *I 29, 2016 2:01:43* (i.e. 2016-01-29
> 14:01:43) is incorrectly parsed as {{ForkingRunListener.BOOTERCODE_SYSPROPS}}
> operation.
> I think the protocol should be robust enough to avoid similar collisions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MPMD-227) Document multimodule configuration example
[ https://issues.apache.org/jira/browse/MPMD-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Dangel resolved MPMD-227. - Resolution: Fixed > Document multimodule configuration example > -- > > Key: MPMD-227 > URL: https://issues.apache.org/jira/browse/MPMD-227 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel >Priority: Minor > Fix For: 3.7 > > > Document the multimodule configuration, similar to Checkstyle. See > https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MPMD-158) Relative file name doesn't work when specifying ruleset
[
https://issues.apache.org/jira/browse/MPMD-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Dangel closed MPMD-158.
---
Resolution: Won't Fix
Assignee: Andreas Dangel
I'm closing this issue as won't fix.
Luckily, this never worked with the PMD plugin, so no need to reproduce the
hack from
[Checkstyle|http://svn.apache.org/viewvc/maven/plugins/trunk/maven-checkstyle-plugin/src/main/java/org/apache/maven/plugin/checkstyle/exec/DefaultCheckstyleExecutor.java?view=markup#l860].
I've added the documentation for a multimodule configuration, which should
solve the issue (MPMD-227).
> Relative file name doesn't work when specifying ruleset
> ---
>
> Key: MPMD-158
> URL: https://issues.apache.org/jira/browse/MPMD-158
> Project: Maven PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 2.7.1
> Environment: Windows 7
>Reporter: Taras Pushyk
>Assignee: Andreas Dangel
> Attachments: MPMD-158-With-Child-Module.zip, MPMD-158.zip
>
>
> When ruleset specified as follows:
> {code}
>
> org.apache.maven.plugins
> maven-pmd-plugin
> 2.7.1
>
> false 100 1.5
>
>../config/basic.xml
>
>
>
> {code}
> File is not resolved. Also following message appears on console:
> [DEBUG] The resource '../config/basic.xml' was not found with resourceLoader
> org.codehaus.plexus.resource.loader.FileResourceLoader.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MPMD-227) Document multimodule configuration example
Andreas Dangel created MPMD-227: --- Summary: Document multimodule configuration example Key: MPMD-227 URL: https://issues.apache.org/jira/browse/MPMD-227 Project: Maven PMD Plugin Issue Type: Improvement Components: PMD Reporter: Andreas Dangel Assignee: Andreas Dangel Priority: Minor Fix For: 3.7 Document the multimodule configuration, similar to Checkstyle. See https://maven.apache.org/plugins/maven-checkstyle-plugin/examples/multi-module-config.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MNGSITE-292) Update the mini guide to creating archectypes to Archetype 2.x
[ https://issues.apache.org/jira/browse/MNGSITE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520549#comment-15520549 ] Hervé Boutemy edited comment on MNGSITE-292 at 9/25/16 10:19 AM: - while thinking at it, another difference is that there is a dedicated packaging now which gives automatic plugin bindings: http://maven.apache.org/archetype/archetype-packaging/index.html was (Author: hboutemy): while thinking at it, another difference is that there is a packaging now which giveds automatic plugin bindings: http://maven.apache.org/archetype/archetype-packaging/index.html > Update the mini guide to creating archectypes to Archetype 2.x > -- > > Key: MNGSITE-292 > URL: https://issues.apache.org/jira/browse/MNGSITE-292 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Hervé Boutemy > > as noticed by a user recently, the > [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] > explains about Archetype 1.x, with its archetype.xml descriptor, which is > deprecated: Archetype 2.x has its descriptor with a different schema under > archetype-metadata.xml (there may be other differences, I did not investigate > in details) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNGSITE-292) Update the mini guide to creating archectypes to Archetype 2.x
[ https://issues.apache.org/jira/browse/MNGSITE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15520549#comment-15520549 ] Hervé Boutemy commented on MNGSITE-292: --- while thinking at it, another difference is that there is a packaging now which giveds automatic plugin bindings: http://maven.apache.org/archetype/archetype-packaging/index.html > Update the mini guide to creating archectypes to Archetype 2.x > -- > > Key: MNGSITE-292 > URL: https://issues.apache.org/jira/browse/MNGSITE-292 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Hervé Boutemy > > as noticed by a user recently, the > [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] > explains about Archetype 1.x, with its archetype.xml descriptor, which is > deprecated: Archetype 2.x has its descriptor with a different schema under > archetype-metadata.xml (there may be other differences, I did not investigate > in details) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MNGSITE-292) Update the mini guide to creating archectypes to Archetype 2.x
[ https://issues.apache.org/jira/browse/MNGSITE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MNGSITE-292: -- Description: as noticed by a user recently, the [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] explains about Archetype 1.x, with its archetype.xml descriptor, which is deprecated: Archetype 2.x has its descriptor with a different schema under archetype-metadata.xml (there may be other differences, I did not investigate in details) (was: as noticed by a user recently, the mini-guide explains about Archetype 1.x, with its archetype.xml descriptor, which is deprecated: Archetype 2.x has its descriptor with a different schema under archetype-metadata.xml (there may be other differences, I did not investigate in details)) > Update the mini guide to creating archectypes to Archetype 2.x > -- > > Key: MNGSITE-292 > URL: https://issues.apache.org/jira/browse/MNGSITE-292 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Hervé Boutemy > > as noticed by a user recently, the > [mini-guide|https://maven.apache.org/guides/mini/guide-creating-archetypes.html] > explains about Archetype 1.x, with its archetype.xml descriptor, which is > deprecated: Archetype 2.x has its descriptor with a different schema under > archetype-metadata.xml (there may be other differences, I did not investigate > in details) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNGSITE-292) Update the mini guide to creating archectypes to Archetype 2.x
Hervé Boutemy created MNGSITE-292: - Summary: Update the mini guide to creating archectypes to Archetype 2.x Key: MNGSITE-292 URL: https://issues.apache.org/jira/browse/MNGSITE-292 Project: Maven Project Web Site Issue Type: Improvement Reporter: Hervé Boutemy as noticed by a user recently, the mini-guide explains about Archetype 1.x, with its archetype.xml descriptor, which is deprecated: Archetype 2.x has its descriptor with a different schema under archetype-metadata.xml (there may be other differences, I did not investigate in details) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
