maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: "The Maven way" for delivery pipelines
Date Fri, 05 Jul 2013 22:23:53 GMT
On Friday, 5 July 2013, Mirko Friedenhagen wrote:

> Hello,
> now after some trial and error with custom packaging and lifecycles I
> ask myself whether I should proceed or do something completely
> different.
> 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
> with:
> 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?

I have been down your road several times... It feels like a bit of a
siren's call to me...

The most public thing I did down this road is mojo's ship-maven-plugin...
Which does things a, IMHO, more maven way *if* I were to imagine a maven
way for things that take place "beyond the (standard) lifecycle"

My current thinking is to use chef/puppet/etc for these tasks... But:

1. I am disappointed by how difficult these toolchains make things
2. Puppet is more "maven" in philosophy but at work our ops team voted for
chef, so harder to try the tool I feel should be best
3. Lab42's module framework for puppet feels better but puppet labs module
framework is "closer" to puppet as its by the main devs... I wish they can
find a way to interop better.

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
> solution?

I actually like shell scripts for this type of thing...

If it ain't broke...

> Regards and thank you very much for reading up to here!
> Mirko
> [1]
> [2]
> [3]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: <javascript:;>
> For additional commands, e-mail:<javascript:;>

Sent from my phone

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message