I'm trying to configure pom.xml
so that it automatically deploys EAR archive to GlassFish application server. I want to attach this operation to the proper maven execution phase. But can't understand which one is dedicated just for this operation? Deploy? Install? Please, help. This is what I'm doing:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>deploy</phase>
<configuration>
<tasks>
<copy file="${project.build.directory}/${project.build.finalName}.ear"
tofile="${glassfish.home}/domains/domain1/autodeploy"/>
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
When I'm doing mvn deploy
, maven is trying to deploy my artifacts to repository. This is not what I'm going to accomplish. I feel that the execution phase is wrong..
When I'm doing
mvn deploy
, maven is trying todeploy
my artifacts to repository. This is not what I'm going to accomplish. I feel that the execution phase is wrong...
In the Maven lingua, deploy has nothing to do with the deployment to an application server and is not an appropriate phase to bind a plugin doing this kind of work. Here is what we can read about the deploy
phase in the Introduction to the Build Lifecycle:
deploy
- done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
But, before I go further with phases, I need to mention that there are several plugins allowing to interact with GF (start/stop/deploy/undeploy/etc) that might do a better job than the AntRun plugin (AntRun might work for trivial use cases but, for example, you might want to wait for the deployment to be done and the application to be in a ready state during the build; for such use cases, you need more advanced control). These candidates are:
Using one or the other really depends on your use case. If you don't plan to deploy on many containers, the GlassFish specific plugins are the most powerful. The beauty of Cargo is that it offers an unified API. But its configuration is less intuitive, especially if you're not used to it.
Now, if you just want to deploy an application during development and don't want the build to interact in any way with the container, binding any of these plugins to a particular phase is not that useful, although some people do deploy their app during package
.
However, you might want to run integration/functional tests against a container as part of you build. This is actually a perfectly valid and very common use case and the relevant phases to implement this are:
pre-integration-test
: perform actions required before integration tests are executed. This may involve things such as setting up the required environment.integration-test
: process and deploy the package if necessary into an environment where integration tests can be run.post-integration-test
: perform actions required after integration tests have been executed. This may including cleaning up the environment.
The pre-integration-test
phase is typically used to start a container and deploy an application on it. The post-integration-test
phase is used to undeploy an application and stop the container.
So I think that deploying to a server can be a typical build activity, there are very valid use cases, and this is well supported by Maven. I don't deploy to my development server (nor to production server) as part of a build though.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With