I will try something like this, thanks.

Hi all,

I have tried Kieran's solution myself; it works fine as long as the profiles
are defined in the same PM 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 PM, and this filter in a child PM:

<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 PM's, you have to duplicate you profile
definitions into every PM, 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.

6/12/06, badaud <vcm3wrt02 (AT) sneakemail (DOT) comwrote:
--
I will try something like this, thanks.

You can also put the profile in your global settings.xml. Then it will work
for all your builds.

6/13/06, Toto Laricot <toto.laricot (AT) gmail (DOT) comwrote:

Hi all,

I have tried Kieran's solution myself; it works fine as long as the
profiles
are defined in the same PM 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 PM, and this filter in a child PM:

<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 PM's, you have to duplicate you profile
definitions into every PM, 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.
>
>
>
>
6/12/06, badaud <vcm3wrt02 (AT) sneakemail (DOT) comwrote:
--
I will try something like this, thanks.

Yes, but the problem is that you end up with build information residing
outside of the PM. It's fine for properties that are developer-dependent (
e.g. app server's location on disk), but if the properties are
client-related (e.g. build the app for SiteA or for SiteB), it does not work
so well, because in order to build, you have to check out another file (
settings.xml).
I'm fairly new to maven and I don't understand the rationale for not
supporting profile inheritance.
I'm sure there is a good reason, I just don't see it.
Could somebody please shed some light on this?

Thanks,

T.

6/12/06, Ivo Limmen <ivolimmen (AT) gmail (DOT) comwrote:

You can also put the profile in your global settings.xml. Then it will
work
for all your builds.

6/13/06, Toto Laricot <toto.laricot (AT) gmail (DOT) comwrote:

Hi all,

I have tried Kieran's solution myself; it works fine as long as the
profiles
are defined in the same PM 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 PM, and this filter in a child PM:

<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 PM's, you have to duplicate you profile
definitions into every PM, 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.
>
>
>
>
6/12/06, badaud <vcm3wrt02 (AT) sneakemail (DOT) comwrote:
--
I will try something like this, thanks.

Hi Theo,

You're correct, that solution does require duplication but in our case its
only a couple of PMs so is manageable for the time being.

I believe that a profiles.xml may be the solution for multiple PMs but I
haven't yet had chance to test it out.

Kieran
Message
From: "Toto Laricot" <toto.laricot (AT) gmail (DOT) com>
To: "Maven Users List" <users (AT) maven (DOT) 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 PM 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 PM, and this filter in a child PM:

<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 PM's, you have to duplicate you profile
definitions into every PM, 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.

6/12/06, badaud <vcm3wrt02 (AT) sneakemail (DOT) comwrote:
--
I will try something like this, thanks.

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 PM; these profile would be inherited by the Test and Production
PMs' (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.

6/13/06, Kieran Brady <kieran.brady (AT) teamcgi (DOT) netwrote:

Hi Theo,

You're correct, that solution does require duplication but in our case its
only a couple of PMs so is manageable for the time being.

I believe that a profiles.xml may be the solution for multiple PMs but I
haven't yet had chance to test it out.

Kieran
Message
From: "Toto Laricot" <toto.laricot (AT) gmail (DOT) com>
To: "Maven Users List" <users (AT) maven (DOT) 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 PM 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 PM, and this filter in a child PM:

<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 PM's, you have to duplicate you profile
definitions into every PM, 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.
>
>
>
>
6/12/06, badaud <vcm3wrt02 (AT) sneakemail (DOT) comwrote:
--
I will try something like this, thanks.

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.

6/13/06, Toto Laricot <toto.laricot (AT) gmail (DOT) comwrote:

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 PM; these profile would be inherited by the Test and Production
PMs' (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.
>
>
>
>
6/13/06, Kieran Brady <kieran.brady (AT) teamcgi (DOT) netwrote:

Hi Theo,

You're correct, that solution does require duplication but in our case
its
only a couple of PMs so is manageable for the time being.

I believe that a profiles.xml may be the solution for multiple PMs but
I
haven't yet had chance to test it out.

Kieran
Message
From: "Toto Laricot" <toto.laricot (AT) gmail (DOT) com>
To: "Maven Users List" <users (AT) maven (DOT) 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 PM 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 PM, and this filter in a child PM:

<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 PM's, you have to duplicate you profile
definitions into every PM, 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.
>
>
>
>
6/12/06, badaud <vcm3wrt02 (AT) sneakemail (DOT) comwrote:
--
I will try something like this, thanks.

Hi Ivo,

So, if you have 3 sub-projects (3 PM's under the root PM), you
define the test/acceptance/production profiles in each one of them?

I.e. the DB information (jdbc url, username, etc.) - for instance-
has to be repeated 3 times?

Theo.

6/14/06, Ivo Limmen <ivolimmen (AT) gmail (DOT) comwrote:
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.

6/13/06, Toto Laricot <toto.laricot (AT) gmail (DOT) comwrote:

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 PM; these profile would be inherited by the Test and Production
PMs' (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.
>
>
>
>
6/13/06, Kieran Brady <kieran.brady (AT) teamcgi (DOT) netwrote:

Hi Theo,

You're correct, that solution does require duplication but in our case
its
only a couple of PMs so is manageable for the time being.

I believe that a profiles.xml may be the solution for multiple PMs but
I
haven't yet had chance to test it out.

Kieran
Message
From: "Toto Laricot" <toto.laricot (AT) gmail (DOT) com>
To: "Maven Users List" <users (AT) maven (DOT) 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 PM 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 PM, and this filter in a child PM:

<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 PM's, you have to duplicate you profile
definitions into every PM, 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.
>
>
>
>
6/12/06, badaud <vcm3wrt02 (AT) sneakemail (DOT) comwrote:
--
I will try something like this, thanks.