Hi Ivo, So, if you have 3 sub-projects (3 POM's under the root POM), 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. On 6/14/06, Ivo Limmen <[EMAIL PROTECTED]> wrote:
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" <[email protected]> > > 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] > > > > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
