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] > https://github.com/mfriedenhagen/foss-jar-maven-plugin/blob/master/src/main/resources/META-INF/plexus/components.xml#L103 > [2] > https://github.com/mfriedenhagen/foss-jar-maven-plugin/blob/master/src/main/resources/META-INF/plexus/components.xml#L77 > [3] > https://github.com/mfriedenhagen/foss-jar-maven-plugin/blob/master/src/it/test-foss-war/pom.xml#L31 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org <javascript:;> > For additional commands, e-mail: users-h...@maven.apache.org<javascript:;> > > -- Sent from my phone