[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=366007#comment-366007
]
Sebastian Paul commented on SUREFIRE-1024:
--
For the usual unit and integration tests, you are absolutely right. But in my
concrete case, the test is not in my ownership. That special test run applies
aspects with load time weaving, in order to gather data for further analysis.
Maybe the use case is too special for Surefire, but the dependenciesToScan
option is there. And in my opinion, verify should not claim that no tests ran,
when integration-test actually did run tests.
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments: surefire-1024-works-for-me.zip,
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> 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
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365998#comment-365998
]
Sebastian Paul commented on SUREFIRE-1024:
--
I am using the POM packaging, because I just want to run tests from an existing
JAR, and generate a site for the results. The project itself should not compile
anything, so the JAR packaging seems not appropriate.
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments: surefire-1024-works-for-me.zip,
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> 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
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365994#comment-365994
]
Sebastian Paul commented on SUREFIRE-1024:
--
Tibor, I was able to reproduce the problem with your provided project, after I
changed packaging to *POM*.
{code}
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building pokus 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ pokus ---
[INFO] Deleting D:\Dev\sc\workspace\surefire-1024-works-for-me\project\target
[INFO]
[INFO] --- maven-failsafe-plugin:2.18.1:integration-test (integration-test) @
pokus ---
[INFO] Failsafe report directory:
D:\Dev\sc\workspace\surefire-1024-works-for-me\project\target\failsafe-reports
---
T E S T S
---
Running a1.A1IT
class a1.A1IT
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.01 sec - in
a1.A1IT
Results :
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
[WARNING] File encoding has not been set, using platform encoding Cp1252, i.e.
build is platform dependent! The
provided by the POM property ${project.reporting.outputEncoding}.
[INFO]
[INFO] --- maven-failsafe-plugin:2.18.1:verify (verify) @ pokus ---
[INFO] No tests to run.
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 11.960 s
[INFO] Finished at: 2015-04-02T10:45:24+02:00
[INFO] Final Memory: 8M/155M
[INFO]
{code}
Verify claims, there were no tests to run.
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments: surefire-1024-works-for-me.zip,
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> 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
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365931#comment-365931
]
Sebastian Paul edited comment on SUREFIRE-1024 at 4/1/15 2:51 AM:
--
I have that problem with JUnit, i.e. it is independent from the provider.
At a first sight, I see a similarity between my POM and and that one in the
description above:
integration-test and verify are in separate executions
In Tibors POM, they are in one single execution.
I can imagine that this is the cause.
My build depends on separate executions, as I need to bind the goals to
different phases than the default,
was (Author: sebpaul):
I have that problem with JUnit, i.e. it is independent from the provider.
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments:
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> 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
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365931#comment-365931
]
Sebastian Paul commented on SUREFIRE-1024:
--
I have that problem with JUnit, i.e. it is independent from the provider.
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments:
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> 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
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365894#comment-365894
]
Sebastian Paul edited comment on SUREFIRE-1024 at 3/31/15 3:12 AM:
---
For the impatient, simply unpack the tests as workaround:
{code:xml|title=pom.xml}
org.apache.maven.plugins
maven-dependency-plugin
2.10
unpack-tests
unpack-dependencies
tests-jar
**/IT*.class,**/*IT.class,**/*ITCase.class
${project.build.testOutputDirectory}
{code}
was (Author: sebpaul):
For the unpatient, simply unpack the tests as workaround:
{code:xml|title=pom.xml}
org.apache.maven.plugins
maven-dependency-plugin
2.10
unpack-tests
unpack-dependencies
tests-jar
**/IT*.class,**/*IT.class,**/*ITCase.class
${project.build.testOutputDirectory}
{code}
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments:
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> 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
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365894#comment-365894
]
Sebastian Paul edited comment on SUREFIRE-1024 at 3/31/15 3:11 AM:
---
For the unpatient, simply unpack the tests as workaround:
{code:xml|title=pom.xml}
org.apache.maven.plugins
maven-dependency-plugin
2.10
unpack-tests
unpack-dependencies
tests-jar
**/IT*.class,**/*IT.class,**/*ITCase.class
${project.build.testOutputDirectory}
{code}
was (Author: sebpaul):
For the unpatient, simply unpack the tests as workaround:
{code:title=pom.xml}
org.apache.maven.plugins
maven-dependency-plugin
2.10
unpack-tests
unpack-dependencies
tests-jar
**/IT*.class,**/*IT.class,**/*ITCase.class
${project.build.testOutputDirectory}
{code}
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments:
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> 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
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1024) "verify" goal ignores "dependenciesToScan" parameter when checking tests existence
[
https://jira.codehaus.org/browse/SUREFIRE-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=365894#comment-365894
]
Sebastian Paul commented on SUREFIRE-1024:
--
For the unpatient, simply unpack the tests as workaround:
{code:title=pom.xml}
org.apache.maven.plugins
maven-dependency-plugin
2.10
unpack-tests
unpack-dependencies
tests-jar
**/IT*.class,**/*IT.class,**/*ITCase.class
${project.build.testOutputDirectory}
{code}
> "verify" goal ignores "dependenciesToScan" parameter when checking tests
> existence
> --
>
> Key: SUREFIRE-1024
> URL: https://jira.codehaus.org/browse/SUREFIRE-1024
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.16
>Reporter: Dmitry Kholodilov
> Fix For: 3.0
>
> Attachments:
> verify_goal_ignores_dependenciesToScan_parameter_when_checking_tests_existence.patch
>
>
> Consider Maven project with packaging=pom that executes tests from some
> external jar:
> {code:xml}
> 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
> test
> test
> test
> pom
>
>
> test
> tests-jar
> 1.0
> tests
>
>
> org.testng
> testng
> 6.8
>
>
>
>
>
> maven-failsafe-plugin
> 2.17-SNAPSHOT
>
>
> test:tests-jar
>
>
>
>
> integration-test
> integration-test
>
> integration-test
>
>
>
> verify
> verify
>
> verify
>
>
>
>
>
>
>
> {code}
> (real use case is execution of prebuilt end-to-end tests of some system after
> its deployment)
> When we run `mvn clean verify` on such project, failsafe plugin's "verify"
> goal reports the following:
> {noformat}
> [INFO] --- maven-failsafe-plugin:2.16:verify (verify) @ test ---
> [INFO] No tests to run.
> {noformat}
> Consequently, even if there are test failures, build success is reported.
> The reason of such behavior is that VerifyMojo ignores "dependenciesToScan"
> parameter. So, the fix is easy - check its existence along with
> "testClassesDirectory" existence, the same way as implemented in
> AbstractSurefireMojo.
> The patch in attachment includes integration test that checks for build
> failure when there is failed test from dependency jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] Commented: (MNG-3939) dependencyManagement does not inherit imported dependencies
[ http://jira.codehaus.org/browse/MNG-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243542#action_243542 ] Sebastian Paul commented on MNG-3939: - I forgot to mention that I used Maven 2.2.1 > dependencyManagement does not inherit imported dependencies > --- > > Key: MNG-3939 > URL: http://jira.codehaus.org/browse/MNG-3939 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.9 >Reporter: Ben Dean > Fix For: Issues to be reviewed for 3.x > > Attachments: console_output.txt, > maven-dependency-inherited-import.not-working.zip, > maven-dependency-inherited-import.working.zip > > > I've attached a zip that has two versions of the same multi-module project. > In the first version there is a parent-pom which defines a > dependencyManagement section with one dependency (junit 4.4). I child project > then inherits from the parent-pom and inherits the dependency management > section including the version number for junit. Then then child project can > have a dependency for junit and not care about the version number which is > managed by the dependencyManagement inherited from the parent. > In the second version, the dependencyManagement of the parent has been moved > to a dependency-pom. This makes sense because the dependencyManagement > section for a multi-module project could get huge and it would be nice to > keep the parent-pom small and clean and just import dependencyManagement as > needed. The problem is that the child project does not inherit these imported > dependencies. It seems to me that imported dependencyManagement sections > should be inherited too. This is the error given when the child doesn't what > version of junit to use: > Project ID: maven.dependency.example:child > POM Location: C:\sandbox\eclipse\default\maven example\child\pom.xml > Validation Messages: > [0] 'dependencies.dependency.version' is missing for junit:junit > This is somewhat related (maybe only tangentially) to the following issues: > http://jira.codehaus.org/browse/MNG-3553 > http://jira.codehaus.org/browse/MNG-2314 > http://jira.codehaus.org/browse/MNG-3537 > maybe more ... > However, all those other issues seem to involve a more complex example than > this issue. This issue is just dependencyManagement, import and inheritance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3939) dependencyManagement does not inherit imported dependencies
[ http://jira.codehaus.org/browse/MNG-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243541#action_243541 ] Sebastian Paul commented on MNG-3939: - I tried to reproduce this. First, I added pom, because Maven complained. Then I installed the dependency-pom. Checking with 'mvn help:effective-pom' shows that the parent contains the correct dependencyManagement and that the child contains the correct dependency to junit. I think the issue can be closed. > dependencyManagement does not inherit imported dependencies > --- > > Key: MNG-3939 > URL: http://jira.codehaus.org/browse/MNG-3939 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.9 >Reporter: Ben Dean > Fix For: Issues to be reviewed for 3.x > > Attachments: console_output.txt, > maven-dependency-inherited-import.not-working.zip, > maven-dependency-inherited-import.working.zip > > > I've attached a zip that has two versions of the same multi-module project. > In the first version there is a parent-pom which defines a > dependencyManagement section with one dependency (junit 4.4). I child project > then inherits from the parent-pom and inherits the dependency management > section including the version number for junit. Then then child project can > have a dependency for junit and not care about the version number which is > managed by the dependencyManagement inherited from the parent. > In the second version, the dependencyManagement of the parent has been moved > to a dependency-pom. This makes sense because the dependencyManagement > section for a multi-module project could get huge and it would be nice to > keep the parent-pom small and clean and just import dependencyManagement as > needed. The problem is that the child project does not inherit these imported > dependencies. It seems to me that imported dependencyManagement sections > should be inherited too. This is the error given when the child doesn't what > version of junit to use: > Project ID: maven.dependency.example:child > POM Location: C:\sandbox\eclipse\default\maven example\child\pom.xml > Validation Messages: > [0] 'dependencies.dependency.version' is missing for junit:junit > This is somewhat related (maybe only tangentially) to the following issues: > http://jira.codehaus.org/browse/MNG-3553 > http://jira.codehaus.org/browse/MNG-2314 > http://jira.codehaus.org/browse/MNG-3537 > maybe more ... > However, all those other issues seem to involve a more complex example than > this issue. This issue is just dependencyManagement, import and inheritance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MSITE-519) overwrite inherited menu item or add addition item to inherited menu
[ http://jira.codehaus.org/browse/MSITE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241292#action_241292 ] Sebastian Paul edited comment on MSITE-519 at 10/28/10 8:02 AM: Hi, the current behavior has been introduced with maven-site-plugin version 2.1 for fixing MSITE-293, where the inheritance concept is not usable for us. One can choose whether a menu is always inherited (with no way of overriding in children) or not inherited at all. This choice is made in the parent project. Child projects don't have a control at all. In versions until 2.0.1, menus (without the inherit attribute) have been inherited from the parent unless a site.xml is present. When a project needed to add a link to a menu, a site.xml had to be added, and all menus had to be redefined. We never made use of the "inherit" attribute, for the reasons explained in the description. For a working around this issue, we have been stuck with version 2.0.1. Unfortunately, this now holds us back from migrating to Maven 3, as the old plugin version is not compatible. There should really be a way of overriding inherited menus, so that they can be extended (or even replaced or removed). For this, child projects have to control the inheritence. was (Author: sebpaul): Hi, this behavior has been introduced with maven-site-plugin version 2.1 for fixing MSITE-293. For a work-around we have been stuck with version 2.0.1. Unfortunately, this now holds us back from migrating to Maven 3, as the old plugin version is not compatible. > overwrite inherited menu item or add addition item to inherited menu > > > Key: MSITE-519 > URL: http://jira.codehaus.org/browse/MSITE-519 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 3.0-beta-3 > Environment: maven 3.0 >Reporter: Thomas Wabner > > I have a parent project with a site descriptor where I have defined a menu > like this: > ... > > > > ... > Now I have a child project which should "overwrite" OR add addition item(s) > to the inherited site descriptor like this: > ... > > > > > ... > The current behavior is that the "Overview" menu is rendered twice in the > resulting site. > But I expect that the additional menu item will be mixed into the "Overview" > menu. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-519) overwrite inherited menu item or add addition item to inherited menu
[ http://jira.codehaus.org/browse/MSITE-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=241292#action_241292 ] Sebastian Paul commented on MSITE-519: -- Hi, this behavior has been introduced with maven-site-plugin version 2.1 for fixing MSITE-293. For a work-around we have been stuck with version 2.0.1. Unfortunately, this now holds us back from migrating to Maven 3, as the old plugin version is not compatible. > overwrite inherited menu item or add addition item to inherited menu > > > Key: MSITE-519 > URL: http://jira.codehaus.org/browse/MSITE-519 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 3.0-beta-3 > Environment: maven 3.0 >Reporter: Thomas Wabner > > I have a parent project with a site descriptor where I have defined a menu > like this: > ... > > > > ... > Now I have a child project which should "overwrite" OR add addition item(s) > to the inherited site descriptor like this: > ... > > > > > ... > The current behavior is that the "Overview" menu is rendered twice in the > resulting site. > But I expect that the additional menu item will be mixed into the "Overview" > menu. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGELOG-109) Support SVN merge history
Support SVN merge history - Key: MCHANGELOG-109 URL: http://jira.codehaus.org/browse/MCHANGELOG-109 Project: Maven 2.x Changelog Plugin Issue Type: Improvement Reporter: Sebastian Paul Currently, merged revisions from SVN are not shown in the log. TortoiseSVN or Subversive support this with the "Show merged revisions" switch. The SVN command line tool provides a switch -g [--use-merge-history] : use/display additional information from merge history. Of course, this requires an SVN server >= 1.5. I am wondering if the maven-scm-api supports this at all. If there is a way to support this feature, the plugin should provide a switch to enable it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=221919#action_221919 ] Sebastian Paul commented on MNG-2258: - @Daniel: How did you work around this issue without running jxr twice? I am using Maven 2.2.1 too, and have the same issue. When jxr only runs once in pre-site, the report does not contain a link to the source (Reports section in the navigation area). Only the tag list plugin correctly links to the source... > Wrong execution order of plugins in same phase > -- > > Key: MNG-2258 > URL: http://jira.codehaus.org/browse/MNG-2258 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: N/A >Reporter: David J. M. Karlsen >Priority: Blocker > Attachments: mavenTest.zip > > > AFAIK plugins should be execute in the same order as they are listed in the > POM, when bound to the same phase. This does not happen, the execution order > is arbitrary. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
