[jira] [Commented] (MPDF-81) Override the copyright footer
[
https://issues.apache.org/jira/browse/MPDF-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160752#comment-16160752
]
Hervé Boutemy commented on MPDF-81:
---
regarding "Chekstyle findings" on Doxia Sink API, no, don't change: it's a case
with something like a fluent API, that does not use traditional Java classical
naming rules
And if you look at Doxia parent pom, you'll find
{code:xml}RedundantThrows,NewlineAtEndOfFile,ParameterNumber,MethodLength,FileLength,MethodName,InnerAssignment,MagicNumber{code}
that disables MethodName checks: isn't it detected by your IDE tooling?
> Override the copyright footer
> -
>
> Key: MPDF-81
> URL: https://issues.apache.org/jira/browse/MPDF-81
> Project: Maven PDF Plugin
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Alex O'Ree
>
> As of right now, it doesn't look possible to override the content of the
> footer which is on all non-title page pages. It currently reads (c) year -
> organization All rights reserved.
> I don't see anywhere in the code where this is defined or in any of the
> resource files. It is in the generated fo files but it's not obvious where
> the xslt is.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SUREFIRE-1414) Configuration still considered "same" after Proguard has rewritten the jar
Chris Hennick created SUREFIRE-1414:
---
Summary: Configuration still considered "same" after Proguard has
rewritten the jar
Key: SUREFIRE-1414
URL: https://issues.apache.org/jira/browse/SUREFIRE-1414
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.14.1
Environment: Ubuntu 14.04.3
Reporter: Chris Hennick
I run my unit tests for a library twice: once to generate a coverage report,
then again after running Proguard to verify the Proguard settings. When I try
to do the latter after the former in the same script, I get "Skipping execution
of surefire because it has already been run for this configuration". This could
be fixed by including checksums of the jar's class files in the identity
checksum of the configuration.
My combined test script, including a workaround, is:
{code:bash}
#!/bin/sh
cd betterrandom
# Coverage test
mvn clean install jacoco:prepare-agent test jacoco:report -e
STATUS=$?
if [ "$STATUS" = 0 ]; then
if [ "$TRAVIS" = "true" ]; then
mvn coveralls:report
fi
rm .surefire-* # Avoid false detection of redundancy
# Post-Proguard test (verifies Proguard settings)
mvn package proguard:proguard install test
STATUS=$?
fi
cd ..
exit "$STATUS"
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1396) Provider class path is incorrect for custom provider in Failsafe
[ https://issues.apache.org/jira/browse/SUREFIRE-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160554#comment-16160554 ] Hudson commented on SUREFIRE-1396: -- SUCCESS: Integrated in Jenkins build maven-surefire #1757 (See [https://builds.apache.org/job/maven-surefire/1757/]) [SUREFIRE-1396] Provider class path is incorrect for custom provider in (jon: [http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=99cd4f65f5f04ed8c98f446850f5f8bd7b98fc64]) * (edit) maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java * (add) surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1396CustomProviderClassPathIT.java * (add) surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath-provider/pom.xml * (add) surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath-provider/src/main/java/org/apache/maven/surefire/testprovider/ClassPathTestProvider.java * (add) surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath-provider/src/main/resources/META-INF/services/org.apache.maven.surefire.providerapi.SurefireProvider * (add) surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath/pom.xml * (add) surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath/src/test/java/pluggableproviders/EmptyTest.java * (edit) maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java * (edit) maven-surefire-plugin/src/main/java/org/apache/maven/plugin/surefire/SurefirePlugin.java * (add) surefire-integration-tests/src/test/resources/surefire-1396-pluggableproviders-classpath/src/test/java/pluggableproviders/EmptyIT.java > Provider class path is incorrect for custom provider in Failsafe > > > Key: SUREFIRE-1396 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1396 > Project: Maven Surefire > Issue Type: Bug >Reporter: Jonathan Bell >Assignee: Tibor Digana > Fix For: 2.20.1 > > > Hi, > When using a custom Surefire provider with Surefire (not Failsafe), the > "provider classpath" contains only the provider and surefire-api. However, > when using a custom provider with Failsafe, the provider class path ends up > including a lot more... it seems like perhaps all plugins that are loaded? > This has caused some mayhem for me when using a custom provider in projects > that use a specific version of SLF4J... because then failsafe forces 1.5.6 to > be loaded (from this process of incorrectly finding the custom provider), > causing a crash. > It is a simple fix (3 lines in AbstractSurefireMojo - it had the name of the > Surefire plugin hardcoded, which isn't correct when it's actually Failsafe). > I've got a patched fork of master on GitHub > (https://github.com/jon-bell/maven-surefire/commit/04f66cdd828d131a028eb400d1ed26fe104fe3f2) > that fixes it and an integration test that demonstrates the flaw. I am not > 100% sure on the formatting of the integration test (i.e., I am opening a > JIRA ticket so that I suppose I can name it under the JIRA issue? How should > I specify the current version of surefire in the integration test package?) - > if the fix is welcome against master I'd be happy to open a PR on GitHub. I > am also happy to merge against a different branch if it's more helpful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1412) Findbugs plugin fails - Update maven-parent to Version 30 and downgrade maven-site-plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160559#comment-16160559 ] Hudson commented on SUREFIRE-1412: -- SUCCESS: Integrated in Jenkins build maven-surefire #1757 (See [https://builds.apache.org/job/maven-surefire/1757/]) [SUREFIRE-1412] Findbugs plugin fails - Update maven-parent to Version (tibor17: [http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=b8eb673627e5d73d0e3d0dfdd639f257e10536ea]) * (edit) pom.xml > Findbugs plugin fails - Update maven-parent to Version 30 and downgrade > maven-site-plugin > - > > Key: SUREFIRE-1412 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1412 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.20 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.20.1 > > > The solution is to Update :maven-parent:26 to Version 30. > Consequently after the update Fluido 1.3.0 fails [1] and the solution is to > downgrage maven-site-plugin:3.5.1 to 3.4. > [1]: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project > surefire: Velocity parsing error while reading the site decoration template > from org.apache.maven.skins:maven-fluido-skin:jar:1.4 skin: Encountered > "source" at META-INF/maven/site.vm[line 1162, column 52] > [ERROR] Was expecting one of: > [ERROR] "," ... > [ERROR] ")" ... > [ERROR] ... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1403) [Jigsaw] [Java 9] add "--add-modules java.se.ee" to forked CLI argument
[
https://issues.apache.org/jira/browse/SUREFIRE-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160553#comment-16160553
]
Hudson commented on SUREFIRE-1403:
--
SUCCESS: Integrated in Jenkins build maven-surefire #1757 (See
[https://builds.apache.org/job/maven-surefire/1757/])
[Agreed with Oracle] [SUREFIRE-1403] [Jigsaw] [Java 9] add (tibor17:
[http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=0635d25e9d273c48196c1c9cb40eefc38393daba])
* (edit)
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkConfiguration.java
[Agreed with Oracle] [SUREFIRE-1403] [DOC] [Jigsaw] [Java 9] add (tibor17:
[http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=100f696029a53d57dbacd0f3962f3c305891588c])
* (edit) maven-surefire-plugin/src/site/markdown/java9.md
> [Jigsaw] [Java 9] add "--add-modules java.se.ee" to forked CLI argument
> ---
>
> Key: SUREFIRE-1403
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1403
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: surefire-1403.zip
>
>
> Calling *findClass( cls, "java.se.ee")* in *IsolatedClassLoader* does not
> help and does not do anything because the module is ignored in Java 9.
> In-plugin provider does not have any problem to load classes from entire JDK.
> Forked JVM would work only after added
> {{--add-modules java.se.ee}}
> The fix would be to add "--add-modules java.se.ee" if {{--add-modules}} is
> not specified by user at Java 9+.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1413) Javadoc - unknown TAG @noinspection
[
https://issues.apache.org/jira/browse/SUREFIRE-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160560#comment-16160560
]
Hudson commented on SUREFIRE-1413:
--
SUCCESS: Integrated in Jenkins build maven-surefire #1757 (See
[https://builds.apache.org/job/maven-surefire/1757/])
[SUREFIRE-1413] Javadoc - unknown TAG @noinspection (tibor17:
[http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=c8e42d05c8fb0a5b3ac8b14d33cac7ac196bbd60])
* (edit)
maven-surefire-report-plugin/src/main/java/org/apache/maven/plugins/surefire/report/SurefireReportMojo.java
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/booter/TestRequestAware.java
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/booter/ProviderPropertiesAware.java
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/booter/SurefireReflector.java
* (edit)
maven-surefire-report-plugin/src/main/java/org/apache/maven/plugins/surefire/report/FailsafeReportMojo.java
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/booter/ReporterConfigurationAware.java
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/booter/DirectoryScannerParametersAware.java
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/booter/TestArtifactInfoAware.java
* (edit) surefire-booter/src/test/java/org/apache/maven/surefire/booter/Foo.java
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/booter/SurefireClassLoadersAware.java
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/booter/RunOrderParametersAware.java
* (edit)
surefire-providers/common-junit3/src/test/java/org/apache/maven/surefire/common/junit3/JUnit3TestCheckerTest.java
* (edit)
maven-surefire-report-plugin/src/main/java/org/apache/maven/plugins/surefire/report/AbstractSurefireReportMojo.java
* (edit)
maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/VerifyMojo.java
> Javadoc - unknown TAG @noinspection
> ---
>
> Key: SUREFIRE-1413
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1413
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Labels: javadoc
> Fix For: 2.20.1
>
>
> After updated {{maven-parent}} Version to 30 this issue became a blocker to
> release {{2.20.1}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1264) Some tests can be lost when running in parallel with parameterized tests
[
https://issues.apache.org/jira/browse/SUREFIRE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160555#comment-16160555
]
Hudson commented on SUREFIRE-1264:
--
SUCCESS: Integrated in Jenkins build maven-surefire #1757 (See
[https://builds.apache.org/job/maven-surefire/1757/])
[SUREFIRE-1264] Some tests can be lost when running in parallel with (tibor17:
[http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=c8724dd2f992625c355e4817a6b7995d3e88fdb4])
* (add)
surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire1264IT.java
* (edit)
surefire-providers/common-junit4/src/main/java/org/apache/maven/surefire/junit4/MockReporter.java
* (edit)
surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreRunListener.java
* (add)
surefire-integration-tests/src/test/resources/surefire-1264/src/test/java/com/appnexus/viewability/core/surefireJunitTests/ATest.java
* (edit)
surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/TestSet.java
* (edit)
surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/ConcurrentRunListener.java
* (add) surefire-integration-tests/src/test/resources/surefire-1264/pom.xml
* (add)
surefire-integration-tests/src/test/resources/surefire-1264/src/test/java/com/appnexus/viewability/core/surefireJunitTests/CTest.java
* (add)
surefire-integration-tests/src/test/resources/surefire-1264/src/test/java/com/appnexus/viewability/core/surefireJunitTests/DTest.java
* (add)
surefire-integration-tests/src/test/resources/surefire-1264/src/test/java/com/appnexus/viewability/core/surefireJunitTests/BaseTest.java
* (add)
surefire-integration-tests/src/test/resources/surefire-1264/src/test/java/com/appnexus/viewability/core/surefireJunitTests/BTest.java
* (edit)
surefire-providers/surefire-junit47/src/test/java/org/apache/maven/surefire/junitcore/JUnitCoreRunListenerTest.java
* (edit)
surefire-api/src/main/java/org/apache/maven/surefire/util/internal/TestClassMethodNameUtils.java
* (add)
surefire-integration-tests/src/test/resources/surefire-621-testCounting-junit3-in-parallel/src/it/java/mho/JUnit4AdapterSuiteTest.java
* (edit)
surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/jiras/Surefire621TestCountingJunit3InParallelIT.java
* (edit)
surefire-providers/surefire-junit47/src/test/java/org/apache/maven/surefire/junitcore/TestMethodTest.java
* (edit)
surefire-providers/common-junit4/src/main/java/org/apache/maven/surefire/common/junit4/JUnit4RunListener.java
* (edit)
surefire-integration-tests/src/test/resources/surefire-621-testCounting-junit3-in-parallel/pom.xml
> Some tests can be lost when running in parallel with parameterized tests
>
>
> Key: SUREFIRE-1264
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1264
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.19.1
> Environment: Maven 3.3.9
> Java 1.8.0_45 (Oracle)
> System: OS X
> Reproduced on Linux too, with both OpenJDK 7 and Java 7 from Oracle.
>Reporter: Jean-Luc Derrien
>Assignee: Tibor Digana
> Fix For: 2.20.1
>
> Attachments: failure-2.21-snapshot-SUREFIRE-1264.zip, pom.xml
>
> Time Spent: 144h
> Remaining Estimate: 24h
>
> Hello,
> It appears some tests can be lost when using the parallel mode with
> parameterized tests. Here is a [small
> project|https://github.com/jderrien/surefire-junit-tests/tree/simple-1] I've
> used to try to reproduce the issue we have seen.
> This is not something that happens on every run, but it's quite frequent.
> With this loop, the problem should appear in less than 2 minutes, maybe on
> the first run when (un)lucky:
> {code}
> time while true; do mvn clean test > last.log ; tail -25 last.log ; if [
> "$(grep -c 'Tests run: 12' last.log)" == "0" ]; then break; fi ; done
> {code}
> Normal run:
> {noformat}
> ---
> T E S T S
> ---
> Running [p2]
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p2] - p2 -
> sleeptime = 1 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p1] - p1 -
> sleeptime = 2 => stop
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => start
> com.appnexus.viewability.core.surefireJunitTests.ATest.methodA1[p0] - p0 -
> sleeptime = 5 => stop
> Tests run: 6, Failures: 0, Errors: 0, Skipped:
[jira] [Commented] (SUREFIRE-1410) Add FAQ and improve Warning message when native stream in forked JVM is corrupted
[
https://issues.apache.org/jira/browse/SUREFIRE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160557#comment-16160557
]
Hudson commented on SUREFIRE-1410:
--
SUCCESS: Integrated in Jenkins build maven-surefire #1757 (See
[https://builds.apache.org/job/maven-surefire/1757/])
[SUREFIRE-1410] Add FAQ and improve Warning message when native stream
(tibor17:
[http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=ead22a3d399a5fd608ebae90a079644ab786eae8])
* (edit)
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ForkStarter.java
* (edit)
maven-surefire-common/src/test/java/org/apache/maven/plugin/surefire/booterclient/ForkingRunListenerTest.java
* (edit)
maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/output/ForkClient.java
* (edit) maven-surefire-plugin/src/site/fml/faq.fml
> Add FAQ and improve Warning message when native stream in forked JVM is
> corrupted
> -
>
> Key: SUREFIRE-1410
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1410
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Labels: documentation
> Fix For: 2.20.1
>
>
> Related to the discussion with contributors in SUREFIRE-1359.
> The message {{Corrupted stdin stream in forked JVM}} would become more
> specific {{Corrupted STDOUT by directly writing to native stream in forked
> JVM}}.
> Then {{See the dump file}} would be extended to {{See FAQ web page and the
> dump file}}.
> These messages would appear just once in the console and not per fork as it
> was in prior versions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1409) Parallel runner should not drop away runners that have zero children.
[ https://issues.apache.org/jira/browse/SUREFIRE-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160556#comment-16160556 ] Hudson commented on SUREFIRE-1409: -- SUCCESS: Integrated in Jenkins build maven-surefire #1757 (See [https://builds.apache.org/job/maven-surefire/1757/]) [SUREFIRE-1409] Parallel runner should not drop away runners that have (tibor17: [http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=67c06d5876dcabc037de9b5f4cc226beeedcb379]) * (edit) surefire-providers/surefire-junit47/src/test/java/org/apache/maven/surefire/junitcore/pc/ParallelComputerBuilderTest.java * (edit) surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/pc/ParallelComputerBuilder.java > Parallel runner should not drop away runners that have zero children. > - > > Key: SUREFIRE-1409 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1409 > Project: Maven Surefire > Issue Type: Improvement > Components: Junit 4.7+ (parallel) support >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.20.1 > > > JUnit does not force runners to include all child tests in Description. > Therefore Parallel Runner should not throw such tests away. > For example Spock does not report parametrized tests. > [https://github.com/spockframework/spock/pull/558] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (SUREFIRE-1411) Improve calls String.length == 0 to Java 1.6 call String.isEmpty
[ https://issues.apache.org/jira/browse/SUREFIRE-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160558#comment-16160558 ] Hudson commented on SUREFIRE-1411: -- SUCCESS: Integrated in Jenkins build maven-surefire #1757 (See [https://builds.apache.org/job/maven-surefire/1757/]) [SUREFIRE-1411] Improve calls String.length == 0 to Java 1.6 call (tibor17: [http://git-wip-us.apache.org/repos/asf/?p=maven-surefire.git=commit=8a63486f8efc721d0003cb5685e590a98369704a]) * (edit) surefire-api/src/main/java/org/apache/maven/surefire/testset/TestListResolver.java * (edit) surefire-providers/surefire-testng-utils/src/main/java/org/apache/maven/surefire/testng/utils/GroupMatcherMethodSelector.java * (edit) surefire-api/src/main/java/org/apache/maven/surefire/booter/ForkingRunListener.java * (edit) maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/StatelessXmlReporter.java * (edit) maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/util/FileScanner.java * (edit) maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/report/WrappedReportEntry.java * (edit) surefire-api/src/main/java/org/apache/maven/surefire/util/internal/StringUtils.java * (edit) surefire-providers/common-junit48/src/main/java/org/apache/maven/surefire/common/junit48/RequestedTest.java * (edit) surefire-providers/surefire-junit47/src/main/java/org/apache/maven/surefire/junitcore/JUnitCoreWrapper.java * (edit) surefire-integration-tests/src/test/java/org/apache/maven/surefire/its/fixture/SurefireLauncher.java * (edit) maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java * (edit) surefire-booter/src/main/java/org/apache/maven/surefire/booter/Classpath.java * (edit) surefire-grouper/src/main/java/org/apache/maven/surefire/group/match/SingleGroupMatcher.java * (edit) surefire-booter/src/main/java/org/apache/maven/surefire/booter/TypeEncodedValue.java > Improve calls String.length == 0 to Java 1.6 call String.isEmpty > > > Key: SUREFIRE-1411 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1411 > Project: Maven Surefire > Issue Type: Improvement >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.20.1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MPDF-81) Override the copyright footer
[ https://issues.apache.org/jira/browse/MPDF-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160455#comment-16160455 ] Alex O'Ree edited comment on MPDF-81 at 9/11/17 1:40 AM: - I'll add the modifying the sink api will requirement modifications in a number of different repos and projects and will likely cause compatibility issues was (Author: spyhunter99): I'll add the modifying the sink api while requirement modifications in a number of different repos and projects and will likely cause compatibility issues > Override the copyright footer > - > > Key: MPDF-81 > URL: https://issues.apache.org/jira/browse/MPDF-81 > Project: Maven PDF Plugin > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Alex O'Ree > > As of right now, it doesn't look possible to override the content of the > footer which is on all non-title page pages. It currently reads (c) year - > organization All rights reserved. > I don't see anywhere in the code where this is defined or in any of the > resource files. It is in the generated fo files but it's not obvious where > the xslt is. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MPDF-81) Override the copyright footer
[ https://issues.apache.org/jira/browse/MPDF-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160455#comment-16160455 ] Alex O'Ree edited comment on MPDF-81 at 9/11/17 1:40 AM: - I'll add the modifying the sink api will requirement modifications in a number of different repos and projects and will likely cause compatibility issues (this is referencing the checkstyle findings) was (Author: spyhunter99): I'll add the modifying the sink api will requirement modifications in a number of different repos and projects and will likely cause compatibility issues > Override the copyright footer > - > > Key: MPDF-81 > URL: https://issues.apache.org/jira/browse/MPDF-81 > Project: Maven PDF Plugin > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Alex O'Ree > > As of right now, it doesn't look possible to override the content of the > footer which is on all non-title page pages. It currently reads (c) year - > organization All rights reserved. > I don't see anywhere in the code where this is defined or in any of the > resource files. It is in the generated fo files but it's not obvious where > the xslt is. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (SUREFIRE-1413) Javadoc - unknown TAG @noinspection
[
https://issues.apache.org/jira/browse/SUREFIRE-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed SUREFIRE-1413.
--
Resolution: Fixed
https://git1-us-west.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=c8e42d05c8fb0a5b3ac8b14d33cac7ac196bbd60
> Javadoc - unknown TAG @noinspection
> ---
>
> Key: SUREFIRE-1413
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1413
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Labels: javadoc
> Fix For: 2.20.1
>
>
> After updated {{maven-parent}} Version to 30 this issue became a blocker to
> release {{2.20.1}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (SUREFIRE-1413) Javadoc - unknown TAG @noinspection
[
https://issues.apache.org/jira/browse/SUREFIRE-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated SUREFIRE-1413:
---
Labels: javadoc (was: )
> Javadoc - unknown TAG @noinspection
> ---
>
> Key: SUREFIRE-1413
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1413
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Tibor Digana
>Assignee: Tibor Digana
> Labels: javadoc
> Fix For: 2.20.1
>
>
> After updated {{maven-parent}} Version to 30 this issue became a blocker to
> release {{2.20.1}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (SUREFIRE-1413) Javadoc - unknown TAG @noinspection
Tibor Digana created SUREFIRE-1413:
--
Summary: Javadoc - unknown TAG @noinspection
Key: SUREFIRE-1413
URL: https://issues.apache.org/jira/browse/SUREFIRE-1413
Project: Maven Surefire
Issue Type: Bug
Reporter: Tibor Digana
Assignee: Tibor Digana
Fix For: 2.20.1
After updated {{maven-parent}} Version to 30 this issue became a blocker to
release {{2.20.1}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (SUREFIRE-1412) Findbugs plugin fails - Update maven-parent to Version 30 and downgrade maven-site-plugin
[ https://issues.apache.org/jira/browse/SUREFIRE-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tibor Digana closed SUREFIRE-1412. -- Resolution: Fixed https://git1-us-west.apache.org/repos/asf?p=maven-surefire.git;a=commit;h=b8eb673627e5d73d0e3d0dfdd639f257e10536ea > Findbugs plugin fails - Update maven-parent to Version 30 and downgrade > maven-site-plugin > - > > Key: SUREFIRE-1412 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1412 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.20 >Reporter: Tibor Digana >Assignee: Tibor Digana > Fix For: 2.20.1 > > > The solution is to Update :maven-parent:26 to Version 30. > Consequently after the update Fluido 1.3.0 fails [1] and the solution is to > downgrage maven-site-plugin:3.5.1 to 3.4. > [1]: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project > surefire: Velocity parsing error while reading the site decoration template > from org.apache.maven.skins:maven-fluido-skin:jar:1.4 skin: Encountered > "source" at META-INF/maven/site.vm[line 1162, column 52] > [ERROR] Was expecting one of: > [ERROR] "," ... > [ERROR] ")" ... > [ERROR] ... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (SUREFIRE-1412) Findbugs plugin fails - Update maven-parent to Version 30 and downgrade maven-site-plugin
Tibor Digana created SUREFIRE-1412: -- Summary: Findbugs plugin fails - Update maven-parent to Version 30 and downgrade maven-site-plugin Key: SUREFIRE-1412 URL: https://issues.apache.org/jira/browse/SUREFIRE-1412 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.20 Reporter: Tibor Digana Assignee: Tibor Digana Fix For: 2.20.1 The solution is to Update :maven-parent:26 to Version 30. Consequently after the update Fluido 1.3.0 fails [1] and the solution is to downgrage maven-site-plugin:3.5.1 to 3.4. [1]: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project surefire: Velocity parsing error while reading the site decoration template from org.apache.maven.skins:maven-fluido-skin:jar:1.4 skin: Encountered "source" at META-INF/maven/site.vm[line 1162, column 52] [ERROR] Was expecting one of: [ERROR] "," ... [ERROR] ")" ... [ERROR] ... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MPDF-81) Override the copyright footer
[ https://issues.apache.org/jira/browse/MPDF-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160485#comment-16160485 ] Hervé Boutemy commented on MPDF-81: --- adding some methods does not break too much: in fact, we don't have choice. Let's try and we'll see. I had a look (I don't know the pdf parts): looks like there is a DocumentModel already there to enhance http://maven.apache.org/doxia/doxia/doxia-modules/doxia-module-fo/apidocs/index.html . Looks a good place to add info, since it won't affect every Sink, and is quite natural > Override the copyright footer > - > > Key: MPDF-81 > URL: https://issues.apache.org/jira/browse/MPDF-81 > Project: Maven PDF Plugin > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Alex O'Ree > > As of right now, it doesn't look possible to override the content of the > footer which is on all non-title page pages. It currently reads (c) year - > organization All rights reserved. > I don't see anywhere in the code where this is defined or in any of the > resource files. It is in the generated fo files but it's not obvious where > the xslt is. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MPDF-81) Override the copyright footer
[ https://issues.apache.org/jira/browse/MPDF-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160455#comment-16160455 ] Alex O'Ree commented on MPDF-81: I'll add the modifying the sink api while requirement modifications in a number of different repos and projects and will likely cause compatibility issues > Override the copyright footer > - > > Key: MPDF-81 > URL: https://issues.apache.org/jira/browse/MPDF-81 > Project: Maven PDF Plugin > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Alex O'Ree > > As of right now, it doesn't look possible to override the content of the > footer which is on all non-title page pages. It currently reads (c) year - > organization All rights reserved. > I don't see anywhere in the code where this is defined or in any of the > resource files. It is in the generated fo files but it's not obvious where > the xslt is. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MJAR-138) jar:test-jar is skipped when maven.test.skip=true
[ https://issues.apache.org/jira/browse/MJAR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160395#comment-16160395 ] Robert Scholte commented on MJAR-138: - There are a couple of plugin "listening" to this property: * [compiler:testCompile skip|https://maven.apache.org/plugins/maven-compiler-plugin/testCompile-mojo.html#skip] * [surefire:test skip|https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#skip] * [jar:test-jar skip|https://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html#skip] I don't know the complete history of this property, but I can imagine the following: if you don't want to run tests, no need to compile them nor to package them. It is not such a weird idea to have the property cause this as default behavior, but is it correct? > jar:test-jar is skipped when maven.test.skip=true > - > > Key: MJAR-138 > URL: https://issues.apache.org/jira/browse/MJAR-138 > Project: Maven JAR Plugin > Issue Type: Improvement >Affects Versions: 2.3.1 > Environment: jar:test-jar >Reporter: Andrew Hughes > Fix For: more-investigation > > Attachments: MJAR-138-maven-jar-plugin.patch > > > Not sure if this is a bug or improvement... > Example: > * ./pom.xml > * ./moduleA/pom.xml > * ./moduleB/pom.xml > Situation: > * moduleA produces moduleA-1.2.3-test.jar with the jar:test-jar goal > * moduleB consumes moduleA-1.2.3-test.jar as a > ...test > Problem: > * When -Dmaven.test.skip=true the moduleA-1.2.3-test.jar is never built. > * Then when moduleB tries to build, it's moduleA-1.2.3-test.jar dependency is > unresolved. FAIL! Even with -Dmaven.test.skip=true this will fail. > You might argue that this is a bug with dependency resolution with > -Dmaven.test.skip=true - should a missing dependency @ test scope really fail > the build??? It probably should - which is why the bug is submitted here :) > I've no idea what could be done to fix this either? > --- > p.s. for anyone with this bug the only workaround I can suggest is running > another module... > ./moduleA-test/pom.xml > and have > ...moduleA-test...test -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MJAR-138) jar:test-jar is skipped when maven.test.skip=true
[
https://issues.apache.org/jira/browse/MJAR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160394#comment-16160394
]
Bisser Peshev commented on MJAR-138:
Well, there's a workaround with Maven profiles. The test-jar dependencies will
be declared only if maven.test.skip is not true:
{code:xml}
maven.test.skip
!true
com.acme.project
my-artifact
test-jar
${project.version}
test
{code}
Ugly, but at least works.
> jar:test-jar is skipped when maven.test.skip=true
> -
>
> Key: MJAR-138
> URL: https://issues.apache.org/jira/browse/MJAR-138
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Affects Versions: 2.3.1
> Environment: jar:test-jar
>Reporter: Andrew Hughes
> Fix For: more-investigation
>
> Attachments: MJAR-138-maven-jar-plugin.patch
>
>
> Not sure if this is a bug or improvement...
> Example:
> * ./pom.xml
> * ./moduleA/pom.xml
> * ./moduleB/pom.xml
> Situation:
> * moduleA produces moduleA-1.2.3-test.jar with the jar:test-jar goal
> * moduleB consumes moduleA-1.2.3-test.jar as a
> ...test
> Problem:
> * When -Dmaven.test.skip=true the moduleA-1.2.3-test.jar is never built.
> * Then when moduleB tries to build, it's moduleA-1.2.3-test.jar dependency is
> unresolved. FAIL! Even with -Dmaven.test.skip=true this will fail.
> You might argue that this is a bug with dependency resolution with
> -Dmaven.test.skip=true - should a missing dependency @ test scope really fail
> the build??? It probably should - which is why the bug is submitted here :)
> I've no idea what could be done to fix this either?
> ---
> p.s. for anyone with this bug the only workaround I can suggest is running
> another module...
> ./moduleA-test/pom.xml
> and have
> ...moduleA-test...test
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (MJAR-138) jar:test-jar is skipped when maven.test.skip=true
[
https://issues.apache.org/jira/browse/MJAR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160365#comment-16160365
]
Bisser Peshev edited comment on MJAR-138 at 9/10/17 2:46 PM:
-
Thank you for your response. Unfortunately, after adding the
{color:#14892c}false{color} configuration, an empty test-jar was
produced when maven.test.skip was true. Or rather, it only contained the
manifest file, but no classes. This is not a solution. :(
Yes, it's a maven-jar-plugin problem, because it doesn't create the test-jar.
But Maven itself also takes part in the problem, because it enforces the
dependencies on the test-jar, although they are not needed when maven.test.skip
is true. But then again, probably it's not Maven's responsibility to decide
which dependency is needed and which isn't, neither is it supposed to know
about the maven.test.skip option.
I suppose the simplest solution would be for maven-jar-plugin to stop checking
the value of maven.test.skip and let the surefire plugin worry about that
option. So, maven-jar-plugin will _always_ generate the test-jar.
was (Author: blizzard):
Thank you for your response. Unfortunately, after adding the
{color:#14892c}false{color} configuration, an empty jar was
produced when maven.test.skip was true. Or rather, it only contained the
manifest file, but no classes. This is not a solution. :(
Yes, it's a maven-jar-plugin problem, because it doesn't create the test-jar.
But Maven itself also takes part in the problem, because it enforces the
dependencies on the test-jar, although they are not needed when maven.test.skip
is true. But then again, probably it's not Maven's responsibility to decide
which dependency is needed and which isn't, neither is it supposed to know
about the maven.test.skip option.
I suppose the simplest solution would be for maven-jar-plugin to stop checking
the value of maven.test.skip and let the surefire plugin worry about that
option. So, maven-jar-plugin will _always_ generate the test-jar.
> jar:test-jar is skipped when maven.test.skip=true
> -
>
> Key: MJAR-138
> URL: https://issues.apache.org/jira/browse/MJAR-138
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Affects Versions: 2.3.1
> Environment: jar:test-jar
>Reporter: Andrew Hughes
> Fix For: more-investigation
>
> Attachments: MJAR-138-maven-jar-plugin.patch
>
>
> Not sure if this is a bug or improvement...
> Example:
> * ./pom.xml
> * ./moduleA/pom.xml
> * ./moduleB/pom.xml
> Situation:
> * moduleA produces moduleA-1.2.3-test.jar with the jar:test-jar goal
> * moduleB consumes moduleA-1.2.3-test.jar as a
> ...test
> Problem:
> * When -Dmaven.test.skip=true the moduleA-1.2.3-test.jar is never built.
> * Then when moduleB tries to build, it's moduleA-1.2.3-test.jar dependency is
> unresolved. FAIL! Even with -Dmaven.test.skip=true this will fail.
> You might argue that this is a bug with dependency resolution with
> -Dmaven.test.skip=true - should a missing dependency @ test scope really fail
> the build??? It probably should - which is why the bug is submitted here :)
> I've no idea what could be done to fix this either?
> ---
> p.s. for anyone with this bug the only workaround I can suggest is running
> another module...
> ./moduleA-test/pom.xml
> and have
> ...moduleA-test...test
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAR-138) jar:test-jar is skipped when maven.test.skip=true
[
https://issues.apache.org/jira/browse/MJAR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160365#comment-16160365
]
Bisser Peshev commented on MJAR-138:
Thank you for your response. Unfortunately, after adding the
{color:#14892c}false{color} configuration, an empty jar was
produced when maven.test.skip was true. Or rather, it only contained the
manifest file, but no classes. This is not a solution. :(
Yes, it's a maven-jar-plugin problem, because it doesn't create the test-jar.
But Maven itself also takes part in the problem, because it enforces the
dependencies on the test-jar, although they are not needed when maven.test.skip
is true. But then again, probably it's not Maven's responsibility to decide
which dependency is needed and which isn't, neither is it supposed to know
about the maven.test.skip option.
I suppose the simplest solution would be for maven-jar-plugin to stop checking
the value of maven.test.skip and let the surefire plugin worry about that
option. So, maven-jar-plugin will _always_ generate the test-jar.
> jar:test-jar is skipped when maven.test.skip=true
> -
>
> Key: MJAR-138
> URL: https://issues.apache.org/jira/browse/MJAR-138
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Affects Versions: 2.3.1
> Environment: jar:test-jar
>Reporter: Andrew Hughes
> Fix For: more-investigation
>
> Attachments: MJAR-138-maven-jar-plugin.patch
>
>
> Not sure if this is a bug or improvement...
> Example:
> * ./pom.xml
> * ./moduleA/pom.xml
> * ./moduleB/pom.xml
> Situation:
> * moduleA produces moduleA-1.2.3-test.jar with the jar:test-jar goal
> * moduleB consumes moduleA-1.2.3-test.jar as a
> ...test
> Problem:
> * When -Dmaven.test.skip=true the moduleA-1.2.3-test.jar is never built.
> * Then when moduleB tries to build, it's moduleA-1.2.3-test.jar dependency is
> unresolved. FAIL! Even with -Dmaven.test.skip=true this will fail.
> You might argue that this is a bug with dependency resolution with
> -Dmaven.test.skip=true - should a missing dependency @ test scope really fail
> the build??? It probably should - which is why the bug is submitted here :)
> I've no idea what could be done to fix this either?
> ---
> p.s. for anyone with this bug the only workaround I can suggest is running
> another module...
> ./moduleA-test/pom.xml
> and have
> ...moduleA-test...test
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MJLINK-3) Improve verbose output during build
Karl Heinz Marbaise created MJLINK-3:
Summary: Improve verbose output during build
Key: MJLINK-3
URL: https://issues.apache.org/jira/browse/MJLINK-3
Project: Maven JLink Plugin
Issue Type: Improvement
Affects Versions: 3.0.0-alpha-1
Reporter: Karl Heinz Marbaise
Priority: Minor
Fix For: 3.0.0-alpha-2
Currently the output during a build in relationship with
{{true}} looks like this:
{code}
[INFO]
[INFO] --- maven-jlink-plugin:3.0.0-alpha-1:jlink (default-jlink) @ mod-jlink
---
[INFO] Toolchain in maven-jlink-plugin: jlink [
/Library/Java/JavaVirtualMachines/jdk1.9.0_ea+181.jdk/Contents/Home/bin/jlink ]
[INFO] The following dependencies will be linked into the runtime image:
[INFO] -> module: com.corporate.project (
/../project/first-jmod/1.0-SNAPSHOT/first-jmod-1.0-SNAPSHOT.jmod )
[INFO] -> module: com.soebes.nine.one.jar (
/../maven-example-only-jars/mod-1-jar/target/mod-1-jar-1.0-SNAPSHOT.jar )
[INFO] -> module: com.soebes.nine.two.jar (
/.../maven-example-only-jars/mod-2-jar/target/mod-2-jar-1.0-SNAPSHOT.jar )
[INFO]
com.corporate.project
file:///.../com/corporate/project/first-jmod/1.0-SNAPSHOT/first-jmod-1.0-SNAPSHOT.jmod
com.soebes.nine.one.jar
file:///../maven-example-only-jars/mod-1-jar/target/mod-1-jar-1.0-SNAPSHOT.jar
com.soebes.nine.two.jar
file:///..//maven-example-only-jars/mod-2-jar/target/mod-2-jar-1.0-SNAPSHOT.jar
java.base
file:///Library/Java/JavaVirtualMachines/jdk1.9.0_ea+181.jdk/Contents/Home/jmods/java.base.jmod
Providers:
java.base provides java.nio.file.spi.FileSystemProvider used by java.base
[INFO] Building zip:
/.../maven-example-only-jars/mod-jlink/target/mod-jlink-1.0-SNAPSHOT.zip
{code}
The output should be correctly prefixed bei {{[INFO]}} etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MJAR-138) jar:test-jar is skipped when maven.test.skip=true
[
https://issues.apache.org/jira/browse/MJAR-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160271#comment-16160271
]
Karl Heinz Marbaise commented on MJAR-138:
--
First this is not related to the used Maven version it is related to the used
the maven-jar-plugin version. Apart from that yes this is actually the case.
You can bypass this by using the following configuration:
{code:xml}
maven-jar-plugin
XXX
false
{code}
> jar:test-jar is skipped when maven.test.skip=true
> -
>
> Key: MJAR-138
> URL: https://issues.apache.org/jira/browse/MJAR-138
> Project: Maven JAR Plugin
> Issue Type: Improvement
>Affects Versions: 2.3.1
> Environment: jar:test-jar
>Reporter: Andrew Hughes
> Fix For: more-investigation
>
> Attachments: MJAR-138-maven-jar-plugin.patch
>
>
> Not sure if this is a bug or improvement...
> Example:
> * ./pom.xml
> * ./moduleA/pom.xml
> * ./moduleB/pom.xml
> Situation:
> * moduleA produces moduleA-1.2.3-test.jar with the jar:test-jar goal
> * moduleB consumes moduleA-1.2.3-test.jar as a
> ...test
> Problem:
> * When -Dmaven.test.skip=true the moduleA-1.2.3-test.jar is never built.
> * Then when moduleB tries to build, it's moduleA-1.2.3-test.jar dependency is
> unresolved. FAIL! Even with -Dmaven.test.skip=true this will fail.
> You might argue that this is a bug with dependency resolution with
> -Dmaven.test.skip=true - should a missing dependency @ test scope really fail
> the build??? It probably should - which is why the bug is submitted here :)
> I've no idea what could be done to fix this either?
> ---
> p.s. for anyone with this bug the only workaround I can suggest is running
> another module...
> ./moduleA-test/pom.xml
> and have
> ...moduleA-test...test
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
