[
https://jira.codehaus.org/browse/MNG-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318206#comment-318206
]
Nicholas Williams commented on MNG-3559:
----------------------------------------
I don't understand how I'm losing dependency management here. I have a set of
"helper" classes used to make certain testing operations easier in my project.
These cannot be abstracted out of the project, because they depend on the
project core. However, the tests for the project core rely on them for the
testing. Putting them in the compile scope of a separate module would introduce
a circular dependency; therefore, that is automatically not an option.
What I want seems pretty simple. I want the test code for one module to be able
to depend on the test code from another module. If we can make the main code
from one module depend on the test code from another module, it seems we should
be able to do the same thing for test code. And, indeed, there's this magical
feature in Maven that is supposed to be able to do that, except it's broken.
Whether or not this is a good feature in Maven is an entirely different
discussion that I'd be happy to have with you. But the fact of the matter is
that the feature exists in Maven and is documented as serving this purpose
(http://maven.apache.org/guides/mini/guide-attached-tests.html). In fact, the
documentation even says:
bq. Note that previous editions of this guide suggested to use
<classifier>tests</classifier> instead of <type>test-jar</type>. While this
currently works for some cases, it does not properly work during a reactor
build of the test JAR module and any consumer if a lifecycle phase prior to
install is invoked.
The problem, however, is that not even <type> works during a reactor build of
the test JAR module and any consumer. Not unless you run test-compile. But Even
if you run test-compile, if you invoke subsequent goals it stil doesn't work.
If it's not a good feature, then maybe it should be removed. I would argue that
it needs to be fixed.
> Multi-Module Project: module that depends on sibling test jar cannot execute
> test-compile without install of sibling first
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-3559
> URL: https://jira.codehaus.org/browse/MNG-3559
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Bootstrap & Build
> Affects Versions: 2.0.8, 2.0.9
> Reporter: Joshua Pollak
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: ActiveProjectTestJar-2.0.9.patch,
> ActiveProjectTestJar-r2-2.0.9.patch, demoPom-0.0.2-src.tgz, demoPom.tgz
>
>
> We have project with a few sibling modules:
> * Project
> ----moduleA
> +-- /src/main/java (Common Code)
> +-- /src/test/java (Common Test Framework)
> ----moduleB
> ----moduleC
> +-- /src/main/java (Production Code, depends on moduleA Common code)
> +-- /src/test/java (Production Test Framework, depends on
> moduleA Common Test Framework)
> I dont think there is anything wrong with this project in concept. moduleC's
> "main" code depends son moduleA's "main" code, and moduleC's test code
> depends on moduleA's test code.
> This works if I run 'mvn install', but for rapid development, we often run
> single unit tests and need to be able to run "mvn test" from the top level
> project, which fails.
> For an example, download the attached project and run "mvn test" from the
> trunk directory. It will fail with the error pasted below. Then, run "mvn
> install" and everything works ok. We should be able to run our unit tests
> without having to install first.
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Failed to resolve artifact.
> Missing:
> ----------
> 1) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=com.kiva.demoPom
> -DartifactId=moduleA -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests
> -Dpackaging=test-jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file -DgroupId=com.kiva.demoPom -DartifactId=moduleA
> -Dversion=0.0.1-SNAPSHOT -Dclassifier=tests -Dpackaging=test-jar
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> Path to dependency:
> 1) com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT
> 2) com.kiva.demoPom:moduleA:test-jar:tests:0.0.1-SNAPSHOT
> ----------
> 1 required artifact is missing.
> for artifact:
> com.kiva.demoPom:moduleC:jar:0.0.1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
