While Wayne's suggestion is probably better "maven style", I expect you
could also use the maven-antrun-plugin to execute an external ant task
at the process-resources phase.
http://maven.apache.org/plugins/maven-antrun-plugin/
http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
http://maven.apache.org/guides/mini/guide-configuring-plugins.html

On Tue, 2006-03-14 at 11:10 -0600, Wayne Fay wrote:
> Well first off, those properties files need to be placed in
> src/main/resources. Then you need to learn about filtering. ;-)
> 
> So what you do is something along these lines...
> /src/main/resources/c3p0.properties
> blah=abc
> yadda=xyz
> server=${c3p0.server}
> 
> Then in pom.xml:
>   <build>
>     <resources>
>       <resource>
>         <directory>src/main/resources</directory>
>         <filtering>true</filtering>
>       </resource>
>     </resources>
>   </build>
> 
> And then the profile & properties data in pom.xml or profile.xml.
> 
> Then finally:
> mvn package -P name1
> 
> And the proper variable values will be substituted into your
> properties files during the filter step.
> 
> HTH.
> Wayne
> 
> On 3/14/06, Sergei Dubov <[EMAIL PROTECTED]> wrote:
> > But those properties files are referenced by Spring configurations in
> > turn, c3p0.properties is the default for c3p0 connection pool
> > configuration. This all happens after deploying in Tomcat. How would
> > Spring know about Maven configurations when the war file is deployed on
> > a remote server? :-)
> >
> > I am open to other approaches but they have to work for one-stop builds.
> > I clearly want to be able to run a single command and have the app
> > deployed to a remote server with all the necessary configs.
> >
> > Serge
> >
> > Wayne Fay wrote:
> > > With a new build environment comes changes to your existing build.
> > > When you moved to Ant, you made these properties files. Now it might
> > > be time to change again if you move to Maven. So just realize upfront
> > > that you will probably have to change.
> > >
> > > The easiest way to achieve your requirements is through the use of
> > > profiles either in pom.xml, settings.xml, or profiles.xml file. Then
> > > you call "mvn -P name1 package" and it uses the variable values you
> > > have defined in the "name1" profile.
> > > See this page for more info:
> > > http://maven.apache.org/guides/introduction/introduction-to-profiles.html
> > >
> > > If you want to keep your existing properties files and build process,
> > > stay in Ant. You could probably write some complicated plugin to
> > > duplicate what you already have in ANT, but I wouldn't do it.
> > >
> > > Wayne
> > >
> > >
> > > On 3/14/06, Sergei Dubov <[EMAIL PROTECTED]> wrote:
> > >
> > >>I am still trying to get my head around the concept of user profiles
> > >>(using Maven2). Here is what I do in Ant:
> > >>
> > >>1. Let's say we have a project called "leonardo".
> > >>
> > >>2. To work with my Ant process the user is required to have a directory
> > >>called $HOME/.leonardorc and an environment variable called
> > >>$LEONARDO_EXT that contains his current configurational profile.
> > >>
> > >>3. $HOME/.leonardorc contains customer properties files. Let's say:
> > >>db.properties.${LEONARDO_EXT}, c3p0.properties.${LEONARDO_EXT},
> > >>tomcat.properties.${LEONARDO_EXT}. They all contain configurational info
> > >>specific to that user's current profile (set by LEONARD_EXT).
> > >>
> > >>4. The moment a user tries to do something (build, deploy, whatever).
> > >>Some of those files will be copied to the "right" place in the project
> > >>repository, and some will be directly referenced in the Ant build
> > >>script. Of course, the extension of ${LEONARDO_EXT} will be removed upon
> > >>copy.
> > >>
> > >>I'd really appreciate if somebody could explain to me how to achieve the
> > >>same flexibility with Maven. Note: the above-mentioned property files
> > >>have to be the entities that specify the user configuration.
> > >>
> > >>Thanks a lot beforehand!
> > >>
> > >>Serge
> > >>
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > 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]

Reply via email to