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 maven.2.user@gmail.com
 designates 209.85.216.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+nPnMzRSgdncuwkYEvTeyttKjkUH1wgv0C-WamGmV6A-cOo_g@mail.gmail.com>
References: <50D4C4D4.40903@gmail.com>
	<CA+nPnMwK9iTg7CvTgdS3RqJhrHxvDQbhPHw=QA9LoWdKacwgGA@mail.gmail.com>
	<CAChPNbc+BX2-1AXyHQfxziY2VBHDmHjqK5+RT+37oOw=Yzqmeg@mail.gmail.com>
	<CA+nPnMzRSgdncuwkYEvTeyttKjkUH1wgv0C-WamGmV6A-cOo_g@mail.gmail.com>
Date: Thu, 27 Dec 2012 10:45:37 -0500
Message-ID: 
 <CAChPNbdzQt6NXD3ZdoUEorUru9LJ43Xof=7PRSnNxbJ4ddVqgQ@mail.gmail.com>
Subject: Re: Maven profiles and resource filtering
From: Maven User <maven.2.user@gmail.com>
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=047d7bdc11e43f490b04d1d770e8

--047d7bdc11e43f490b04d1d770e8
Content-Type: text/plain; charset=ISO-8859-1

Our pattern is anything in nexus comes from jenkins.  All jobs have a
"prod" profile activated.

ALL this profile does is uses assembly descriptors that produce zips
instead of directories, includes stuff from src/main/resources in a
"templates" directory and inserts ERB style templating syntax so chef can
deploy.

If anything is missing, the absent property is caught during our nightly
"phoenix" build (and fix fast).  No one is introducing properties moments
before going to production (and they'd not be incorporated anyway due to
our branch management strategy.

If you have profiles that you use for building a release - and those make
the output is RADICALLY different - then yeah, that's a terrible idea!!!


On Wed, Dec 26, 2012 at 1:23 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> Which profile was version 1.2.1 built with?
>
> 1 hour later... Oh that was built with dev and should have been built with
> prod... There was one hour of my life wasted
>
> You are following an anti-pattern. Please don't. You are free to ignore my
> advice, just don't come cribbing and moaning to me later when it all blows
> up in your face ;-)
>
> On Wednesday, 26 December 2012, Maven User wrote:
>
> > Stephen - can you clarify which points you're against?
> >
> > If there are profiles (and filter files) for every environment they
> deploy
> > to - then yeah, don't do that.
> >
> > BUT - for example, if there are exactly two (one for dev, defaults in
> poms,
> > overrides in each person's settings.xml) and one for prod (which inserts
> > OTHER templates to be use by an orchestration system against these "new"
> > templates), then I see no harm - but they'll have to make sure each
> > property is defined (somewhere).
> >
> >
> >
> >
> > On Fri, Dec 21, 2012 at 3:32 PM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com <javascript:;>> wrote:
> >
> > >
> > >
> >
> http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
> > >
> > > Please don't do maven the way you are doing it
> > >
> > > On Friday, 21 December 2012, Niranjan Rao wrote:
> > >
> > > > Greetings,
> > > >
> > > > We have bunch of profiles and corresponding resource filtering which
> > all
> > > > works great. One frequent problem that we encounter team members
> often
> > > > forget to add new values in profile/filter property file of other
> > > profiles
> > > > than the one they are currently using. Naturally results are
> > disastrous.
> > > >  Normally we can find quickly which property is not filtered
> correctly
> > > and
> > > > fix it but this is tedious.
> > > >
> > > > I am wondering if there is any way to catch missing properties at
> build
> > > > time. That is when maven sees a property definition during filtering
> > > phase
> > > > which has variable declaration and could not locate the value, can it
> > > raise
> > > > the error and let the build fail?
> > > >
> > > > Thanks,
> > > >
> > > > Niranjan
> > > >
> > > >
> > ------------------------------**------------------------------**---------
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> <javascript:;>
> > > > For additional commands, e-mail: users-help@maven.apache.org
> <javascript:;>
> > > >
> > > >
> > >
> >
>

--047d7bdc11e43f490b04d1d770e8--