[jetty-dev] [jira] (JETTY-1517) Resolve submodule artifacts in reactor builds with Maven 3
"Thomas Broyer (JIRA)" <[email protected]> Tue, 21 Aug 2012 05:48:21 -0500 (CDT)
| Newsgroups | gmane.comp.java.jetty.general |
|---|---|
| Message-ID | <821711338.43391.1345546101543.JavaMail.j2ee-jira@codehaus01.managed.contegix.com> |
Thomas Broyer commented on JETTY-1517 Resolve submodule artifacts in reactor builds with Maven 3 Ah, note that reactor-resolution only works for classes and resources (project.build.outputDirectory), and specifically not for web resources. Those would have to be computed out of the MavenProject#getProjectReferences, if at all possible (the Tomcat plugin doesn't do it, see MTOMCAT-158 ). A workaround would be to use mvn -pl my-webapp -am package jetty:run but then Artifact#getFile would return the packaged JAR for the dependencies, defeating the purpose of launching jetty:run in a reactor build (which is to use the build.outputDirectory directly, so the webapp can be restarted easily while your IDE compiles the classes there on-the-fly, and without the need to package the dependencies). Maybe for overlays support, the plugin could require that prepare-package or war:exploded by run previously on the WAR dependencies, and then look at the output for these (<project.build.directory>/<project.build.finalName>) out of the getProjectReferences. See also MNG-5214 : for now (pending Maven 3.0.5), Maven will give you the build.outputDirectory for a dependency with type war; after the fix, Artifact#getFile() will instead return null. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators . For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email