maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mirko Friedenhagen <>
Subject "The Maven way" for delivery pipelines
Date Fri, 05 Jul 2013 20:29:30 GMT

now after some trial and error with custom packaging and lifecycles I
ask myself whether I should proceed or do something completely

What I want to achieve:
- We have loads of web-applications (WARs with a homegrown
configuration tooling)
- Some are single module projects, some are multi-module.
- All should be deployed to an adhoc tomcat instance after the WAR is
built to see whether configurations are solid and to do some
integrative tests.
- Right now we invoke a shell-script which runs several maven goals
(not phases) directly:
mvn clean verify
mvn internal:create-tomcat (special packaging with logback as logger etc.)
mvn internal:start-tomcat
mvn internal:deploy-war (this one will _modify_ the war's
configuration on the fly before deployment)
mvn webtest:test
mvn internal:stop-tomcat

Now, shell scripts are not very portable and so I thought about two solutions:

Solution 1:
Create a custom lifecycle called webtest
- My first idea was to create a custom lifecycle[1] which will invoke
some standard standard goals[2], so the complete vodoo could be done

mvn clean verify verify-webtest

- I tried this with a tiny IT project, where I configured failsafe to
do special stuff during the phase webtest of lifecycle webtest.
- However, now failsafe is invoked twice:
--- snip ---
[INFO] --- maven-failsafe-plugin:2.15:integration-test
(default-integration-test-1) @ foss-jar-maven-plugin-test-foss-war ---
[INFO] --- maven-failsafe-plugin:2.15:integration-test
(webtest-integration-test) @ foss-jar-maven-plugin-test-foss-war ---
--- snap ---

- As the tomcat plugins are invoked as well with the "wrong lifecycle"
default, I guess this will not work out.

Solution 2:

Would be to create a special packaging webtest and have a module in a
multi-module project, one creating the war and the webtest module
picking up the war as dependency and do the vodoo (on demand).
Then I could imagine having two jobs in Jenkins, one
deploying/installing the WAR and another Jenkins-Job running the shell
equivalent from above by only executing module webtest.

Now, I read a lot about Maven being a tool for *building  only*, but
in some way I like Maven and developing plugins is quite easy, so I
thought it might be nonetheless a good way.

What do you think, do I have a hammer and now everything looks like a
nail to me?
Or could I use one of the proposed solutions without abusing Maven to
much? Or is invoking the shell script as we do now a much better

Regards and thank you very much for reading up to here!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message