For this we use the profile in the settings.xml. We do this to avoid
creating a pom file with 30+ environments. If everyone uses a local profile
with their own unique settings you get a clean pom file. The only profiles
we do maintain in the pom file is the profile to build for the test,
acceptation and production environments.
I am also working with Maven for about one month. But this felt as the
proper way of doing things and (for what I understand) fits in the Maven
philosophy.
On 6/13/06, Toto Laricot <[EMAIL PROTECTED]> wrote:
I'm still trying to understand why Maven doesn't support profile
inheritance.
Would that go again the Maven philosophy?
Using settings.xml is fine to describe a developer's local environment,
not
to describe deployment properties.
Let's say I have a project with two subprojects: one for the client and
one
for the server; and 2 environments: Production and Test. In addition to
the
Production and Test environments, each developer has his/her own
development
environment.
I would expect to be able to define the test and production profiles in
the
parent POM; these profile would be inherited by the Test and Production
POMs' (no additional files to check out to build/deploy the app,
configuration is done all in one place); during development, these
profiles
would be merged with the same profiles defined in settings.xml to match
the
developer's environment.
Am I missing something?
Thanks,
Theo.
On 6/13/06, Kieran Brady <[EMAIL PROTECTED]> wrote:
>
> Hi Theo,
>
> You're correct, that solution does require duplication but in our case
its
> only a couple of POMs so is manageable for the time being.
>
> I believe that a profiles.xml may be the solution for multiple POMs but
I
> haven't yet had chance to test it out.
>
> Kieran
> ----- Original Message -----
> From: "Toto Laricot" <[EMAIL PROTECTED]>
> To: "Maven Users List" <users@maven.apache.org>
> Sent: Tuesday, June 13, 2006 5:51 AM
> Subject: Re: Best practices for multi-flavour build?
>
>
> Hi all,
>
> I have tried Kieran's solution myself; it works fine as long as the
> profiles
> are defined in the same POM that contains the variables that need to be
> injected.
>
> In other words –still using Kieran's example- if you define:
> <profile>
> <id>dev</id>
> […]
> <properties>
> <environment.name>dev</environment.name>
> </properties>
> […]
> </profile>
>
> in a parent POM, and this filter in a child POM:
>
> <filters>
> <filter>src/main/profiles/${delivery.name}/general-
filter.properties
> </filter>
>
> <filter>src/main/profiles/${delivery.name}/${environment.name}-
> filter.properties</filter>
> <filter>src/main/resources/${operatingsys.name}-filter.properties
> </filter>
>
> </filters>
>
> The properties won't be injected.
>
> So, if you have a hierarchy of POM's, you have to duplicate you profile
> definitions into every POM, which is a maintenance nightmare.
>
> I'd be curious to find out how people deal with this issue. Is the ant
> plugin the only solution? I sure hope not.
>
> Theo.
>
>
>
>
> On 6/12/06, badaud <[EMAIL PROTECTED]> wrote:
> >
> >
> > I will try something like this, thanks.
> > --
> > View this message in context:
> >
>
http://www.nabble.com/Best-practices-for-multi-flavour-build--t1741483.html#a4826563
> > Sent from the Maven - Users forum at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
