Hi Franck, On 30/10/05, Franck de Bruijn <[EMAIL PROTECTED]> wrote: > Hi, > > I see that the tomcat plugin has an execution phase 'package' defined. > > I'm not sure if I understand correctly, but this causes all the steps > (compile, packaging, etcetera) to be repeated when goal 'tomcat:deploy' is > executed. Anyway, if I remove the line '@execute phase = "package"' from the > Deploy Mojo, these steps are not performed, and this is actually what I > would prefer. > > Since, I normally first build the multiproject (mvn install), and then > possibly want to deploy the generated WAR file to Tomcat (mvn > tomcat:deploy). Since the packaging phase has already been performed during > the initial build, the tomcat:deploy goal should not perform this anymore > (especially if you pack libraries like Struts and Hibernate with it, result > in a WAR-file of 9 MB).
You should normally just need to call either tomcat:deploy or install - they rarely need to be used together. In you are in development then tomcat:deploy will build the war and deploy it to tomcat. If you need to install the war into your local repo for a further project to use, then mvn install will work. Running both together will indeed build the war twice, but I'm not sure that this is a typical use case? > My questions are: > * is it possible to detach a certain goal of a plug-in from the build > lifecycle through some sort of a setting in the pom (I only encountered > documentation how to attach goals, but not how to detach them)? It's possible to run plugin goals at different phases in the lifecyle by using the <executions> element, see: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html Although I'd rather that this was not necessary for the majority of use cases. > * Or would it be a good idea to indeed remove the execution declaration from > the MOJO and let the users attach the goal to the lifecycle in the > plugin-section of the POM? tomcat:deploy depends on the package phase to ensure that the deployed war is up-to-date, otherwise it'd be all too easy to deploy old code. Forcing users to bind the goals themselves for simple deployments increases the learning curve, which I'd rather avoid. If you could clarify your development process then hopefully we can accommodate it within the plugin naturally. Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
