[jira] [Commented] (SUREFIRE-1229) Cucumber parallel tests using Surefire throws NPE
[ https://issues.apache.org/jira/browse/SUREFIRE-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146457#comment-15146457 ] Tibor Digana commented on SUREFIRE-1229: [~mpalki] Feel free to reopen this issue as necessary. > Cucumber parallel tests using Surefire throws NPE > - > > Key: SUREFIRE-1229 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1229 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.18.1 >Reporter: Manoj Palki > > I am running Cucumber feature files in parallel using the surefire config > 20 > classes > true > The tests run successfully. But at the end I get the following NPE > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on > project accounts-webservice: Execution default-test of goal > org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test failed: There was > an error in the forked process > [ERROR] org.apache.maven.surefire.testset.TestSetFailedException: > java.lang.NullPointerException > [ERROR] at > org.apache.maven.surefire.common.junit4.JUnit4RunListener.rethrowAnyTestMechanismFailures(JUnit4RunListener.java:213) > [ERROR] at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:109) > [ERROR] at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78) > [ERROR] at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54) > [ERROR] at > org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144) > [ERROR] at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203) > [ERROR] at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) > [ERROR] at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) > [ERROR] Caused by: java.lang.NullPointerException > [ERROR] at > org.apache.maven.surefire.junitcore.ConcurrentRunListener.testStarting(ConcurrentRunListener.java:129) > [ERROR] at > org.apache.maven.surefire.common.junit4.JUnit4RunListener.testStarted(JUnit4RunListener.java:91) > [ERROR] at > org.junit.runner.notification.RunNotifier$3.notifyListener(RunNotifier.java:115) > [ERROR] at > org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:61) > [ERROR] at > org.junit.runner.notification.RunNotifier.fireTestStarted(RunNotifier.java:112) > [ERROR] at > org.junit.internal.runners.model.EachTestNotifier.fireTestStarted(EachTestNotifier.java:43) > [ERROR] at > cucumber.runtime.junit.JUnitReporter.startExecutionUnit(JUnitReporter.java:50) > [ERROR] at > cucumber.runtime.junit.ExecutionUnitRunner.run(ExecutionUnitRunner.java:89) > [ERROR] at > cucumber.runtime.junit.FeatureRunner.runChild(FeatureRunner.java:63) > [ERROR] at > cucumber.runtime.junit.FeatureRunner.runChild(FeatureRunner.java:18) > [ERROR] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > [ERROR] at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > [ERROR] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > [ERROR] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > [ERROR] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > [ERROR] at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > [ERROR] at cucumber.runtime.junit.FeatureRunner.run(FeatureRunner.java:70) > [ERROR] at cucumber.api.junit.Cucumber.runChild(Cucumber.java:93) > [ERROR] at cucumber.api.junit.Cucumber.runChild(Cucumber.java:37) > [ERROR] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > [ERROR] at > org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:387) > [ERROR] at > org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54) > [ERROR] at > org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:346) > [ERROR] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > [ERROR] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > [ERROR] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > [ERROR] at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > [ERROR] at cucumber.api.junit.Cucumber.run(Cucumber.java:98) > [ERROR] at org.junit.runners.Suite.runChild(Suite.java:127) > [ERROR] at org.junit.runners.Suite.runChild(Suite.java:26) > [ERROR] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > [ERROR] at > org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:387) > [ERROR] at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [ERROR] at java.util.concurrent.Futur
[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=15146512#comment-15146512
]
Tibor Digana commented on SUREFIRE-1220:
[~agudian]
As you mentioned 3. option, is it better to take UTF-8 or value in
{{project.reporting.outputEncoding}}?
> 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] [Updated] (SUREFIRE-1223) Cannot run invoker ITs on Windows with Maven 3.3.1+
[
https://issues.apache.org/jira/browse/SUREFIRE-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1223:
---
Issue Type: Task (was: Bug)
> Cannot run invoker ITs on Windows with Maven 3.3.1+
> ---
>
> Key: SUREFIRE-1223
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1223
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin
>Affects Versions: 2.19.1
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 2.19.2
>
>
> The error output is:
> {noformat}
> [INFO]
> [INFO] --- maven-invoker-plugin:1.9:run (integration-test) @
> maven-failsafe-plugin ---
> [INFO] Building: jetty-war-test-failing\pom.xml
> [INFO] ..FAILED (0.0 s)
> [INFO] Maven invocation failed. Error configuring command-line. Reason:
> Maven executable not found at:
> D:\Entwicklung\Programme\apache-maven-3.3.9\bin\mvn.bat
> [INFO] Building: jetty-war-test-passing\pom.xml
> [INFO] ..FAILED (0.0 s)
> [INFO] Maven invocation failed. Error configuring command-line. Reason:
> Maven executable not found at:
> D:\Entwicklung\Programme\apache-maven-3.3.9\bin\mvn.bat
> [INFO] Building: multiple-summaries\pom.xml
> [INFO] ..FAILED (0.0 s)
> [INFO] Maven invocation failed. Error configuring command-line. Reason:
> Maven executable not found at:
> D:\Entwicklung\Programme\apache-maven-3.3.9\bin\mvn.bat
> [INFO] Building: multiple-summaries-failing\pom.xml
> [INFO] ..FAILED (0.0 s)
> [INFO] Maven invocation failed. Error configuring command-line. Reason:
> Maven executable not found at:
> D:\Entwicklung\Programme\apache-maven-3.3.9\bin\mvn.bat
> [INFO] Building: working-directory\pom.xml
> [INFO] ..FAILED (0.0 s)
> [INFO] Maven invocation failed. Error configuring command-line. Reason:
> Maven executable not found at:
> D:\Entwicklung\Programme\apache-maven-3.3.9\bin\mvn.bat
> [INFO] -
> {noformat}
> Maven Invoker Plugin version needs to be updated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1218) Improve fork-options-and-parallel-execution.html upon Stackoverflow users pitfalls
[ https://issues.apache.org/jira/browse/SUREFIRE-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1218: --- Issue Type: Documentation (was: Improvement) > Improve fork-options-and-parallel-execution.html upon Stackoverflow users > pitfalls > -- > > Key: SUREFIRE-1218 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1218 > Project: Maven Surefire > Issue Type: Documentation > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > > Providing solutions for user pitfalls: > * Selenium fails in parallel tests execution using @BeforeClass due to using > shared static code > * correct use of dependency JCPI artifact > * explained rules about optimizations > * added current name of plugin > * added missing version 2.16 in a part of the document > * improved document styling -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SUREFIRE-1218) Improve fork-options-and-parallel-execution.html upon Stackoverflow users pitfalls
[ https://issues.apache.org/jira/browse/SUREFIRE-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana updated SUREFIRE-1218: --- Description: Providing solutions for user pitfalls: * Selenium fails in parallel tests execution using @BeforeClass due to using shared static code * correct use of dependency JCIP artifact * explained rules about optimizations * added current name of plugin * added missing version 2.16 in a part of the document * improved document styling * more clarified specification around @NotThreadSafe in use cases with JUnit Suites was: Providing solutions for user pitfalls: * Selenium fails in parallel tests execution using @BeforeClass due to using shared static code * correct use of dependency JCPI artifact * explained rules about optimizations * added current name of plugin * added missing version 2.16 in a part of the document * improved document styling > Improve fork-options-and-parallel-execution.html upon Stackoverflow users > pitfalls > -- > > Key: SUREFIRE-1218 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1218 > Project: Maven Surefire > Issue Type: Documentation > Components: Maven Failsafe Plugin, Maven Surefire Plugin >Affects Versions: 2.19.1 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.19.2 > > > Providing solutions for user pitfalls: > * Selenium fails in parallel tests execution using @BeforeClass due to using > shared static code > * correct use of dependency JCIP artifact > * explained rules about optimizations > * added current name of plugin > * added missing version 2.16 in a part of the document > * improved document styling > * more clarified specification around @NotThreadSafe in use cases with JUnit > Suites -- 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=15146516#comment-15146516
]
Michael Osipov commented on SUREFIRE-1220:
--
What I can say it that "TestOutput file (.txt): unchanged bytes as written by
the forked VM" is not true. The file is written in the encoding of the parent
VM, I wrote that already.
> 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] (MNG-5935) Optional true getting lost in managed dependencies when transitive
[ https://issues.apache.org/jira/browse/MNG-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146609#comment-15146609 ] Sergey Tryuber commented on MNG-5935: - Also faced this issue (observed as some transitive dependencies of "provided" dependencies were included into final archetype). Confirm it's fixed in 3.4.0-SNAPSHOT. > Optional true getting lost in managed dependencies when transitive > -- > > Key: MNG-5935 > URL: https://issues.apache.org/jira/browse/MNG-5935 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\Temp\apache-maven-3.3.9 > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\Prog\Java\v8_66\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Marcel Schutte >Assignee: Christian Schulte > Fix For: 3.4.0 > > Attachments: Parent.zip, buildoutput.txt > > > Run 'mvn package' on the project in the attached Parent.zip. Note that the > dependency Jar2 gets packaged in WEB-INF/lib and the other dependencies (Jar, > Jar1 and Jar3) do not. > I think the inclusion of Jar2 is incorrect, because project 'Web' declares > its dependency on 'Jar' to be optional and Jar2 being a transitive dependency > of Jar should inherit this. > If you look at the other Jarx dependencies, they have different combinations > of ways to become optional and have their versions managed. Only the case > when optionality is inherited and the dependency management for the version > is in another pom, yields incorrect results. > Please note that I believe the maven-war-plugin is not the cause of this > behavior. I have built and used a modified version of maven-war-plugin which > as the first thing in its WarMojo.execute() lists the result of > getProject().getArtifacts() including the value of each Artifact's > isOptional() method. Already at this point only Jar2 has optional false. > I am using maven-war-plugin in this bug report for the following reasons: > * maven-war-plugin uses the optional flag of dependencies in deciding whether > to package it or not, making this behavior visible > * I don't know of another way to visualize the value of the optional flag in > core maven (running with -X outputs the dependency tree in a section with > header 'Dependency collection stats', but this only shows the scope value) > * maven-dependency-plugin:resolve also only shows scope and not optionality > * obviously, maven-war-plugin is exactly what I intend to use and where I > found the bug -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MNG-5935) Optional true getting lost in managed dependencies when transitive
[ https://issues.apache.org/jira/browse/MNG-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146609#comment-15146609 ] Sergey Tryuber edited comment on MNG-5935 at 2/14/16 3:23 PM: -- Also faced this issue (observed as some transitive dependencies of "provided" dependencies were included into final jar). Confirm it's fixed in 3.4.0-SNAPSHOT. was (Author: sergeant): Also faced this issue (observed as some transitive dependencies of "provided" dependencies were included into final archetype). Confirm it's fixed in 3.4.0-SNAPSHOT. > Optional true getting lost in managed dependencies when transitive > -- > > Key: MNG-5935 > URL: https://issues.apache.org/jira/browse/MNG-5935 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\Temp\apache-maven-3.3.9 > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\Prog\Java\v8_66\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Marcel Schutte >Assignee: Christian Schulte > Fix For: 3.4.0 > > Attachments: Parent.zip, buildoutput.txt > > > Run 'mvn package' on the project in the attached Parent.zip. Note that the > dependency Jar2 gets packaged in WEB-INF/lib and the other dependencies (Jar, > Jar1 and Jar3) do not. > I think the inclusion of Jar2 is incorrect, because project 'Web' declares > its dependency on 'Jar' to be optional and Jar2 being a transitive dependency > of Jar should inherit this. > If you look at the other Jarx dependencies, they have different combinations > of ways to become optional and have their versions managed. Only the case > when optionality is inherited and the dependency management for the version > is in another pom, yields incorrect results. > Please note that I believe the maven-war-plugin is not the cause of this > behavior. I have built and used a modified version of maven-war-plugin which > as the first thing in its WarMojo.execute() lists the result of > getProject().getArtifacts() including the value of each Artifact's > isOptional() method. Already at this point only Jar2 has optional false. > I am using maven-war-plugin in this bug report for the following reasons: > * maven-war-plugin uses the optional flag of dependencies in deciding whether > to package it or not, making this behavior visible > * I don't know of another way to visualize the value of the optional flag in > core maven (running with -X outputs the dependency tree in a section with > header 'Dependency collection stats', but this only shows the scope value) > * maven-dependency-plugin:resolve also only shows scope and not optionality > * obviously, maven-war-plugin is exactly what I intend to use and where I > found the bug -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (MNG-5935) Optional true getting lost in managed dependencies when transitive
[ https://issues.apache.org/jira/browse/MNG-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Tryuber updated MNG-5935: Comment: was deleted (was: Also faced this issue (observed as some transitive dependencies of "provided" dependencies were included into final jar). Confirm it's fixed in 3.4.0-SNAPSHOT.) > Optional true getting lost in managed dependencies when transitive > -- > > Key: MNG-5935 > URL: https://issues.apache.org/jira/browse/MNG-5935 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.3.9 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00) > Maven home: C:\Temp\apache-maven-3.3.9 > Java version: 1.8.0_66, vendor: Oracle Corporation > Java home: C:\Prog\Java\v8_66\jre > Default locale: nl_NL, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Marcel Schutte >Assignee: Christian Schulte > Fix For: 3.4.0 > > Attachments: Parent.zip, buildoutput.txt > > > Run 'mvn package' on the project in the attached Parent.zip. Note that the > dependency Jar2 gets packaged in WEB-INF/lib and the other dependencies (Jar, > Jar1 and Jar3) do not. > I think the inclusion of Jar2 is incorrect, because project 'Web' declares > its dependency on 'Jar' to be optional and Jar2 being a transitive dependency > of Jar should inherit this. > If you look at the other Jarx dependencies, they have different combinations > of ways to become optional and have their versions managed. Only the case > when optionality is inherited and the dependency management for the version > is in another pom, yields incorrect results. > Please note that I believe the maven-war-plugin is not the cause of this > behavior. I have built and used a modified version of maven-war-plugin which > as the first thing in its WarMojo.execute() lists the result of > getProject().getArtifacts() including the value of each Artifact's > isOptional() method. Already at this point only Jar2 has optional false. > I am using maven-war-plugin in this bug report for the following reasons: > * maven-war-plugin uses the optional flag of dependencies in deciding whether > to package it or not, making this behavior visible > * I don't know of another way to visualize the value of the optional flag in > core maven (running with -X outputs the dependency tree in a section with > header 'Dependency collection stats', but this only shows the scope value) > * maven-dependency-plugin:resolve also only shows scope and not optionality > * obviously, maven-war-plugin is exactly what I intend to use and where I > found the bug -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MNG-5978) test libraries should declare expected scope in their pom
Nadav Wexler created MNG-5978: - Summary: test libraries should declare expected scope in their pom Key: MNG-5978 URL: https://issues.apache.org/jira/browse/MNG-5978 Project: Maven Issue Type: Wish Components: Dependencies Reporter: Nadav Wexler when using test libraries and forgetting to include the expected test this could have your jars and wars inflated and could also create some problems in your environment. I suggest to include the expected scope in your pom, and then when depending on that library, checking against the actual pom. if those do not match then a warning should be triggered. also this should be recursive - the check should not emit a warning if the using library is also a test library. I'd love to hear your comments on this Wish! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5978) test libraries should declare expected scope in their pom
[
https://issues.apache.org/jira/browse/MNG-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146655#comment-15146655
]
Karl Heinz Marbaise commented on MNG-5978:
--
Sure it will be part of your application if you omit the
{{test}}..but what i don't understand: Who should check against
which library? And what do you mean by recursive ? test-scope is not transitive
? May be you can give concrete project example (on github / bitbucket) to have
a better imagination what you like to suggest ?
> test libraries should declare expected scope in their pom
> -
>
> Key: MNG-5978
> URL: https://issues.apache.org/jira/browse/MNG-5978
> Project: Maven
> Issue Type: Wish
> Components: Dependencies
>Reporter: Nadav Wexler
>
> when using test libraries and forgetting to include the expected
> test this could have your jars and wars inflated and could
> also create some problems in your environment.
> I suggest to include the expected scope in your pom, and then when depending
> on that library, checking against the actual pom.
> if those do not match then a warning should be triggered.
> also this should be recursive - the check should not emit a warning if the
> using library is also a test library.
> I'd love to hear your comments on this Wish!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5978) test libraries should declare expected scope in their pom
[ https://issues.apache.org/jira/browse/MNG-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146767#comment-15146767 ] Michael Osipov commented on MNG-5978: - The request is unclear to me too. > test libraries should declare expected scope in their pom > - > > Key: MNG-5978 > URL: https://issues.apache.org/jira/browse/MNG-5978 > Project: Maven > Issue Type: Wish > Components: Dependencies >Reporter: Nadav Wexler > > when using test libraries and forgetting to include the expected > test this could have your jars and wars inflated and could > also create some problems in your environment. > I suggest to include the expected scope in your pom, and then when depending > on that library, checking against the actual pom. > if those do not match then a warning should be triggered. > also this should be recursive - the check should not emit a warning if the > using library is also a test library. > I'd love to hear your comments on this Wish! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MSITE-755) Upgrade Doxia Sitetools from 1.6 to 1.7
[ https://issues.apache.org/jira/browse/MSITE-755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146794#comment-15146794 ] Hudson commented on MSITE-755: -- SUCCESS: Integrated in maven-plugins #5106 (See [https://builds.apache.org/job/maven-plugins/5106/]) [MSITE-755] Upgraded Doxia Sitetools from 1.6 to 1.7 (hboutemy: [http://svn.apache.org/viewvc/?view=rev&rev=1730434]) * maven-site-plugin/pom.xml > Upgrade Doxia Sitetools from 1.6 to 1.7 > --- > > Key: MSITE-755 > URL: https://issues.apache.org/jira/browse/MSITE-755 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.4 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5 > > > Release Notes - Maven Doxia Sitetools - Version 1.7 > Bug > * [DOXIASITETOOLS-93] - request-scoped default Velocity Tools are not > accessible > * [DOXIASITETOOLS-107] - Fix link to plexus page in the > doxia-site-renderer web page > * [DOXIASITETOOLS-130] - Doxia document not rendered if "." in > filename > * [DOXIASITETOOLS-145] - when called from Maven 3, > SiteTool.getParentProject() should just return project.getParent() > Improvement > * [DOXIASITETOOLS-82] - Decoration model body/footer type mismatch > * [DOXIASITETOOLS-94] - add plexus container to Velocity context > * [DOXIASITETOOLS-99] - Add typed context variable for creationDate > * [DOXIASITETOOLS-100] - Deprecate all context properties which are > duplicate or already available through Velocity tools > * [DOXIASITETOOLS-102] - Allow multiple extensions for given format > * [DOXIASITETOOLS-103] - Don't create outputFile in case of an external > report > * [DOXIASITETOOLS-105] - add Markdown to dependencies > * [DOXIASITETOOLS-118] - Separate inheritance and interpolation > * [DOXIASITETOOLS-120] - Print artifactId only in modules menu when > module has no name > * [DOXIASITETOOLS-122] - improve API regarding locales > * [DOXIASITETOOLS-126] - don't copy resources when rendering documents > but copy all resources in 1 call > * [DOXIASITETOOLS-132] - do not override existing content with template > when copyResources() > * [DOXIASITETOOLS-136] - improve "Could not parse date: ..., ignoring!" > message with document reference > * [DOXIASITETOOLS-147] - link breadcrumbs to index.html instead of > directory (like menus) > * [DOXIASITETOOLS-155] - Change type of decoration model's body/head > element to string > New Feature > * [DOXIASITETOOLS-133] - for Velocity processed Doxia files > (*.extension.vm), add an option to dump generated markup (= *.extension) > * [DOXIASITETOOLS-149] - Create a skin descriptor to contain metadata > about the skin > * [DOXIASITETOOLS-150] - create a "isLink(href)" function for use in skins > * [DOXIASITETOOLS-154] - Add encoding to skin descriptor to define the > encoding of site.vm > Task > * [DOXIASITETOOLS-98] - Decoration model's Modello doc point to a > statically versioned schema file > * [DOXIASITETOOLS-115] - move doxia-integration-tools from Doxia Tools to > Doxia Sitetools > * [DOXIASITETOOLS-123] - remove long deprecated SiteTool API > * [DOXIASITETOOLS-125] - getDecorationModel() change siteDirectory from > String to File > * [DOXIASITETOOLS-131] - don't add Template-specific variables in general > document Velocity context > * [DOXIASITETOOLS-134] - Remove special handling of date format in > DefaultSiteRenderer > * [DOXIASITETOOLS-135] - Make input source file encoding default to > platform encoding > * [DOXIASITETOOLS-137] - add documentation on how site is rendered, > merging documents and decoration > * [DOXIASITETOOLS-138] - remove skinFile parameter from > createContextForTemplate > * [DOXIASITETOOLS-151] - Upgrade default skin to Default Skin 1.1 > * [DOXIASITETOOLS-153] - Deprecate direct template usage in favor of skin > only > Wish > * [DOXIASITETOOLS-92] - Upgrade Velocity from 1.5 to 1.7 > * [DOXIASITETOOLS-124] - streamline SiteTools API: hide methods that are > only used internally > * [DOXIASITETOOLS-139] - don't render Apache license from default template > * [DOXIASITETOOLS-146] - don't translate APT source comments into output > comments -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSITE-755) Upgrade Doxia Sitetools from 1.6 to 1.7
[ https://issues.apache.org/jira/browse/MSITE-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MSITE-755. --- Resolution: Fixed > Upgrade Doxia Sitetools from 1.6 to 1.7 > --- > > Key: MSITE-755 > URL: https://issues.apache.org/jira/browse/MSITE-755 > Project: Maven Site Plugin > Issue Type: Improvement > Components: doxia integration >Affects Versions: 3.4 >Reporter: Hervé Boutemy >Assignee: Hervé Boutemy > Fix For: 3.5 > > > Release Notes - Maven Doxia Sitetools - Version 1.7 > Bug > * [DOXIASITETOOLS-93] - request-scoped default Velocity Tools are not > accessible > * [DOXIASITETOOLS-107] - Fix link to plexus page in the > doxia-site-renderer web page > * [DOXIASITETOOLS-130] - Doxia document not rendered if "." in > filename > * [DOXIASITETOOLS-145] - when called from Maven 3, > SiteTool.getParentProject() should just return project.getParent() > Improvement > * [DOXIASITETOOLS-82] - Decoration model body/footer type mismatch > * [DOXIASITETOOLS-94] - add plexus container to Velocity context > * [DOXIASITETOOLS-99] - Add typed context variable for creationDate > * [DOXIASITETOOLS-100] - Deprecate all context properties which are > duplicate or already available through Velocity tools > * [DOXIASITETOOLS-102] - Allow multiple extensions for given format > * [DOXIASITETOOLS-103] - Don't create outputFile in case of an external > report > * [DOXIASITETOOLS-105] - add Markdown to dependencies > * [DOXIASITETOOLS-118] - Separate inheritance and interpolation > * [DOXIASITETOOLS-120] - Print artifactId only in modules menu when > module has no name > * [DOXIASITETOOLS-122] - improve API regarding locales > * [DOXIASITETOOLS-126] - don't copy resources when rendering documents > but copy all resources in 1 call > * [DOXIASITETOOLS-132] - do not override existing content with template > when copyResources() > * [DOXIASITETOOLS-136] - improve "Could not parse date: ..., ignoring!" > message with document reference > * [DOXIASITETOOLS-147] - link breadcrumbs to index.html instead of > directory (like menus) > * [DOXIASITETOOLS-155] - Change type of decoration model's body/head > element to string > New Feature > * [DOXIASITETOOLS-133] - for Velocity processed Doxia files > (*.extension.vm), add an option to dump generated markup (= *.extension) > * [DOXIASITETOOLS-149] - Create a skin descriptor to contain metadata > about the skin > * [DOXIASITETOOLS-150] - create a "isLink(href)" function for use in skins > * [DOXIASITETOOLS-154] - Add encoding to skin descriptor to define the > encoding of site.vm > Task > * [DOXIASITETOOLS-98] - Decoration model's Modello doc point to a > statically versioned schema file > * [DOXIASITETOOLS-115] - move doxia-integration-tools from Doxia Tools to > Doxia Sitetools > * [DOXIASITETOOLS-123] - remove long deprecated SiteTool API > * [DOXIASITETOOLS-125] - getDecorationModel() change siteDirectory from > String to File > * [DOXIASITETOOLS-131] - don't add Template-specific variables in general > document Velocity context > * [DOXIASITETOOLS-134] - Remove special handling of date format in > DefaultSiteRenderer > * [DOXIASITETOOLS-135] - Make input source file encoding default to > platform encoding > * [DOXIASITETOOLS-137] - add documentation on how site is rendered, > merging documents and decoration > * [DOXIASITETOOLS-138] - remove skinFile parameter from > createContextForTemplate > * [DOXIASITETOOLS-151] - Upgrade default skin to Default Skin 1.1 > * [DOXIASITETOOLS-153] - Deprecate direct template usage in favor of skin > only > Wish > * [DOXIASITETOOLS-92] - Upgrade Velocity from 1.5 to 1.7 > * [DOXIASITETOOLS-124] - streamline SiteTools API: hide methods that are > only used internally > * [DOXIASITETOOLS-139] - don't render Apache license from default template > * [DOXIASITETOOLS-146] - don't translate APT source comments into output > comments -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (MSITE-759) Update "Configuring the Site Descriptor" page for Doxia (Sitetools) 1.7
[ https://issues.apache.org/jira/browse/MSITE-759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy closed MSITE-759. --- Resolution: Fixed Assignee: Hervé Boutemy (was: Michael Osipov) > Update "Configuring the Site Descriptor" page for Doxia (Sitetools) 1.7 > --- > > Key: MSITE-759 > URL: https://issues.apache.org/jira/browse/MSITE-759 > Project: Maven Site Plugin > Issue Type: Task > Components: documentation >Affects Versions: 3.5 >Reporter: Michael Osipov >Assignee: Hervé Boutemy > Fix For: 3.5 > > > Reflect changes of Doxia (Sitetools) 1.7 when we upgrade. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MNG-5977) Improve output readability of our MavenTransferListener implementations
[
https://issues.apache.org/jira/browse/MNG-5977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146807#comment-15146807
]
Hervé Boutemy commented on MNG-5977:
can you give some concrete examples of the issue and the proposed solution
output, please?
> Improve output readability of our MavenTransferListener implementations
> ---
>
> Key: MNG-5977
> URL: https://issues.apache.org/jira/browse/MNG-5977
> Project: Maven
> Issue Type: Improvement
> Components: Command Line, Embedding
>Affects Versions: 3.3.9
>Reporter: Michael Osipov
>Assignee: Michael Osipov
> Fix For: 3.4.0
>
>
> The current output of Downloading/Downladed/Uploading/Uploaded transfer
> notification has some flaws:
> 1. It does not scale numbers between 1 and 1000 with appropriate units
> 2. It uses incorrect size and time units
> 3. When Aether downloads in parallel (which applies for non-POM files) the
> progress interleaves and you do not know to which resource a progress belongs.
> Let's use MPIR {{DependenciesRenderer}}'s
> [{{FileDecimalFormat}}|https://github.com/apache/maven-plugins/blob/trunk/maven-project-info-reports-plugin/src/main/java/org/apache/maven/report/projectinfo/dependencies/renderer/DependenciesRenderer.java#L1583]
> for it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MWAR-150) Test for overlay.skip before resolving overlay dependency
[
https://issues.apache.org/jira/browse/MWAR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise closed MWAR-150.
Resolution: Implemented
> Test for overlay.skip before resolving overlay dependency
> -
>
> Key: MWAR-150
> URL: https://issues.apache.org/jira/browse/MWAR-150
> Project: Maven WAR Plugin
> Issue Type: Improvement
> Components: overlay
>Affects Versions: 2.1-alpha-1
>Reporter: Mike Youngstrom
> Attachments: skip-overlay.zip
>
>
> I have a "master" pom that many projects share and inherit common build,
> report, dependency, etc. functionality from. I would like all of my .war
> projects to inherit from this "master" pom including my overlays and my
> projects that use the overlay.
> In my master pom I have:
> {code:xml}
>
>
>
>
> org.apache.maven.plugins
>
> maven-war-plugin
> 2.1-alpha-1
>
>
>
>
> com.mycompany.app
>
> my-overlay
>
>
>
>
>
>
>
> {code}
> This obviously causes a problem when the overlay war is created because it
> cannot overlay itself with itself. So I get the error:
> {noformat}
> "overlay[ id com.mycompany.app:my-overlay] is not a dependency of the
> project."
> {noformat}
> I tried overriding the war plugin in the overlay pom and removed the overlays
> but there seemed to be some kind of inheritance thing going on where the
> overlays were still being added no matter what I did. (Might be a different
> issue?)
> Anyway, another way to fix this issue might be to use the "skip" attribute???
> But I get the same error using {{true}}. Would it be possible
> to allow the "skip" attribute to be tested prior to overlay dependency
> checking? I've provided an example project of how I would like skip to
> function in a clean way that might help this problem of circular overlays.
> Mike
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MWAR-360) Overlay: ignore WAR which is transitively dependent over JAR
[
https://issues.apache.org/jira/browse/MWAR-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147024#comment-15147024
]
Karl Heinz Marbaise commented on MWAR-360:
--
The simplest solution is to use the correctly created {{-classes}} artifact
instead of the {{war}} artifact. May be you can show an example projects which
shows the current state...
> Overlay: ignore WAR which is transitively dependent over JAR
>
>
> Key: MWAR-360
> URL: https://issues.apache.org/jira/browse/MWAR-360
> Project: Maven WAR Plugin
> Issue Type: Improvement
>Reporter: Michal Domagala
>Priority: Minor
>
> Example:
> I have WAR project 'Base' with class A.
> I have WAR project 'Level1' which is depends on 'Base'. 'Level1' has class B
> extends A.
> Then 'Base' must have true
> Finally, I have WAR project 'Level2' with class C extends B. For the same
> reason 'Level1' must have true
> Expected: when Level2 WAR is build, only Level1 WAR is overlayed, because
> Level1 contains Base
> Actual: Level1 and Base are overlayed together. That wastes time.
> {noformat}
> [INFO] Copying webapp resources [mwar/Level2/src/main/webapp]
> [INFO] Processing overlay [ id mwar:Level1]
> [INFO] Processing overlay [ id Base:Base]
> [INFO] Webapp assembled in [26 msecs]
> {noformat}
> Reason: Level1 classes JAR has dependency to Base WAR, but that dependency is
> "fake"
> {noformat}
> [INFO] mwar:Level2:war:0.0.1-SNAPSHOT
> [INFO] +- mwar:Level1:war:0.0.1-SNAPSHOT:compile
> [INFO] \- mwar:Level1:jar:classes:0.0.1-SNAPSHOT:compile
> [INFO]+- Base:Base:war:0.0.1-SNAPSHOT:compile
> [INFO]\- Base:Base:jar:classes:0.0.1-SNAPSHOT:compile
> {noformat}
> Proposed solution: There should be option 'notOverlayTransitiveWar' which
> allow exclude WARs like 'Base' from overlaying, because the transitive WAR
> may be reached only over JAR and I think there is no reason any JAR really
> depends on WAR.
> Workaround is manually define ovelays in plugin configuration, but Maven
> spirit is Convention over Configuration
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (MWAR-359) Need to include only specific jars like in war plugin. We need one more tag like including specific jars.
[ https://issues.apache.org/jira/browse/MWAR-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MWAR-359. Resolution: Incomplete Fix Version/s: (was: waiting-for-feedback) Í > Need to include only specific jars like in war plugin. We > need one more tag like including specific jars. > - > > Key: MWAR-359 > URL: https://issues.apache.org/jira/browse/MWAR-359 > Project: Maven WAR Plugin > Issue Type: New Feature >Affects Versions: 2.4 > Environment: Windows, JAVA >Reporter: Naresh > > Need to include only specific jars like in war plugin. We > need one more tag like including specific jars. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MWAR-359) Need to include only specific jars like in war plugin. We need one more tag like including specific jars.
[ https://issues.apache.org/jira/browse/MWAR-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147026#comment-15147026 ] Karl Heinz Marbaise edited comment on MWAR-359 at 2/15/16 7:48 AM: --- Unfortunately no feedback. So closing the issue. if you have further information about the issue don't hesitate to reopen the issue. was (Author: khmarbaise): Í > Need to include only specific jars like in war plugin. We > need one more tag like including specific jars. > - > > Key: MWAR-359 > URL: https://issues.apache.org/jira/browse/MWAR-359 > Project: Maven WAR Plugin > Issue Type: New Feature >Affects Versions: 2.4 > Environment: Windows, JAVA >Reporter: Naresh > > Need to include only specific jars like in war plugin. We > need one more tag like including specific jars. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MWAR-366) Change package to org.apache.maven.plugins to prevent conflict with Maven Core
Karl Heinz Marbaise created MWAR-366: Summary: Change package to org.apache.maven.plugins to prevent conflict with Maven Core Key: MWAR-366 URL: https://issues.apache.org/jira/browse/MWAR-366 Project: Maven WAR Plugin Issue Type: Improvement Affects Versions: 3.0.0 Reporter: Karl Heinz Marbaise Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MWAR-356) "archiveClasses" and "attachClasses" should archive/attach classes only
[ https://issues.apache.org/jira/browse/MWAR-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MWAR-356: - Fix Version/s: waiting-for-feedback > "archiveClasses" and "attachClasses" should archive/attach classes only > --- > > Key: MWAR-356 > URL: https://issues.apache.org/jira/browse/MWAR-356 > Project: Maven WAR Plugin > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Alberto Mozzone > Fix For: waiting-for-feedback > > > As their name implies, "archiveClasses" and "attachClasses" should avoid to > put in the resulting jar the files under "src/main/resources" because: > # they're not classes > # they should be left in "WEB-INF/classes" > # they could be environment dependent: via filtering, the resources in the > deployed artifact could contain information which simply do not make sense in > the repository (or, worse, could contain sensitive information) > Of course, to preserve backward compatibility, I just suggest 2 alternatives: > # a brand new element which joins the behavior of "archiveClasses" and > "attachClasses" (e. g. "packageClasses/deployClasses") and a sibling element > "packageResources" which puts the resources in a jar file in "WEB-INF/lib", > but not in the repo > # a new option used by the two elements which activates the new behavior. > I'm assuming that the properties in subject should behave the same to avoid > differences in artifact naming or content; see also > [MWAR-215|https://issues.apache.org/jira/browse/MWAR-215]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MWAR-356) "archiveClasses" and "attachClasses" should archive/attach classes only
[ https://issues.apache.org/jira/browse/MWAR-356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15147029#comment-15147029 ] Karl Heinz Marbaise commented on MWAR-356: -- Can you show a project example which shows the wrong behaviour, cause currently i can't reproduce this... > "archiveClasses" and "attachClasses" should archive/attach classes only > --- > > Key: MWAR-356 > URL: https://issues.apache.org/jira/browse/MWAR-356 > Project: Maven WAR Plugin > Issue Type: Improvement >Affects Versions: 2.6 >Reporter: Alberto Mozzone > Fix For: waiting-for-feedback > > > As their name implies, "archiveClasses" and "attachClasses" should avoid to > put in the resulting jar the files under "src/main/resources" because: > # they're not classes > # they should be left in "WEB-INF/classes" > # they could be environment dependent: via filtering, the resources in the > deployed artifact could contain information which simply do not make sense in > the repository (or, worse, could contain sensitive information) > Of course, to preserve backward compatibility, I just suggest 2 alternatives: > # a brand new element which joins the behavior of "archiveClasses" and > "attachClasses" (e. g. "packageClasses/deployClasses") and a sibling element > "packageResources" which puts the resources in a jar file in "WEB-INF/lib", > but not in the repo > # a new option used by the two elements which activates the new behavior. > I'm assuming that the properties in subject should behave the same to avoid > differences in artifact naming or content; see also > [MWAR-215|https://issues.apache.org/jira/browse/MWAR-215]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
