Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (nike.apache.org: domain of mfriedenhagen@gmail.com
 designates 209.85.214.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+nPnMyR35E2_SVSh0WMrhoc85dP+F5HM11Rp2PNcY4JMXQE3A@mail.gmail.com>
References: 
 <CAK8jvqyL0DoDxg-nBxLxK2cjvW+8rofLwcKKNtZsnz+GFcQTkQ@mail.gmail.com>
	<CA+nPnMyR35E2_SVSh0WMrhoc85dP+F5HM11Rp2PNcY4JMXQE3A@mail.gmail.com>
Date: Sat, 6 Jul 2013 08:04:54 +0200
Message-ID: 
 <CAK8jvqyPFzzxfR4rtE7CbrHLCyPAf84FDyO2fM-=w+J_mJLVtA@mail.gmail.com>
Subject: Re: "The Maven way" for delivery pipelines
From: Mirko Friedenhagen <mfriedenhagen@gmail.com>
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=047d7b2e4b5e1c1d2704e0d19726

--047d7b2e4b5e1c1d2704e0d19726
Content-Type: text/plain; charset=UTF-8

Stephen, Russel,

thanks for your suggestions so far. I will take a look into the plugins you
mentioned.

Our operations department is using puppet and I did some tiny steps with. I
agree it feels a bit like Maven because it is declarative as well. Now Ruby
is IMO Python's perlish brother, so I am not very fond of it :-).

Regards Mirko
-- 
Sent from my mobile
On Jul 6, 2013 12:24 AM, "Stephen Connolly" <stephen.alan.connolly@gmail.com>
wrote:

> 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-unsubscribe@maven.apache.org<javascript:;>
> > For additional commands, e-mail: users-help@maven.apache.org
> <javascript:;>
> >
> >
>
> --
> Sent from my phone
>

--047d7b2e4b5e1c1d2704e0d19726--