Yes I understand that. That's why I was suggesting the Maven2 approach with resources and filters. ;-)
This is all very possible with standard Maven2 usage and xml configuration files etc. I have presently defined "dev_workstation" as active, "dev", "qe", and "prod" in my profiles. Hoping to get the full build, configure, deploy in a single Maven command at some point in the near future (it hasn't really been a goal for me, so I haven't bothered to get it working 100% in Maven yet). Assuming you get your full process in a single command, perhaps post your pom etc back to the list for other people's usage? Wayne On 3/14/06, Sergei Dubov <[EMAIL PROTECTED]> wrote: > The point is of course that I am talking about properties files specific > to the application and not the build process. Just wanted to make it clear. > > Serge > > Wayne Fay wrote: > > Simon is right... I simply went "whole hog" with Maven2 as much as > > possible, and except for the Oc4j deployment via Ant, I have > > eliminated all "old" ant *.properties files in favor of profiles. > > > > So instead of various properties files in various places in my project > > filesystem, I've got it all contained in a single profile.xml file, > > and I'm much happier with the centralized management of all properties > > used in my project. > > > > Wayne > > > > > > On 3/14/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > > > >>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] > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
