[jira] [Commented] (MSITE-804) update Doxia Site Renderer to 1.8
[ https://issues.apache.org/jira/browse/MSITE-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292109#comment-16292109 ] Hervé Boutemy commented on MSITE-804: - editable field integration: https://gitbox.apache.org/repos/asf?p=maven-site-plugin.git=commit=459152d25e11ae72e7598b29c4c508cadef67c13 generator field integration: https://gitbox.apache.org/repos/asf?p=maven-site-plugin.git=commit=1ca2fb3e86f742b365f580ce02c46c1de1a50d97 > update Doxia Site Renderer to 1.8 > - > > Key: MSITE-804 > URL: https://issues.apache.org/jira/browse/MSITE-804 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.6 >Reporter: Hervé Boutemy > Fix For: 3.7 > > > to benefit from DOXIASITETOOLS-181, DOXIASITETOOLS-182, DOXIASITETOOLS-184 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (DOXIASITETOOLS-184) add generator field to document RenderingContext to get info on report
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed DOXIASITETOOLS-184. Resolution: Fixed https://gitbox.apache.org/repos/asf?p=maven-doxia-sitetools.git=commit=2fe1061a26aafd35db9d3c73daeab2e01a082946 > add generator field to document RenderingContext to get info on report > -- > > Key: DOXIASITETOOLS-184 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-184 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 1.7.5 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.8 > > > after adding info on Doxia source in DOXIASITETOOLS-181, getting info on > report that generated content is natural -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1453) Allow to specify non existant classes as "groups"
[
https://issues.apache.org/jira/browse/SUREFIRE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292093#comment-16292093
]
Enrico Olivelli commented on SUREFIRE-1453:
---
I will try to send my proposal today.
I will need help/suggestions about adding it tests for each provider.
> Allow to specify non existant classes as "groups"
> -
>
> Key: SUREFIRE-1453
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1453
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading, Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Enrico Olivelli
>Assignee: Tibor Digana
>Priority: Critical
>
> In a reactor project I would like to run only a subset of JUnit (4.12) tests
> tagged with @Category
> But the class which defines the category is not present in the dependency
> tree of every module.
> I get this error.
> I would like to simply skip these modules, maybe in conjunction with the
> failIfNoTest=false option
> {code:java}
> rg.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category:
> magnews.testgroups.MinimumAcceptance
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException:
> magnews.testgroups.MinimumAcceptance
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] maven-surefire pull request #166: Support filtering of tests from Base Class...
Github user krmahadevan closed the pull request at: https://github.com/apache/maven-surefire/pull/166 ---
[GitHub] maven-surefire issue #166: Support filtering of tests from Base Class (TestN...
Github user krmahadevan commented on the issue: https://github.com/apache/maven-surefire/pull/166 Changeset has been merged as part of https://github.com/apache/maven-surefire/commit/39acb98a94242149b5a8374a9619eb06f6b3cb6d Closing this PR. @Tibor17 thanks for helping me with this PR. ---
[jira] [Commented] (MSITE-804) update Doxia Site Renderer to 1.8
[ https://issues.apache.org/jira/browse/MSITE-804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292026#comment-16292026 ] Hudson commented on MSITE-804: -- Build succeeded in Jenkins: Maven TLP » maven-site-plugin » master #8 See https://builds.apache.org/job/maven-box/job/maven-site-plugin/job/master/8/ > update Doxia Site Renderer to 1.8 > - > > Key: MSITE-804 > URL: https://issues.apache.org/jira/browse/MSITE-804 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.6 >Reporter: Hervé Boutemy > Fix For: 3.7 > > > to benefit from DOXIASITETOOLS-181, DOXIASITETOOLS-182, DOXIASITETOOLS-184 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MSITE-804) update Doxia Site Renderer to 1.8
[ https://issues.apache.org/jira/browse/MSITE-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSITE-804: Description: to benefit from DOXIASITETOOLS-181, DOXIASITETOOLS-182, DOXIASITETOOLS-184 (was: to benefit from DOXIASITETOOLS-181 and DOXIASITETOOLS-182) > update Doxia Site Renderer to 1.8 > - > > Key: MSITE-804 > URL: https://issues.apache.org/jira/browse/MSITE-804 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.6 >Reporter: Hervé Boutemy > Fix For: 3.7 > > > to benefit from DOXIASITETOOLS-181, DOXIASITETOOLS-182, DOXIASITETOOLS-184 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DOXIASITETOOLS-184) add generator field to document RenderingContext to get info on report
[ https://issues.apache.org/jira/browse/DOXIASITETOOLS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16292015#comment-16292015 ] Hudson commented on DOXIASITETOOLS-184: --- Build succeeded in Jenkins: Maven TLP » maven-doxia-sitetools » master #13 See https://builds.apache.org/job/maven-box/job/maven-doxia-sitetools/job/master/13/ > add generator field to document RenderingContext to get info on report > -- > > Key: DOXIASITETOOLS-184 > URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-184 > Project: Maven Doxia Sitetools > Issue Type: Improvement > Components: Site renderer >Affects Versions: 1.7.5 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 1.8 > > > after adding info on Doxia source in DOXIASITETOOLS-181, getting info on > report that generated content is natural -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (DOXIASITETOOLS-184) add generator field to document RenderingContext to get info on report
Hervé Boutemy created DOXIASITETOOLS-184: Summary: add generator field to document RenderingContext to get info on report Key: DOXIASITETOOLS-184 URL: https://issues.apache.org/jira/browse/DOXIASITETOOLS-184 Project: Maven Doxia Sitetools Issue Type: Improvement Components: Site renderer Affects Versions: 1.7.5 Reporter: Hervé Boutemy Assignee: Hervé Boutemy Fix For: 1.8 after adding info on Doxia source in DOXIASITETOOLS-181, getting info on report that generated content is natural -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1452) Support filtering of tests from Base Class (TestNG)
[
https://issues.apache.org/jira/browse/SUREFIRE-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291755#comment-16291755
]
Hudson commented on SUREFIRE-1452:
--
SUCCESS: Integrated in Jenkins build maven-surefire #1811 (See
[https://builds.apache.org/job/maven-surefire/1811/])
[SUREFIRE-1452] Support filtering of tests from Base Class (TestNG) (tibor17:
[http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=39acb98a94242149b5a8374a9619eb06f6b3cb6d])
* (add)
surefire-providers/surefire-testng-utils/src/test/java/testng/utils/MethodSelectorTest.java
* (edit)
surefire-providers/surefire-testng-utils/src/main/java/org/apache/maven/surefire/testng/utils/MethodSelector.java
* (add)
surefire-providers/surefire-testng-utils/src/test/java/testng/utils/ChildClassSample.java
* (add)
surefire-providers/surefire-testng-utils/src/test/java/testng/utils/BaseClassSample.java
> Support filtering of tests from Base Class (TestNG)
> ---
>
> Key: SUREFIRE-1452
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1452
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, TestNG
> support
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.21.0.Jigsaw
>
>
> User has two test classes.
> An abstract base class called {{BaseTest}} which contains an {{@Test}} method
> called {{testMethodFromBase}}. A child class called {{ChildTest}} which
> extends {{BaseTest}}.
> User attempts at running the TestNG test via
> {{-Dtest=ChildTest#testMethodFromBase}}.
> This PR basically addresses only the TestNG portion of the bug
> https://github.com/cbeust/testng/issues/1563
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1453) Allow to specify non existant classes as "groups"
[
https://issues.apache.org/jira/browse/SUREFIRE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291743#comment-16291743
]
Tibor Digana commented on SUREFIRE-1453:
[~eolivelli]
Would you have spare time to fix this issue and included in version {{2.21.0}}?
> Allow to specify non existant classes as "groups"
> -
>
> Key: SUREFIRE-1453
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1453
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading, Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Enrico Olivelli
>Assignee: Tibor Digana
>Priority: Critical
>
> In a reactor project I would like to run only a subset of JUnit (4.12) tests
> tagged with @Category
> But the class which defines the category is not present in the dependency
> tree of every module.
> I get this error.
> I would like to simply skip these modules, maybe in conjunction with the
> failIfNoTest=false option
> {code:java}
> rg.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category:
> magnews.testgroups.MinimumAcceptance
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException:
> magnews.testgroups.MinimumAcceptance
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291739#comment-16291739
]
ASF GitHub Bot commented on SUREFIRE-1372:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/150
@mpkorstanje
I saw you typed version `2.21`. It should be `2.21.0`. Pls fix this as
well. Thx.
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] maven-surefire issue #150: SUREFIRE-1372 Filter tests to be rerun by descrip...
Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/150 @mpkorstanje I saw you typed version `2.21`. It should be `2.21.0`. Pls fix this as well. Thx. ---
[jira] [Assigned] (SUREFIRE-1453) Allow to specify non existant classes as "groups"
[
https://issues.apache.org/jira/browse/SUREFIRE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned SUREFIRE-1453:
--
Assignee: Tibor Digana
> Allow to specify non existant classes as "groups"
> -
>
> Key: SUREFIRE-1453
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1453
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading, Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Enrico Olivelli
>Assignee: Tibor Digana
>Priority: Critical
>
> In a reactor project I would like to run only a subset of JUnit (4.12) tests
> tagged with @Category
> But the class which defines the category is not present in the dependency
> tree of every module.
> I get this error.
> I would like to simply skip these modules, maybe in conjunction with the
> failIfNoTest=false option
> {code:java}
> rg.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category:
> magnews.testgroups.MinimumAcceptance
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException:
> magnews.testgroups.MinimumAcceptance
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1372) Rerunning failing tests fails in combination with Description#createSuiteDescription
[
https://issues.apache.org/jira/browse/SUREFIRE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291731#comment-16291731
]
ASF GitHub Bot commented on SUREFIRE-1372:
--
Github user Tibor17 commented on the issue:
https://github.com/apache/maven-surefire/pull/150
@mpkorstanje
Now I understand the Cucumber internals.
Can you write the documentation?
Fix the checkstyle in your integration test and the classes
`FlakeCucumberTest`.
Then try to alter the behavior of the integration test with Maven profile
(junit4 and junit47). We are already doing it, see `addGoal( "-P junit4" )`,
`addGoal( "-P junit47" )`.
This would lead to `@Parameterized` IT which exists in our code already,
see `FailFastJUnitIT` as a hint.
> Rerunning failing tests fails in combination with
> Description#createSuiteDescription
>
>
> Key: SUREFIRE-1372
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1372
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20
>Reporter: M.P. Korstanje
>Assignee: Tibor Digana
> Fix For: 2.21.1
>
>
> When using surefire to rerun failing tests created by a Runner that uses
> {noformat}Description#createSuiteDescription{noformat} with a human readable
> name rather then a class name the following stack trace occurs:
> {code}
> org.apache.maven.surefire.testset.TestSetFailedException: Unable to create
> test class 'Scenario: Fail when running'
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:385)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> Caused by: java.lang.ClassNotFoundException: Scenario: Fail when running
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeFailedMethod(JUnit4Provider.java:379)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:292)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] maven-surefire issue #150: SUREFIRE-1372 Filter tests to be rerun by descrip...
Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/150 @mpkorstanje Now I understand the Cucumber internals. Can you write the documentation? Fix the checkstyle in your integration test and the classes `FlakeCucumberTest`. Then try to alter the behavior of the integration test with Maven profile (junit4 and junit47). We are already doing it, see `addGoal( "-P junit4" )`, `addGoal( "-P junit47" )`. This would lead to `@Parameterized` IT which exists in our code already, see `FailFastJUnitIT` as a hint. ---
[jira] [Created] (SCM-857) AnnotateConsumer fails to parse author name if name contains dot
Rahul Maheshwari created SCM-857:
Summary: AnnotateConsumer fails to parse author name if name
contains dot
Key: SCM-857
URL: https://issues.apache.org/jira/browse/SCM-857
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-accurev
Affects Versions: 1.9.5
Reporter: Rahul Maheshwari
Priority: Critical
AnnotateConsumer fails to parse author name if accurev user name contains dot
(".")
Sample annotation output that contains user name with dot
{code:java}
10 john.x.doe 2017/12/13 15:10:34 buildscript {
10 john.x.doe 2017/12/13 15:10:34 repositories {
10 john.x.doe 2017/12/13 15:10:34 mavenCentral()
10 john.x.doe 2017/12/13 15:10:34 }
10 john.x.doe 2017/12/13 15:10:34 dependencies {
10 john.x.doe 2017/12/13 15:10:34
10 john.x.doe 2017/12/13 15:10:34 }
10 john.x.doe 2017/12/13 15:10:34 }
{code}
Exception Details:
{code:java}
Caused by: java.lang.RuntimeException: Unable to parse annotation from line:
10 john.x.doe 2017/12/13 15:10:34 buildscript {
at
org.apache.maven.scm.provider.accurev.cli.AnnotateConsumer.consumeLine(AnnotateConsumer.java:69)
at
org.apache.maven.scm.provider.accurev.cli.CommandOutputConsumer.consumeLine(CommandOutputConsumer.java:51)
at
org.codehaus.plexus.util.cli.StreamPumper.consumeLine(StreamPumper.java:190)
at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:135)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] maven-surefire issue #166: Support filtering of tests from Base Class (TestN...
Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/166 @krmahadevan Thx for contributing. Now you should close this PR. ---
[jira] [Closed] (SUREFIRE-1452) Support filtering of tests from Base Class (TestNG)
[
https://issues.apache.org/jira/browse/SUREFIRE-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1452.
--
Resolution: Fixed
https://git1-us-west.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=39acb98a94242149b5a8374a9619eb06f6b3cb6d
> Support filtering of tests from Base Class (TestNG)
> ---
>
> Key: SUREFIRE-1452
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1452
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin, TestNG
> support
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.21.0.Jigsaw
>
>
> User has two test classes.
> An abstract base class called {{BaseTest}} which contains an {{@Test}} method
> called {{testMethodFromBase}}. A child class called {{ChildTest}} which
> extends {{BaseTest}}.
> User attempts at running the TestNG test via
> {{-Dtest=ChildTest#testMethodFromBase}}.
> This PR basically addresses only the TestNG portion of the bug
> https://github.com/cbeust/testng/issues/1563
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291653#comment-16291653
]
Hudson commented on MNG-6308:
-
Build unstable in Jenkins: Maven TLP (wip) » maven » MNG-6308_display_packaging
#7
See
https://builds.apache.org/job/maven-wip/job/maven/job/MNG-6308_display_packaging/7/
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6308) display packaging when building a module
[
https://issues.apache.org/jira/browse/MNG-6308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291652#comment-16291652
]
Hudson commented on MNG-6308:
-
Build unstable in Jenkins: maven-3.x-jenkinsfile » MNG-6308_display_packaging #6
See
https://builds.apache.org/job/maven-3.x-jenkinsfile/job/MNG-6308_display_packaging/6/
> display packaging when building a module
>
>
> Key: MNG-6308
> URL: https://issues.apache.org/jira/browse/MNG-6308
> Project: Maven
> Issue Type: Improvement
>Affects Versions: 3.5.2
>Reporter: Hervé Boutemy
>Assignee: Hervé Boutemy
>
> Packaging is a key information, since it defines what bindings will be: it is
> short and should be visible in the build log
> proposal:
> {code}[INFO]
>
> [INFO] Building Apache Maven Distribution 3.5.3-SNAPSHOT
> [15/15]
> [INFO] --- pom
> --{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (WAGON-486) Wagon fails to download artifacts if number of dropped pooled connections (by intermediate) are greater than default retry count
[ https://issues.apache.org/jira/browse/WAGON-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291523#comment-16291523 ] Matt Nelson commented on WAGON-486: --- [~michael-o] I thought it was a similar issue based on a large percentage of the stack trace being down the same path. Discovered after some more troubleshooting that it was actually MRESOLVER-25 since I was able to fix the stuck build with the proposed workaround. > Wagon fails to download artifacts if number of dropped pooled connections (by > intermediate) are greater than default retry count > > > Key: WAGON-486 > URL: https://issues.apache.org/jira/browse/WAGON-486 > Project: Maven Wagon > Issue Type: Bug >Reporter: Martin Myslík > Attachments: build-failure-maven-3.5.0-patched-debug-updated.txt, > build-failure-maven-3.5.0-patched-debug.txt, build-failure-vanilla.txt, > build-success-keep-alive-false.txt, > build-success-maven-3.5.0-patched-debug.txt, build-success-pooling-false.txt, > dump-failed-build.pcap, dump.pcap > > > I was recently discussing and issue with Atlassian team concerning failing > build on Atlassian Pipelines when running Maven build for more than 5 minutes. > The issue was with NAT timeout which kills all idle connections after 5 > mintues and Maven does not try to reconnect once the connection is killed > (and hence cannot download artifacts from Maven central). > Please, take a look at the open issue (it contains more detailed description > and also comments from Atlassian which suggested opening an issue with > Maven): > https://bitbucket.org/site/master/issues/13988/pipelines-kills-idle-maven-connections > Could you, please, take a minute and explain how could proceed with solving > this issue? I am not sure whether this is something that Maven should handle > or whether it is Atlassians issue. > Thank you for your input. > This is the link to my public repo with test project running tests for 15 > mintues. This build fails on Pipelines because of Maven connection that is > being killed during the test: https://bitbucket.org/Smedzlatko/del-me -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MPMD-246) Output details of processing errors
[ https://issues.apache.org/jira/browse/MPMD-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291419#comment-16291419 ] Ryan Bard commented on MPMD-246: [~adangel], thank you for the information! I've worked around the problem by setting skipPmdError to true and just creating a named class instead of anonymous-inner-classes in those cases in my project's code. It was going to be really tempting to look at the 6.0.0 fix and maybe try to back-port it to 5.8.2 this weekend, however, if 6.0.0 is about to release, I'll just wait and use 6.0.0. Thanks again for giving me some tools to better find out what is going on if I run into issues again in the future. > Output details of processing errors > --- > > Key: MPMD-246 > URL: https://issues.apache.org/jira/browse/MPMD-246 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel > Fix For: 3.9.0 > > > To help debugging processing errors (or any error in PMD), maven should be > able to output the processing errors with exception stacktraces. > Currently, only the number of the problematic files are displayed. > Furthermore, PMD usually adds the processing errors to the XML report. But > the XML report that is generated with the maven pmd plugin doesn't contain > the errors. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MPMD-246) Output details of processing errors
[
https://issues.apache.org/jira/browse/MPMD-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291388#comment-16291388
]
Andreas Dangel commented on MPMD-246:
-
[~rbard] Thanks for the testcase. This is actually a problem in PMD itself -
I've verified, it is already fixed with the upcoming version 6.0.0 (to be
released tomorrow).
This issue here is about the problem, that it's virtually impossible at the
moment, to investigate the processing error (you currently don't get a
stacktrace out of PMD when running via m-pmd-p).
The reason, why you don't see the processing error when executing PMD on the
command line is this: It's the {{auxclasspath}} option, which is enabled by
default by the maven-pmd-plugin. It improves the detection rate of PMD, since
it can the also take type information into account and thus avoiding false
positives. Maven is a great help here, since it assembles the runtime classpath
for you (the auxclasspath contains all dependencies of the project). It can
however trigger some bug in PMD.
You can run maven in debug mode, to see, which auxclasspath is used:
{noformat}
$ ./mvnw clean verify -X
...
[INFO] --- maven-pmd-plugin:3.8:pmd (pmd) @ example1 ---
...
[DEBUG] Using aux classpath:
[/home/andreas/PMD/source/pmd-it/MPMD-246-pmd-plugin-bug/example1/target/classes,
/home/andreas/PMD/source/pmd-it/MPMD-246-pmd-plugin-bug/common/target/common-1.0-SNAPSHOT.jar]
...
{noformat}
With that, you can run it on the command line:
{noformat}
~/PMD/binaries/pmd-bin-5.8.1/bin/run.sh pmd -d example1/src -f text -R
pmdrules.xml -auxclasspath
example1/target/classes:common/target/common-1.0-SNAPSHOT.jar
{noformat}
And this now also fails with a processing error. Adding {{-V}} to the command
line gives you then the stacktrace, which is
{noformat}
Caused by: java.lang.IllegalArgumentException: No generic parameter by name T
on class
at
net.sourceforge.pmd.lang.java.typeresolution.typedefinition.JavaTypeDefinition.getGenericType(JavaTypeDefinition.java:103)
...
{noformat}
> Output details of processing errors
> ---
>
> Key: MPMD-246
> URL: https://issues.apache.org/jira/browse/MPMD-246
> Project: Maven PMD Plugin
> Issue Type: Improvement
> Components: PMD
>Reporter: Andreas Dangel
>Assignee: Andreas Dangel
> Fix For: 3.9.0
>
>
> To help debugging processing errors (or any error in PMD), maven should be
> able to output the processing errors with exception stacktraces.
> Currently, only the number of the problematic files are displayed.
> Furthermore, PMD usually adds the processing errors to the XML report. But
> the XML report that is generated with the maven pmd plugin doesn't contain
> the errors.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MJAVADOC-506) Javadoc plugin broken on Java 8 when module-info.java present
Stephen Colebourne created MJAVADOC-506: --- Summary: Javadoc plugin broken on Java 8 when module-info.java present Key: MJAVADOC-506 URL: https://issues.apache.org/jira/browse/MJAVADOC-506 Project: Maven Javadoc Plugin Issue Type: Bug Components: javadoc Affects Versions: 3.0.0 Reporter: Stephen Colebourne The fix to MJAVADOC-498 causes the command line flag `--class-path` to be used on Java 8, a flag that is not recognised. This happens when the project contains `module-info.java`, but the module-info file is excluded by the configuration of the plugin. The problem is here: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java?r1=1802722=1813672=1813672 where the code checks whether `src/main/java/module-info.java` exists without considering whether the file has been excluded by configuration. (I am simply trying to setup a build that uses Java 9 tooling on Java 9 and Java 8 tooling when running on Java 8) There is no workaround to this in v3.0.0 that I can see, so I have to rollback to v3.0.0-M1. The solution is to check the includes/excludes when trying to obtain the module-info file. Or to check what version of the Javadoc tool is being used (as per MJAVADOC-499). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MPMD-246) Output details of processing errors
[ https://issues.apache.org/jira/browse/MPMD-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291174#comment-16291174 ] Ryan Bard edited comment on MPMD-246 at 12/14/17 5:24 PM: -- I am having this problem as well. I've investigated what was going wrong in my files (what java code reproduces the problem, I don't know what is going wrong in the plugin code). It is something to do with processing java code that has an anonymous inner class overriding a method that infers it's generic type from the parameter. I have a writeup of this info and a small example here: https://github.com/RyanBard/pmd-plugin-bug EDIT: It's not inferring the type from the method param, but it is important to have an inferred type in the method parameters (no parameters didn't reproduce the problem for me). was (Author: rbard): I am having this problem as well. I've investigated what was going wrong in my files (what java code reproduces the problem, I don't know what is going wrong in the plugin code). It is something to do with processing java code that has an anonymous inner class overriding a method that infers it's generic type from the parameter. I have a writeup of this info and a small example here: https://github.com/RyanBard/pmd-plugin-bug > Output details of processing errors > --- > > Key: MPMD-246 > URL: https://issues.apache.org/jira/browse/MPMD-246 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel > Fix For: 3.9.0 > > > To help debugging processing errors (or any error in PMD), maven should be > able to output the processing errors with exception stacktraces. > Currently, only the number of the problematic files are displayed. > Furthermore, PMD usually adds the processing errors to the XML report. But > the XML report that is generated with the maven pmd plugin doesn't contain > the errors. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MPMD-246) Output details of processing errors
[ https://issues.apache.org/jira/browse/MPMD-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16291174#comment-16291174 ] Ryan Bard commented on MPMD-246: I am having this problem as well. I've investigated what was going wrong in my files (what java code reproduces the problem, I don't know what is going wrong in the plugin code). It is something to do with processing java code that has an anonymous inner class overriding a method that infers it's generic type from the parameter. I have a writeup of this info and a small example here: https://github.com/RyanBard/pmd-plugin-bug > Output details of processing errors > --- > > Key: MPMD-246 > URL: https://issues.apache.org/jira/browse/MPMD-246 > Project: Maven PMD Plugin > Issue Type: Improvement > Components: PMD >Reporter: Andreas Dangel >Assignee: Andreas Dangel > Fix For: 3.9.0 > > > To help debugging processing errors (or any error in PMD), maven should be > able to output the processing errors with exception stacktraces. > Currently, only the number of the problematic files are displayed. > Furthermore, PMD usually adds the processing errors to the XML report. But > the XML report that is generated with the maven pmd plugin doesn't contain > the errors. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MJAVADOC-505) "Warning: no description for @throws" shows even after adding -Xdoclint:none
Devran created MJAVADOC-505: --- Summary: "Warning: no description for @throws" shows even after adding -Xdoclint:none Key: MJAVADOC-505 URL: https://issues.apache.org/jira/browse/MJAVADOC-505 Project: Maven Javadoc Plugin Issue Type: Bug Components: javadoc Affects Versions: 3.0.0 Environment: Windows 7. Netbeans 8.2 Reporter: Devran Priority: Minor Hi, I am not sure if this is intended or if it is a bug, but in version 3.0.0, when adding "Xdoclint:none", this warning is not ignored: "no description for @throws". It is ignored in version 3.0.0-M1. Thank you -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1453) Allow to specify non existant classes as "groups"
[
https://issues.apache.org/jira/browse/SUREFIRE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16290921#comment-16290921
]
Tibor Digana commented on SUREFIRE-1453:
[~eolivelli]
No objections from my side.
You can make some sanity check of every included/excluded group class in
Provider's ClassLoader and filter only those which exist.
After you have finished the fix, pls run the build {{mvn install -P run-its}}.
I think same issue has been discussed in Jira several days or weeks ago. So one
is duplicate then.
> Allow to specify non existant classes as "groups"
> -
>
> Key: SUREFIRE-1453
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1453
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading, Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Enrico Olivelli
>Priority: Critical
>
> In a reactor project I would like to run only a subset of JUnit (4.12) tests
> tagged with @Category
> But the class which defines the category is not present in the dependency
> tree of every module.
> I get this error.
> I would like to simply skip these modules, maybe in conjunction with the
> failIfNoTest=false option
> {code:java}
> rg.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category:
> magnews.testgroups.MinimumAcceptance
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException:
> magnews.testgroups.MinimumAcceptance
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (ARCHETYPE-492) Underscore in filenames problematic due to greedy regex
[
https://issues.apache.org/jira/browse/ARCHETYPE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16290895#comment-16290895
]
Matthias Hanisch edited comment on ARCHETYPE-492 at 12/14/17 2:20 PM:
--
Got the same problem today. Wanted to generate a file
errors_${artifactId}.properties, so I chose the filename
errorsartifactId___.properties in the archetype.
The placeholder in the file name was not resolved.
was (Author: matze):
Got the same problem today. Wanted to generate a file
errors_${artifactId}.properties, so I chose the filename
errors___artifactId__.properties in the archetype.
The placeholder in the file name was not resolved.
> Underscore in filenames problematic due to greedy regex
> ---
>
> Key: ARCHETYPE-492
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-492
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 2.4
> Environment: Windows 7, Sun JDK
>Reporter: Oliver Dungey
>
> If you have a file in a project with an underscore adjacent to a substitution
> variable, the substitution will fail i.e.
> if {{artifactId}} is 'Test' and a target file is to be named
> {{something_test.txt}} the file in the template should be named
> {{somethingartifactId__.txt}} (3 underscores in the middle) but the
> result is an error stating that the property {{_artifactId}} cannot be found.
> This is because the term inside the regex is a greedy .* - a simple fix
> would be to change this to something like __[^_]*___ which would only match
> non-underscore characters.
> Fixing this issue would allow the use of underscores in filenames in all
> circumstances rather than the current situation where you may get lucky. The
> only down side to fixing this issue is that properties with leading or
> trailing underscores will not be valid - this seems a far more preferable
> situation.
> A patch for this issue was put on this bug back in 01//2009 but somehow got
> ignored - see [~maslovalex] patch and comments at the end of this issue:
> https://issues.apache.org/jira/browse/ARCHETYPE-191
> Apologies for the formatting - it appears double underscores are an issue :-)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ARCHETYPE-492) Underscore in filenames problematic due to greedy regex
[
https://issues.apache.org/jira/browse/ARCHETYPE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16290895#comment-16290895
]
Matthias Hanisch commented on ARCHETYPE-492:
Got the same problem today. Wanted to generate a file
errors_${artifactId}.properties, so I chose the filename
errors___artifactId__.properties in the archetype.
The placeholder in the file name was not resolved.
> Underscore in filenames problematic due to greedy regex
> ---
>
> Key: ARCHETYPE-492
> URL: https://issues.apache.org/jira/browse/ARCHETYPE-492
> Project: Maven Archetype
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 2.4
> Environment: Windows 7, Sun JDK
>Reporter: Oliver Dungey
>
> If you have a file in a project with an underscore adjacent to a substitution
> variable, the substitution will fail i.e.
> if {{artifactId}} is 'Test' and a target file is to be named
> {{something_test.txt}} the file in the template should be named
> {{somethingartifactId__.txt}} (3 underscores in the middle) but the
> result is an error stating that the property {{_artifactId}} cannot be found.
> This is because the term inside the regex is a greedy .* - a simple fix
> would be to change this to something like __[^_]*___ which would only match
> non-underscore characters.
> Fixing this issue would allow the use of underscores in filenames in all
> circumstances rather than the current situation where you may get lucky. The
> only down side to fixing this issue is that properties with leading or
> trailing underscores will not be valid - this seems a far more preferable
> situation.
> A patch for this issue was put on this bug back in 01//2009 but somehow got
> ignored - see [~maslovalex] patch and comments at the end of this issue:
> https://issues.apache.org/jira/browse/ARCHETYPE-191
> Apologies for the formatting - it appears double underscores are an issue :-)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1453) Allow to specify non existant classes as "groups"
[
https://issues.apache.org/jira/browse/SUREFIRE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16290719#comment-16290719
]
Enrico Olivelli commented on SUREFIRE-1453:
---
This thread is relevant to this issue:
https://stackoverflow.com/questions/41065441/is-there-an-interface-in-a-third-party-library-to-use-for-junit-category
> Allow to specify non existant classes as "groups"
> -
>
> Key: SUREFIRE-1453
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1453
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading, Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Enrico Olivelli
>Priority: Critical
>
> In a reactor project I would like to run only a subset of JUnit (4.12) tests
> tagged with @Category
> But the class which defines the category is not present in the dependency
> tree of every module.
> I get this error.
> I would like to simply skip these modules, maybe in conjunction with the
> failIfNoTest=false option
> {code:java}
> rg.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category:
> magnews.testgroups.MinimumAcceptance
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException:
> magnews.testgroups.MinimumAcceptance
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1453) Allow to specify non existant classes as "groups"
[
https://issues.apache.org/jira/browse/SUREFIRE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16290716#comment-16290716
]
Enrico Olivelli commented on SUREFIRE-1453:
---
[~tibor17] does this sound reasonable to you ?
The patch would be simple, in case of ClassNotFoundException we can assume that
there is no test which matches the filter.
If this approach is good to you I can start working on this, and I would like
to try to make it for the next release, it will unlock some project of mine
> Allow to specify non existant classes as "groups"
> -
>
> Key: SUREFIRE-1453
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1453
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading, Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Enrico Olivelli
>
> In a reactor project I would like to run only a subset of JUnit (4.12) tests
> tagged with @Category
> But the class which defines the category is not present in the dependency
> tree of every module.
> I get this error.
> I would like to simply skip these modules, maybe in conjunction with the
> failIfNoTest=false option
> {code:java}
> rg.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category:
> magnews.testgroups.MinimumAcceptance
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException:
> magnews.testgroups.MinimumAcceptance
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1453) Allow to specify non existant classes as "groups"
[
https://issues.apache.org/jira/browse/SUREFIRE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli updated SUREFIRE-1453:
--
Priority: Critical (was: Major)
> Allow to specify non existant classes as "groups"
> -
>
> Key: SUREFIRE-1453
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1453
> Project: Maven Surefire
> Issue Type: Improvement
> Components: classloading, Junit 4.x support, Maven Surefire Plugin
>Affects Versions: 2.19.1
>Reporter: Enrico Olivelli
>Priority: Critical
>
> In a reactor project I would like to run only a subset of JUnit (4.12) tests
> tagged with @Category
> But the class which defines the category is not present in the dependency
> tree of every module.
> I get this error.
> I would like to simply skip these modules, maybe in conjunction with the
> failIfNoTest=false option
> {code:java}
> rg.apache.maven.surefire.util.SurefireReflectionException:
> java.lang.reflect.InvocationTargetException; nested exception is
> java.lang.reflect.InvocationTargetException: null
> java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at
> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> Caused by: java.lang.RuntimeException: Unable to load category:
> magnews.testgroups.MinimumAcceptance
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
> at
> org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
> at
> org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
> ... 9 more
> Caused by: java.lang.ClassNotFoundException:
> magnews.testgroups.MinimumAcceptance
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
> ... 12 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SUREFIRE-1453) Allow to specify non existant classes as "groups"
Enrico Olivelli created SUREFIRE-1453:
-
Summary: Allow to specify non existant classes as "groups"
Key: SUREFIRE-1453
URL: https://issues.apache.org/jira/browse/SUREFIRE-1453
Project: Maven Surefire
Issue Type: Improvement
Components: classloading, Junit 4.x support, Maven Surefire Plugin
Affects Versions: 2.19.1
Reporter: Enrico Olivelli
In a reactor project I would like to run only a subset of JUnit (4.12) tests
tagged with @Category
But the class which defines the category is not present in the dependency tree
of every module.
I get this error.
I would like to simply skip these modules, maybe in conjunction with the
failIfNoTest=false option
{code:java}
rg.apache.maven.surefire.util.SurefireReflectionException:
java.lang.reflect.InvocationTargetException; nested exception is
java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.RuntimeException: Unable to load category:
magnews.testgroups.MinimumAcceptance
at
org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
at
org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
at
org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
at
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
... 9 more
Caused by: java.lang.ClassNotFoundException:
magnews.testgroups.MinimumAcceptance
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at
org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
... 12 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNG-6320) Apparently wrong encoding of non-ascii java class filename in error messages in the maven log
Eugene Pliskin created MNG-6320: --- Summary: Apparently wrong encoding of non-ascii java class filename in error messages in the maven log Key: MNG-6320 URL: https://issues.apache.org/jira/browse/MNG-6320 Project: Maven Issue Type: Bug Components: Logging Affects Versions: 3.5.2 Environment: Windows 10 Reporter: Eugene Pliskin Priority: Minor Attachments: maven.3.3.9.log, maven.3.5.2.log Attached please find two build logs, one from maven version 3.3.9, and another from maven version 3.5.2. Both log files were made for the same Java project on Windows 10 machine, with "mvn compile > log" command. Java platform default encoding is UTF-8. One Java source file contains intentional error, which is reported in lines 433-435 of file "maven.3.3.9.log", and in lines 437-439 of file "maven.3.5.2.log". Class name is non-ascii and version 3.3.9 log appears right. But in version 3.5.2 this same filename appears unreadable in the error message in the maven log. Notice that if I view the file "maven.3.5.2.log" with different encoding (cp866), then this error message becomes readable. It looks like this non-ascii filename gets inserted into UTF-8 encoded log file in wrong "cp866" encoding, in maven version 3.5.2. Still, version 3.3.9 of maven does the right thing, and the error message is readable in UTF-8 log. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (MANTRUN-207) scriptdef ignores CDATA when there is also an element
Matteo Steccolini created MANTRUN-207: - Summary: scriptdef ignores CDATA when there is also an element Key: MANTRUN-207 URL: https://issues.apache.org/jira/browse/MANTRUN-207 Project: Maven Antrun Plugin Issue Type: Bug Affects Versions: 1.8, 1.7, 1.6, 1.5, 1.4, 1.3, 1.2, 1.1, 1.0 Environment: Windows 10 64bit, java 1.8.0_151, maven 3.5.0 Reporter: Matteo Steccolini Attachments: build-main.xml, pom.xml When I put a CDATA node inside a scriptdef which has also an element node, the cdata is ignored. You can see it in the attached build-main.xml that is generated from the attached pom.xml (mvn antrun:run@hello). When I though I might be doing something wrong I wrote this question on stackoverflow: [https://stackoverflow.com/questions/47796805/maven-antrun-plugin-scriptdef-ignores-cdata-when-i-add-an-element] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
