[
https://jira.codehaus.org/browse/MNG-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287010#comment-287010
]
Jesse Glick commented on MNG-5059:
----------------------------------
http://maven.40175.n5.nabble.com/Inflexibility-of-also-make-w-r-t-unusual-goals-td3073240.html
is a better archive link.
http://hg.netbeans.org/core-main/rev/3085ac76f9ae highlights a related use case
for {{nbm-maven-plugin}}. The plugin will typically manage one project with
{{nbm-application}} packaging, plus a number of projects with {{nbm}}
packaging, in one reactor. For the {{nbm}} projects, the {{\*.nbm}} artifact is
produced in the {{package}} phase. For the {{nbm-application}} project, the
{{package}} phase in the default lifecycle includes {{nbm:cluster-app}}, with
some overhead, and the rather slower {{nbm:standalone-zip}} which produces the
primary artifact. For interactive testing, {{nbm:standalone-zip}} is
unnecessary; {{nbm:run-platform}} requires just {{nbm:cluster-app}} to have
been run. So if all recently modified module projects have been built already
({{install}}), {{mvn -f application/pom.xml nbm:cluster-app nbm:run-platform}}
suffices to test changes. But if you want to use automake mode to rebuild all
modules in the reactor, you are stuck: you have to run at least to the
{{package}} phase in all modules (to get the {{nbm:nbm}} goal), but {{-am}}
will then run {{package}} on the app project, which will gratuitously create
the ZIP artifact. Would rather be able to run {{mvn -amp package -pl
application nbm:cluster-app nbm:run-platform}} to do the minimum required work
(this assumes that {{nbm:cluster-app}} can load {{\*/target/*.nbm}} files from
the reactor rather than local repo).
> --also-make-phase
> -----------------
>
> Key: MNG-5059
> URL: https://jira.codehaus.org/browse/MNG-5059
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Command Line
> Affects Versions: 3.0.3
> Reporter: Jesse Glick
>
> Background:
> http://mail-archives.apache.org/mod_mbox/maven-dev/201104.mbox/%3Cincnbn$4kl$1...@dough.gmane.org%3E
> {{--also-make}} (with {{--projects}}) is useful, but suffers from the problem
> that dependent projects are always built to the same goal/phase as the
> selected project(s). That is fine for e.g. {{compile}} or {{install}}, but
> not for e.g. {{test}} where you would only want to build {{compile}} (or
> {{test-compile}}) for dependencies, not actually test them.
> Suggest a variant form of this parameter (say {{--also-make-phase}} /
> {{-amp}}) which would accept a goal or phase to run on dependencies in place
> of the regular arguments. For example, to run a unit test after making sure
> all its dependencies have been (re-)compiled:
> {noformat}
> mvn -amp test-compile -pl testedmod test -Dtest=OneTest
> {noformat}
> or to run an (unpacked) web application after (re-)compiling libraries it
> uses:
> {noformat}
> mvn -amp compile -pl webapp jetty:run
> {noformat}
> You might want to pass a goal rather than a phase, so the name could be
> misleading, but I think that would be a rarer use case. Ditto passing
> multiple goals/phases for the upstream projects.
--
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
