do something before *.properties files load
Hi, I'd like to set a property based on some other command line property. For instance if: maven -Denv=qa java:compile I'd like this: build.properties --- some.arbitrary.property=qaValue but if maven -Denv=prod java:compile I'd like this: build.properties --- some.arbitrary.property=prodValue I've come up with 2 theoretical solutions, but I don't know if either are valid. 1) Can I embed jelly in my build.properties files? 2) Is there a goal that occurs before maven loads the properties file. So I could write a ... ... some.arbitrary.property=qaValue ... some.arbitrary.property=prodValue Thanks, Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: do something before *.properties files load
> 1) Can I embed jelly in my build.properties files? The answer to the question you were trying to ask is yes, but to this specific one, no. Jelly is the XML scripting, JEXL is the expression language used in Jelly. You can use an expression in build.properties, but not embed Jelly - just in case you wanted to start doing conditionals :) eg, somedir=${basedir}/src otherdir=${maven.build.dir}/other > 2) Is there a goal that occurs before maven loads the properties > file. So I could write a > ... > ... > some.arbitrary.property=qaValue > ... > some.arbitrary.property=prodValue No, but the first is nicer and works. - Brett > > Thanks, > Ben > > - > 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]
Re: do something before *.properties files load
Thanks Brett. I ran some tests specifying expressions in the project.properties file. It's pretty neat how the properties retain a reference of some kind instead of resolving at the initial assignment. For instance: qb.name=Tommy Maddox best.qb.ever=${qb.name} qb.name=Ben Roethlisberger now best.qb.ever is "Ben Roethlisberger". I see this works now - is this indended (I'm assuming is must be)? Am I safe in relying on maven to stay this way? One more general question. The reason I'm asking is because I'd like to do the following. Maybe this is way off base and there's a better way: command -- maven -Denv=qa jar:jar maven.xml ... project.properties - maven.src.dir=${basepath}/src/java project.xml - ... this is bogus and will never be used Does this make sense? I think this is the best way to be able to flip things like maven.src.dir by specifying an environment on the command line. One more.. I can't find the property that equates to this tag . I checked here: http://maven.apache.org/reference/plugins/test/properties.html and here: http://maven.apache.org/reference/user-guide.html#Behavioural_Properties am I just blind or is it not listed? Thanks, Ben On Fri, 19 Nov 2004 09:01:48 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > > 1) Can I embed jelly in my build.properties files? > > The answer to the question you were trying to ask is yes, but to this > specific one, no. Jelly is the XML scripting, JEXL is the expression > language used in Jelly. You can use an expression in build.properties, > but not embed Jelly - just in case you wanted to start doing > conditionals :) > > eg, > somedir=${basedir}/src > otherdir=${maven.build.dir}/other > > > 2) Is there a goal that occurs before maven loads the properties > > file. So I could write a > > ... > > ... > > some.arbitrary.property=qaValue > > ... > > some.arbitrary.property=prodValue > > No, but the first is nicer and works. > > - Brett > > > > > Thanks, > > Ben > > > > - > > 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]
Re: do something before *.properties files load
Hi Ben, Yes, you can expect that behaviour to remain the same. maven.src.dir is not what you think it is. You would need to modify pom.build.sourceDirectory, but this is not recommended. Why are you changing sources in different environments? Perhaps you want s? - Brett On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson <[EMAIL PROTECTED]> wrote: > Thanks Brett. I ran some tests specifying expressions in the > project.properties file. It's pretty neat how the properties retain a > reference of some kind instead of resolving at the initial assignment. > For instance: > > qb.name=Tommy Maddox > best.qb.ever=${qb.name} > qb.name=Ben Roethlisberger > > now best.qb.ever is "Ben Roethlisberger". I see this works now - is > this indended (I'm assuming is must be)? Am I safe in relying on > maven to stay this way? > > One more general question. The reason I'm asking is because I'd like > to do the following. Maybe this is way off base and there's a better > way: > > command > -- > maven -Denv=qa jar:jar > > maven.xml > > > > > > ... > > project.properties > - > maven.src.dir=${basepath}/src/java > > project.xml > - > ... > > > this is bogus and will never be used > > > Does this make sense? I think this is the best way to be able to flip > things like maven.src.dir by specifying an environment on the command > line. > > One more.. I can't find the property that equates to this tag > . I checked here: > http://maven.apache.org/reference/plugins/test/properties.html > and here: > http://maven.apache.org/reference/user-guide.html#Behavioural_Properties > am I just blind or is it not listed? > > Thanks, > Ben > > > > > On Fri, 19 Nov 2004 09:01:48 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > > > 1) Can I embed jelly in my build.properties files? > > > > The answer to the question you were trying to ask is yes, but to this > > specific one, no. Jelly is the XML scripting, JEXL is the expression > > language used in Jelly. You can use an expression in build.properties, > > but not embed Jelly - just in case you wanted to start doing > > conditionals :) > > > > eg, > > somedir=${basedir}/src > > otherdir=${maven.build.dir}/other > > > > > 2) Is there a goal that occurs before maven loads the properties > > > file. So I could write a > > > ... > > > ... > > > some.arbitrary.property=qaValue > > > ... > > > some.arbitrary.property=prodValue > > > > No, but the first is nicer and works. > > > > - Brett > > > > > > > > Thanks, > > > Ben > > > > > > - > > > 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]
Re: do something before *.properties files load
I want to be able to build the source using either my local working directory which I have modified, or vss's shadow directory which contains only checked in files. Same goes for unit tests. On Sat, 20 Nov 2004 00:26:28 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > Hi Ben, > > Yes, you can expect that behaviour to remain the same. > > maven.src.dir is not what you think it is. You would need to modify > pom.build.sourceDirectory, but this is not recommended. > > Why are you changing sources in different environments? Perhaps you > want s? > > - Brett > > > > > On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson > <[EMAIL PROTECTED]> wrote: > > Thanks Brett. I ran some tests specifying expressions in the > > project.properties file. It's pretty neat how the properties retain a > > reference of some kind instead of resolving at the initial assignment. > > For instance: > > > > qb.name=Tommy Maddox > > best.qb.ever=${qb.name} > > qb.name=Ben Roethlisberger > > > > now best.qb.ever is "Ben Roethlisberger". I see this works now - is > > this indended (I'm assuming is must be)? Am I safe in relying on > > maven to stay this way? > > > > One more general question. The reason I'm asking is because I'd like > > to do the following. Maybe this is way off base and there's a better > > way: > > > > command > > -- > > maven -Denv=qa jar:jar > > > > maven.xml > > > > > > > > > > > > ... > > > > project.properties > > - > > maven.src.dir=${basepath}/src/java > > > > project.xml > > - > > ... > > > > > > this is bogus and will never be used > > > > > > Does this make sense? I think this is the best way to be able to flip > > things like maven.src.dir by specifying an environment on the command > > line. > > > > One more.. I can't find the property that equates to this tag > > . I checked here: > > http://maven.apache.org/reference/plugins/test/properties.html > > and here: > > http://maven.apache.org/reference/user-guide.html#Behavioural_Properties > > am I just blind or is it not listed? > > > > Thanks, > > Ben > > > > > > > > > > On Fri, 19 Nov 2004 09:01:48 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > > > > 1) Can I embed jelly in my build.properties files? > > > > > > The answer to the question you were trying to ask is yes, but to this > > > specific one, no. Jelly is the XML scripting, JEXL is the expression > > > language used in Jelly. You can use an expression in build.properties, > > > but not embed Jelly - just in case you wanted to start doing > > > conditionals :) > > > > > > eg, > > > somedir=${basedir}/src > > > otherdir=${maven.build.dir}/other > > > > > > > 2) Is there a goal that occurs before maven loads the properties > > > > file. So I could write a > > > > ... > > > > ... > > > > some.arbitrary.property=qaValue > > > > ... > > > > some.arbitrary.property=prodValue > > > > > > No, but the first is nicer and works. > > > > > > - Brett > > > > > > > > > > > Thanks, > > > > Ben > > > > > > > > - > > > > 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]
Re: do something before *.properties files load
Can I suggest that you just use project.xml from your local copy or the VSS shadow directory respectively? Does this pose some particular limitation? I do something similar in some cases - having a clean CVS checkout and an in progress checkout. - Brett On Fri, 19 Nov 2004 08:37:55 -0500, Ben Anderson <[EMAIL PROTECTED]> wrote: > I want to be able to build the source using either my local working > directory which I have modified, or vss's shadow directory which > contains only checked in files. Same goes for unit tests. > > > > > On Sat, 20 Nov 2004 00:26:28 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > > Hi Ben, > > > > Yes, you can expect that behaviour to remain the same. > > > > maven.src.dir is not what you think it is. You would need to modify > > pom.build.sourceDirectory, but this is not recommended. > > > > Why are you changing sources in different environments? Perhaps you > > want s? > > > > - Brett > > > > > > > > > > On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson > > <[EMAIL PROTECTED]> wrote: > > > Thanks Brett. I ran some tests specifying expressions in the > > > project.properties file. It's pretty neat how the properties retain a > > > reference of some kind instead of resolving at the initial assignment. > > > For instance: > > > > > > qb.name=Tommy Maddox > > > best.qb.ever=${qb.name} > > > qb.name=Ben Roethlisberger > > > > > > now best.qb.ever is "Ben Roethlisberger". I see this works now - is > > > this indended (I'm assuming is must be)? Am I safe in relying on > > > maven to stay this way? > > > > > > One more general question. The reason I'm asking is because I'd like > > > to do the following. Maybe this is way off base and there's a better > > > way: > > > > > > command > > > -- > > > maven -Denv=qa jar:jar > > > > > > maven.xml > > > > > > > > > > > > > > > > > > ... > > > > > > project.properties > > > - > > > maven.src.dir=${basepath}/src/java > > > > > > project.xml > > > - > > > ... > > > > > > > > > this is bogus and will never be used > > > > > > > > > Does this make sense? I think this is the best way to be able to flip > > > things like maven.src.dir by specifying an environment on the command > > > line. > > > > > > One more.. I can't find the property that equates to this tag > > > . I checked here: > > > http://maven.apache.org/reference/plugins/test/properties.html > > > and here: > > > http://maven.apache.org/reference/user-guide.html#Behavioural_Properties > > > am I just blind or is it not listed? > > > > > > Thanks, > > > Ben > > > > > > > > > > > > > > > On Fri, 19 Nov 2004 09:01:48 +1100, Brett Porter <[EMAIL PROTECTED]> > > > wrote: > > > > > 1) Can I embed jelly in my build.properties files? > > > > > > > > The answer to the question you were trying to ask is yes, but to this > > > > specific one, no. Jelly is the XML scripting, JEXL is the expression > > > > language used in Jelly. You can use an expression in build.properties, > > > > but not embed Jelly - just in case you wanted to start doing > > > > conditionals :) > > > > > > > > eg, > > > > somedir=${basedir}/src > > > > otherdir=${maven.build.dir}/other > > > > > > > > > 2) Is there a goal that occurs before maven loads the properties > > > > > file. So I could write a > > > > > ... > > > > > ... > > > > > some.arbitrary.property=qaValue > > > > > ... > > > > > some.arbitrary.property=prodValue > > > > > > > > No, but the first is nicer and works. > > > > > > > > - Brett > > > > > > > > > > > > > > Thanks, > > > > > Ben > > > > > > > > > > - > > > > > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: do something before *.properties files load
Yeah, you're probably right. We should just use maven's inheritance to sort this stuff out. But this is still throwing me a little. I want to be able to create artifacts for various environments w/out changing any files, whether it's renaming or whatever. Does this mean I would have to create a subdirectory for each different environment? It would be nice if maven allowed inheritance (which is one of the many things that makes maven cool) using some other techniqure than the file structure. For instance, I've already created 2 sub directories (war and ear) for the same project. To create the ear, I first cd to the war directory and do a war:install. Then I have to cd to the ear directory and create my ear. The only reason the ear directory exists is so that I can specify a dependency on my war artifact (creating a new project.xml which inherits from the upper project.xml). I know I can use the reactor here, which would eliminate some of the "cd"'ing. Back from my tangent... so, in order to do different environmetns, I'd specify separate sub directories for each and override accordingly? Does that make more sense? It's a little different than what I think you suggested, but like I said, I don't want to have to change files (project.xml, build.properties, etc.) for each different environment. Thanks, Ben On Sat, 20 Nov 2004 00:43:31 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > Can I suggest that you just use project.xml from your local copy or > the VSS shadow directory respectively? Does this pose some particular > limitation? > > I do something similar in some cases - having a clean CVS checkout and > an in progress checkout. > > - Brett > > On Fri, 19 Nov 2004 08:37:55 -0500, Ben Anderson > > > <[EMAIL PROTECTED]> wrote: > > I want to be able to build the source using either my local working > > directory which I have modified, or vss's shadow directory which > > contains only checked in files. Same goes for unit tests. > > > > > > > > > > On Sat, 20 Nov 2004 00:26:28 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > > > Hi Ben, > > > > > > Yes, you can expect that behaviour to remain the same. > > > > > > maven.src.dir is not what you think it is. You would need to modify > > > pom.build.sourceDirectory, but this is not recommended. > > > > > > Why are you changing sources in different environments? Perhaps you > > > want s? > > > > > > - Brett > > > > > > > > > > > > > > > On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson > > > <[EMAIL PROTECTED]> wrote: > > > > Thanks Brett. I ran some tests specifying expressions in the > > > > project.properties file. It's pretty neat how the properties retain a > > > > reference of some kind instead of resolving at the initial assignment. > > > > For instance: > > > > > > > > qb.name=Tommy Maddox > > > > best.qb.ever=${qb.name} > > > > qb.name=Ben Roethlisberger > > > > > > > > now best.qb.ever is "Ben Roethlisberger". I see this works now - is > > > > this indended (I'm assuming is must be)? Am I safe in relying on > > > > maven to stay this way? > > > > > > > > One more general question. The reason I'm asking is because I'd like > > > > to do the following. Maybe this is way off base and there's a better > > > > way: > > > > > > > > command > > > > -- > > > > maven -Denv=qa jar:jar > > > > > > > > maven.xml > > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > project.properties > > > > - > > > > maven.src.dir=${basepath}/src/java > > > > > > > > project.xml > > > > - > > > > ... > > > > > > > > > > > > this is bogus and will never be used > > > > > > > > > > > > Does this make sense? I think this is the best way to be able to flip > > > > things like maven.src.dir by specifying an environment on the command > > > > line. > > > > > > > > One more.. I can't find the property that equates to this tag > > > > . I checked here: > > > > http://maven.apache.org/reference/plugins/test/properties.html > > > > and here: > > > > http://maven.apache.org/reference/user-guide.html#Behavioural_Properties > > > > am I just blind or is it not listed? > > > > > > > > Thanks, > > > > Ben > > > > > > > > > > > > > > > > > > > > On Fri, 19 Nov 2004 09:01:48 +1100, Brett Porter <[EMAIL PROTECTED]> > > > > wrote: > > > > > > 1) Can I embed jelly in my build.properties files? > > > > > > > > > > The answer to the question you were trying to ask is yes, but to this > > > > > specific one, no. Jelly is the XML scripting, JEXL is the expression > > > > > language used in Jelly. You can use an expression in build.properties, > > > > > but not embed Jelly - just in case you wanted to start doing > > > > > conditionals :) > > > > > > > > > > eg, > > > > > somedir=${basedir}/src > > > > > otherdir=${maven.build.dir}/other > > > > > > > > > > > 2) Is there a goal that occurs before maven loads the properties > > > > > > file.
RE: do something before *.properties files load
I think that environment specifical things can be set in the build.properties file. I am using one build.properties file for each environment. For instance, for Windows I have one build.properties in my home, for unix a slightly different one in my unix home. For nightly build we have a different unix user, which has a special build.properties file in home. If I work with several environment on the same machine, I simply switch the build.properties file in my home. I hope this helps. Greetings Pierre -Original Message- From: Ben Anderson [mailto:[EMAIL PROTECTED] Sent: Freitag, 19. November 2004 15:52 To: Maven Users List Subject: Re: do something before *.properties files load Yeah, you're probably right. We should just use maven's inheritance to sort this stuff out. But this is still throwing me a little. I want to be able to create artifacts for various environments w/out changing any files, whether it's renaming or whatever. Does this mean I would have to create a subdirectory for each different environment? It would be nice if maven allowed inheritance (which is one of the many things that makes maven cool) using some other techniqure than the file structure. For instance, I've already created 2 sub directories (war and ear) for the same project. To create the ear, I first cd to the war directory and do a war:install. Then I have to cd to the ear directory and create my ear. The only reason the ear directory exists is so that I can specify a dependency on my war artifact (creating a new project.xml which inherits from the upper project.xml). I know I can use the reactor here, which would eliminate some of the "cd"'ing. Back from my tangent... so, in order to do different environmetns, I'd specify separate sub directories for each and override accordingly? Does that make more sense? It's a little different than what I think you suggested, but like I said, I don't want to have to change files (project.xml, build.properties, etc.) for each different environment. Thanks, Ben On Sat, 20 Nov 2004 00:43:31 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > Can I suggest that you just use project.xml from your local copy or > the VSS shadow directory respectively? Does this pose some particular > limitation? > > I do something similar in some cases - having a clean CVS checkout and > an in progress checkout. > > - Brett > > On Fri, 19 Nov 2004 08:37:55 -0500, Ben Anderson > > > <[EMAIL PROTECTED]> wrote: > > I want to be able to build the source using either my local working > > directory which I have modified, or vss's shadow directory which > > contains only checked in files. Same goes for unit tests. > > > > > > > > > > On Sat, 20 Nov 2004 00:26:28 +1100, Brett Porter <[EMAIL PROTECTED]> wrote: > > > Hi Ben, > > > > > > Yes, you can expect that behaviour to remain the same. > > > > > > maven.src.dir is not what you think it is. You would need to modify > > > pom.build.sourceDirectory, but this is not recommended. > > > > > > Why are you changing sources in different environments? Perhaps you > > > want s? > > > > > > - Brett > > > > > > > > > > > > > > > On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson > > > <[EMAIL PROTECTED]> wrote: > > > > Thanks Brett. I ran some tests specifying expressions in the > > > > project.properties file. It's pretty neat how the properties retain a > > > > reference of some kind instead of resolving at the initial assignment. > > > > For instance: > > > > > > > > qb.name=Tommy Maddox > > > > best.qb.ever=${qb.name} > > > > qb.name=Ben Roethlisberger > > > > > > > > now best.qb.ever is "Ben Roethlisberger". I see this works now - is > > > > this indended (I'm assuming is must be)? Am I safe in relying on > > > > maven to stay this way? > > > > > > > > One more general question. The reason I'm asking is because I'd like > > > > to do the following. Maybe this is way off base and there's a better > > > > way: > > > > > > > > command > > > > -- > > > > maven -Denv=qa jar:jar > > > > > > > > maven.xml > > > > > > > > > > > > > > > > > > > > > > > > ... > > > > > > > > project.properties > > > > - >
Re: do something before *.properties files load
yes, I understand that. But what if I don't want to swap build.properties files for each environment? I want to the same user, w/out making them manually change build.properties, to be able to build for various environments from the same machine. On Fri, 19 Nov 2004 16:11:13 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I think that environment specifical things can be set in the > build.properties file. > I am using one build.properties file for each environment. For instance, > for Windows I have one build.properties in my home, for unix a slightly > different one in my unix home. For nightly build we have a > different unix user, which has a special build.properties file in home. > If I work with several environment on the same machine, I simply switch > the build.properties file in my home. > I hope this helps. > > Greetings > Pierre > > > > -Original Message- > From: Ben Anderson [mailto:[EMAIL PROTECTED] > Sent: Freitag, 19. November 2004 15:52 > To: Maven Users List > Subject: Re: do something before *.properties files load > > Yeah, you're probably right. We should just use maven's inheritance > to sort this stuff out. But this is still throwing me a little. I > want to be able to create artifacts for various environments w/out > changing any files, whether it's renaming or whatever. Does this mean > I would have to create a subdirectory for each different environment? > It would be nice if maven allowed inheritance (which is one of the > many things that makes maven cool) using some other techniqure than > the file structure. For instance, I've already created 2 sub > directories (war and ear) for the same project. To create the ear, I > first cd to the war directory and do a war:install. Then I have to cd > to the ear directory and create my ear. The only reason the ear > directory exists is so that I can specify a dependency on my war > artifact (creating a new project.xml which inherits from the upper > project.xml). I know I can use the reactor here, which would > eliminate some of the "cd"'ing. Back from my tangent... so, in order > to do different environmetns, I'd specify separate sub directories for > each and override accordingly? Does that make more sense? It's a > little different than what I think you suggested, but like I said, I > don't want to have to change files (project.xml, build.properties, > etc.) for each different environment. > Thanks, > Ben > > On Sat, 20 Nov 2004 00:43:31 +1100, Brett Porter > <[EMAIL PROTECTED]> wrote: > > Can I suggest that you just use project.xml from your local copy or > > the VSS shadow directory respectively? Does this pose some particular > > limitation? > > > > I do something similar in some cases - having a clean CVS checkout and > > an in progress checkout. > > > > - Brett > > > > On Fri, 19 Nov 2004 08:37:55 -0500, Ben Anderson > > > > > > <[EMAIL PROTECTED]> wrote: > > > I want to be able to build the source using either my local working > > > directory which I have modified, or vss's shadow directory which > > > contains only checked in files. Same goes for unit tests. > > > > > > > > > > > > > > > On Sat, 20 Nov 2004 00:26:28 +1100, Brett Porter > <[EMAIL PROTECTED]> wrote: > > > > Hi Ben, > > > > > > > > Yes, you can expect that behaviour to remain the same. > > > > > > > > maven.src.dir is not what you think it is. You would need to > modify > > > > pom.build.sourceDirectory, but this is not recommended. > > > > > > > > Why are you changing sources in different environments? Perhaps > you > > > > want s? > > > > > > > > - Brett > > > > > > > > > > > > > > > > > > > > On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson > > > > <[EMAIL PROTECTED]> wrote: > > > > > Thanks Brett. I ran some tests specifying expressions in the > > > > > project.properties file. It's pretty neat how the properties > retain a > > > > > reference of some kind instead of resolving at the initial > assignment. > > > > > For instance: > > > > > > > > > > qb.name=Tommy Maddox > > > > > best.qb.ever=${qb.name} > > > > > qb.name=Ben Roethlisberger > > > > > > > > > > now best.qb.ever is "Ben Roethlisberger". I see this works now > - is > > > > > this indended (I
RE: do something before *.properties files load
I am coming to a similar problem as you, Ben. I can see two possible solutions, I've yet to decide which fits our setup the best. The first solution is to use Ant's property replacement task. For example, let's say your environment specific properties are in your web.xml file. You'd create a generic web_template.xml file with all the environment specific information written in the form of: ${env.specific.property}. Then, you'll create a .properties file for each of your environments, (dev.properties) which will contain your environment specific properties for development. Then create a preGoal for war:war (maybe something else), and use the ant properties replacement task ( I believe) to get those values into the newly generated web.xml. Then use this new web.xml will be used in the newly generated war file. You'll have to create some switch that can be used on the command line, or maybe even some project level goals in your maven.xml files that will generate what you need (think of something like "build-dev" to create in your top most maven.xml file). Another solution would be to create a separate web.xml for each environment, web_dev.xml for example. Then in your preGoal for war:war, you could switch on a property specified on the command line, and copy the selected xml file to web.xml. Then the newly generated war file will contain the right web.xml. Personally, I like the first solution a bit better. In a way, it makes you declare what the environment specific properties are, and you must provide a value for them to work. It also allows you to replace properties into different types of files, like source code. I've used this approach for some of my Xdoclet code. I'll set some Xdoclet values to be like "${env.property}", let Xdoclet generate other files, then run my properties file through, replacing what needs to be replaced. It seems to work pretty well, I find that many of my properties are really quite common, and as a result, I only have to change the property in one place to affect a change in my whole build. Obviously, it makes yet another step to get from code to build, and maybe it's a bit difficult to explain to another developer. But you document your build process perfectly anyway, right? ;) Hope that helps. Troy -Original Message- From: Ben Anderson [mailto:[EMAIL PROTECTED] Sent: Friday, November 19, 2004 10:44 AM To: Maven Users List Subject: Re: do something before *.properties files load yes, I understand that. But what if I don't want to swap build.properties files for each environment? I want to the same user, w/out making them manually change build.properties, to be able to build for various environments from the same machine. On Fri, 19 Nov 2004 16:11:13 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I think that environment specifical things can be set in the > build.properties file. I am using one build.properties file for each > environment. For instance, for Windows I have one build.properties in > my home, for unix a slightly different one in my unix home. For > nightly build we have a different unix user, which has a special > build.properties file in home. If I work with several environment on > the same machine, I simply switch the build.properties file in my > home. I hope this helps. > > Greetings > Pierre > > > > -Original Message- > From: Ben Anderson [mailto:[EMAIL PROTECTED] > Sent: Freitag, 19. November 2004 15:52 > To: Maven Users List > Subject: Re: do something before *.properties files load > > Yeah, you're probably right. We should just use maven's inheritance > to sort this stuff out. But this is still throwing me a little. I > want to be able to create artifacts for various environments w/out > changing any files, whether it's renaming or whatever. Does this mean > I would have to create a subdirectory for each different environment? > It would be nice if maven allowed inheritance (which is one of the > many things that makes maven cool) using some other techniqure than > the file structure. For instance, I've already created 2 sub > directories (war and ear) for the same project. To create the ear, I > first cd to the war directory and do a war:install. Then I have to cd > to the ear directory and create my ear. The only reason the ear > directory exists is so that I can specify a dependency on my war > artifact (creating a new project.xml which inherits from the upper > project.xml). I know I can use the reactor here, which would > eliminate some of the "cd"'ing. Back from my tangent... so, in order > to do different environmetns, I'd specify separate sub directories for > each and override accordingly? Does that make more sense? It
RE: do something before *.properties files load
The first solution can also be done with the following ant snippet: (I found it in my build.xml script.) T -Original Message- From: Poppe, Troy [mailto:[EMAIL PROTECTED] Sent: Friday, November 19, 2004 11:03 AM To: 'Maven Users List'; 'Ben Anderson' Subject: RE: do something before *.properties files load I am coming to a similar problem as you, Ben. I can see two possible solutions, I've yet to decide which fits our setup the best. The first solution is to use Ant's property replacement task. For example, let's say your environment specific properties are in your web.xml file. You'd create a generic web_template.xml file with all the environment specific information written in the form of: ${env.specific.property}. Then, you'll create a .properties file for each of your environments, (dev.properties) which will contain your environment specific properties for development. Then create a preGoal for war:war (maybe something else), and use the ant properties replacement task ( I believe) to get those values into the newly generated web.xml. Then use this new web.xml will be used in the newly generated war file. You'll have to create some switch that can be used on the command line, or maybe even some project level goals in your maven.xml files that will generate what you need (think of something like "build-dev" to create in your top most maven.xml file). Another solution would be to create a separate web.xml for each environment, web_dev.xml for example. Then in your preGoal for war:war, you could switch on a property specified on the command line, and copy the selected xml file to web.xml. Then the newly generated war file will contain the right web.xml. Personally, I like the first solution a bit better. In a way, it makes you declare what the environment specific properties are, and you must provide a value for them to work. It also allows you to replace properties into different types of files, like source code. I've used this approach for some of my Xdoclet code. I'll set some Xdoclet values to be like "${env.property}", let Xdoclet generate other files, then run my properties file through, replacing what needs to be replaced. It seems to work pretty well, I find that many of my properties are really quite common, and as a result, I only have to change the property in one place to affect a change in my whole build. Obviously, it makes yet another step to get from code to build, and maybe it's a bit difficult to explain to another developer. But you document your build process perfectly anyway, right? ;) Hope that helps. Troy -Original Message- From: Ben Anderson [mailto:[EMAIL PROTECTED] Sent: Friday, November 19, 2004 10:44 AM To: Maven Users List Subject: Re: do something before *.properties files load yes, I understand that. But what if I don't want to swap build.properties files for each environment? I want to the same user, w/out making them manually change build.properties, to be able to build for various environments from the same machine. On Fri, 19 Nov 2004 16:11:13 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I think that environment specifical things can be set in the > build.properties file. I am using one build.properties file for each > environment. For instance, for Windows I have one build.properties in > my home, for unix a slightly different one in my unix home. For > nightly build we have a different unix user, which has a special > build.properties file in home. If I work with several environment on > the same machine, I simply switch the build.properties file in my > home. I hope this helps. > > Greetings > Pierre > > > > -Original Message----- > From: Ben Anderson [mailto:[EMAIL PROTECTED] > Sent: Freitag, 19. November 2004 15:52 > To: Maven Users List > Subject: Re: do something before *.properties files load > > Yeah, you're probably right. We should just use maven's inheritance > to sort this stuff out. But this is still throwing me a little. I > want to be able to create artifacts for various environments w/out > changing any files, whether it's renaming or whatever. Does this mean > I would have to create a subdirectory for each different environment? > It would be nice if maven allowed inheritance (which is one of the > many things that makes maven cool) using some other techniqure than > the file structure. For instance, I've already created 2 sub > directories (war and ear) for the same project. To create the ear, I > first cd to the war directory and do a war:install. Then I have to cd > to the ear directory and create my ear. The only reason the ear > directory exists is so that I can specify a dependency on my war >
Re: do something before *.properties files load
Neither of those will work, because I want to dynamically change these: ${basepath}/src/java ${basepath}/src/test ... The properties file that specifices ${basepath} must be set before the maven.xml is parsed. On Fri, 19 Nov 2004 11:02:55 -0500, Poppe, Troy <[EMAIL PROTECTED]> wrote: > > I am coming to a similar problem as you, Ben. I can see two possible > solutions, > I've yet to decide which fits our setup the best. > > The first solution is to use Ant's property replacement task. For example, > let's > say your environment specific properties are in your web.xml file. You'd > create > a generic web_template.xml file with all the environment specific information > written in the form of: ${env.specific.property}. Then, you'll create a > .properties file for each of your environments, (dev.properties) which will > contain your environment specific properties for development. Then create a > preGoal for war:war (maybe something else), and use the ant properties > replacement task ( I believe) to get those values into the newly > generated web.xml. Then use this new web.xml will be used in the newly > generated > war file. You'll have to create some switch that can be used on the command > line, or maybe even some project level goals in your maven.xml files that will > generate what you need (think of something like "build-dev" to create in your > top > most maven.xml file). > > Another solution would be to create a separate web.xml for each environment, > web_dev.xml for example. Then in your preGoal for war:war, you could switch > on a > property specified on the command line, and copy the selected xml file to > web.xml. Then the newly generated war file will contain the right web.xml. > > Personally, I like the first solution a bit better. In a way, it makes you > declare what the environment specific properties are, and you must provide a > value for them to work. It also allows you to replace properties into > different > types of files, like source code. > > I've used this approach for some of my Xdoclet code. I'll set some Xdoclet > values to be like "${env.property}", let Xdoclet generate other files, then > run > my properties file through, replacing what needs to be replaced. It seems to > work pretty well, I find that many of my properties are really quite common, > and > as a result, I only have to change the property in one place to affect a > change > in my whole build. > > Obviously, it makes yet another step to get from code to build, and maybe > it's a > bit difficult to explain to another developer. But you document your build > process perfectly anyway, right? ;) > > Hope that helps. > > Troy > > > > > -Original Message- > From: Ben Anderson [mailto:[EMAIL PROTECTED] > Sent: Friday, November 19, 2004 10:44 AM > To: Maven Users List > Subject: Re: do something before *.properties files load > > yes, I understand that. But what if I don't want to swap build.properties > files > for each environment? I want to the same user, w/out making them manually > change > build.properties, to be able to build for various environments from the same > machine. > > On Fri, 19 Nov 2004 16:11:13 +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> > wrote: > > I think that environment specifical things can be set in the > > build.properties file. I am using one build.properties file for each > > environment. For instance, for Windows I have one build.properties in > > my home, for unix a slightly different one in my unix home. For > > nightly build we have a different unix user, which has a special > > build.properties file in home. If I work with several environment on > > the same machine, I simply switch the build.properties file in my > > home. I hope this helps. > > > > Greetings > > Pierre > > > > > > > > -Original Message- > > From: Ben Anderson [mailto:[EMAIL PROTECTED] > > Sent: Freitag, 19. November 2004 15:52 > > To: Maven Users List > > Subject: Re: do something before *.properties files load > > > > Yeah, you're probably right. We should just use maven's inheritance > > to sort this stuff out. But this is still throwing me a little. I > > want to be able to create artifacts for various environments w/out > > changing any files, whether it's renaming or whatever. Does this mean > > I would have to create a subdirectory for each different environment? > > It would be nice if maven allowed inheritance (which is one of the > > many things that makes maven cool) us
RE: do something before *.properties files load
So you deploy different code to different environments? T -Original Message- From: Ben Anderson [mailto:[EMAIL PROTECTED] Sent: Friday, November 19, 2004 11:29 AM To: Maven Users List Subject: Re: do something before *.properties files load Neither of those will work, because I want to dynamically change these: ${basepath}/src/java ${basepath}/src/test ... The properties file that specifices ${basepath} must be set before the maven.xml is parsed. On Fri, 19 Nov 2004 11:02:55 -0500, Poppe, Troy <[EMAIL PROTECTED]> wrote: > > I am coming to a similar problem as you, Ben. I can see two possible > solutions, I've yet to decide which fits our setup the best. > > The first solution is to use Ant's property replacement task. For > example, let's say your environment specific properties are in your > web.xml file. You'd create a generic web_template.xml file with all > the environment specific information written in the form of: > ${env.specific.property}. Then, you'll create a .properties file for > each of your environments, (dev.properties) which will contain your > environment specific properties for development. Then create a > preGoal for war:war (maybe something else), and use the ant properties > replacement task ( I believe) to get those values into the > newly generated web.xml. Then use this new web.xml will be used in > the newly generated war file. You'll have to create some switch that > can be used on the command line, or maybe even some project level > goals in your maven.xml files that will generate what you need (think > of something like "build-dev" to create in your top most maven.xml > file). > > Another solution would be to create a separate web.xml for each > environment, web_dev.xml for example. Then in your preGoal for > war:war, you could switch on a property specified on the command line, > and copy the selected xml file to web.xml. Then the newly generated > war file will contain the right web.xml. > > Personally, I like the first solution a bit better. In a way, it > makes you declare what the environment specific properties are, and > you must provide a value for them to work. It also allows you to > replace properties into different types of files, like source code. > > I've used this approach for some of my Xdoclet code. I'll set some > Xdoclet values to be like "${env.property}", let Xdoclet generate > other files, then run my properties file through, replacing what needs > to be replaced. It seems to work pretty well, I find that many of my > properties are really quite common, and as a result, I only have to > change the property in one place to affect a change in my whole build. > > Obviously, it makes yet another step to get from code to build, and > maybe it's a bit difficult to explain to another developer. But you > document your build process perfectly anyway, right? ;) > > Hope that helps. > > Troy > > > > > -Original Message- > From: Ben Anderson [mailto:[EMAIL PROTECTED] > Sent: Friday, November 19, 2004 10:44 AM > To: Maven Users List > Subject: Re: do something before *.properties files load > > yes, I understand that. But what if I don't want to swap > build.properties files for each environment? I want to the same user, > w/out making them manually change build.properties, to be able to > build for various environments from the same machine. > > On Fri, 19 Nov 2004 16:11:13 +0100, [EMAIL PROTECTED] > <[EMAIL PROTECTED]> > wrote: > > I think that environment specifical things can be set in the > > build.properties file. I am using one build.properties file for each > > environment. For instance, for Windows I have one build.properties > > in my home, for unix a slightly different one in my unix home. For > > nightly build we have a different unix user, which has a special > > build.properties file in home. If I work with several environment on > > the same machine, I simply switch the build.properties file in my > > home. I hope this helps. > > > > Greetings > > Pierre > > > > > > > > -Original Message- > > From: Ben Anderson [mailto:[EMAIL PROTECTED] > > Sent: Freitag, 19. November 2004 15:52 > > To: Maven Users List > > Subject: Re: do something before *.properties files load > > > > Yeah, you're probably right. We should just use maven's inheritance > > to sort this stuff out. But this is still throwing me a little. I > > want to be able to create artifacts for various environments w/out > > changing any files, whether it's rena
Fwd: do something before *.properties files load
-- Forwarded message -- From: Ben Anderson <[EMAIL PROTECTED]> Date: Fri, 19 Nov 2004 11:43:26 -0500 Subject: Re: do something before *.properties files load To: "Poppe, Troy" <[EMAIL PROTECTED]> Yes, same code essentially, except that one directory is a users working directory and one is from the SCM repository. On Fri, 19 Nov 2004 11:30:37 -0500, Poppe, Troy <[EMAIL PROTECTED]> wrote: > > So you deploy different code to different environments? > > T > > > > -Original Message- > From: Ben Anderson [mailto:[EMAIL PROTECTED] > Sent: Friday, November 19, 2004 11:29 AM > To: Maven Users List > Subject: Re: do something before *.properties files load > > Neither of those will work, because I want to dynamically change these: > > ${basepath}/src/java > ${basepath}/src/test > ... > The properties file that specifices ${basepath} must be set before the > maven.xml > is parsed. > > On Fri, 19 Nov 2004 11:02:55 -0500, Poppe, Troy <[EMAIL PROTECTED]> wrote: > > > > I am coming to a similar problem as you, Ben. I can see two possible > > solutions, I've yet to decide which fits our setup the best. > > > > The first solution is to use Ant's property replacement task. For > > example, let's say your environment specific properties are in your > > web.xml file. You'd create a generic web_template.xml file with all > > the environment specific information written in the form of: > > ${env.specific.property}. Then, you'll create a .properties file for > > each of your environments, (dev.properties) which will contain your > > environment specific properties for development. Then create a > > preGoal for war:war (maybe something else), and use the ant properties > > replacement task ( I believe) to get those values into the > > newly generated web.xml. Then use this new web.xml will be used in > > the newly generated war file. You'll have to create some switch that > > can be used on the command line, or maybe even some project level > > goals in your maven.xml files that will generate what you need (think > > of something like "build-dev" to create in your top most maven.xml > > file). > > > > Another solution would be to create a separate web.xml for each > > environment, web_dev.xml for example. Then in your preGoal for > > war:war, you could switch on a property specified on the command line, > > and copy the selected xml file to web.xml. Then the newly generated > > war file will contain the right web.xml. > > > > Personally, I like the first solution a bit better. In a way, it > > makes you declare what the environment specific properties are, and > > you must provide a value for them to work. It also allows you to > > replace properties into different types of files, like source code. > > > > I've used this approach for some of my Xdoclet code. I'll set some > > Xdoclet values to be like "${env.property}", let Xdoclet generate > > other files, then run my properties file through, replacing what needs > > to be replaced. It seems to work pretty well, I find that many of my > > properties are really quite common, and as a result, I only have to > > change the property in one place to affect a change in my whole build. > > > > Obviously, it makes yet another step to get from code to build, and > > maybe it's a bit difficult to explain to another developer. But you > > document your build process perfectly anyway, right? ;) > > > > Hope that helps. > > > > Troy > > > > > > > > > > -Original Message- > > From: Ben Anderson [mailto:[EMAIL PROTECTED] > > Sent: Friday, November 19, 2004 10:44 AM > > To: Maven Users List > > Subject: Re: do something before *.properties files load > > > > yes, I understand that. But what if I don't want to swap > > build.properties files for each environment? I want to the same user, > > w/out making them manually change build.properties, to be able to > > build for various environments from the same machine. > > > > On Fri, 19 Nov 2004 16:11:13 +0100, [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> > > wrote: > > > I think that environment specifical things can be set in the > > > build.properties file. I am using one build.properties file for each > > > environment. For instance, for Windows I have one build.properties > > > in my home, for unix a slightly different one in my unix home. For > > > nightly build we have a different unix use
RE: do something before *.properties files load
Would it be possible to use something like this in the POM: ./opt/${myenvironmenttype}/project.xml So depending on the property you specify you can inherit from ./opt/dev/project.xml or ./opt/prod/project.xml, and their respective *.properties. The dev and prod folder only contains maven files. The opt folder should prevent the multiproject plug-in to go through these folders. Just an idea, let me know if this make sense. > -Original Message- > From: Ben Anderson [mailto:[EMAIL PROTECTED] > Sent: Friday, November 19, 2004 11:44 AM > To: Maven Users List > Subject: Fwd: do something before *.properties files load > > -- Forwarded message -- > From: Ben Anderson <[EMAIL PROTECTED]> > Date: Fri, 19 Nov 2004 11:43:26 -0500 > Subject: Re: do something before *.properties files load > To: "Poppe, Troy" <[EMAIL PROTECTED]> > > > Yes, same code essentially, except that one directory is a users > working directory and one is from the SCM repository. > > > > > On Fri, 19 Nov 2004 11:30:37 -0500, Poppe, Troy <[EMAIL PROTECTED]> > wrote: > > > > So you deploy different code to different environments? > > > > T > > > > > > > > -Original Message----- > > From: Ben Anderson [mailto:[EMAIL PROTECTED] > > Sent: Friday, November 19, 2004 11:29 AM > > To: Maven Users List > > Subject: Re: do something before *.properties files load > > > > Neither of those will work, because I want to dynamically change these: > > > > ${basepath}/src/java > > ${basepath}/src/test > > ... > > The properties file that specifices ${basepath} must be set before the > maven.xml > > is parsed. > > > > On Fri, 19 Nov 2004 11:02:55 -0500, Poppe, Troy <[EMAIL PROTECTED]> > wrote: > > > > > > I am coming to a similar problem as you, Ben. I can see two possible > > > solutions, I've yet to decide which fits our setup the best. > > > > > > The first solution is to use Ant's property replacement task. For > > > example, let's say your environment specific properties are in your > > > web.xml file. You'd create a generic web_template.xml file with all > > > the environment specific information written in the form of: > > > ${env.specific.property}. Then, you'll create a .properties file for > > > each of your environments, (dev.properties) which will contain your > > > environment specific properties for development. Then create a > > > preGoal for war:war (maybe something else), and use the ant properties > > > replacement task ( I believe) to get those values into the > > > newly generated web.xml. Then use this new web.xml will be used in > > > the newly generated war file. You'll have to create some switch that > > > can be used on the command line, or maybe even some project level > > > goals in your maven.xml files that will generate what you need (think > > > of something like "build-dev" to create in your top most maven.xml > > > file). > > > > > > Another solution would be to create a separate web.xml for each > > > environment, web_dev.xml for example. Then in your preGoal for > > > war:war, you could switch on a property specified on the command line, > > > and copy the selected xml file to web.xml. Then the newly generated > > > war file will contain the right web.xml. > > > > > > Personally, I like the first solution a bit better. In a way, it > > > makes you declare what the environment specific properties are, and > > > you must provide a value for them to work. It also allows you to > > > replace properties into different types of files, like source code. > > > > > > I've used this approach for some of my Xdoclet code. I'll set some > > > Xdoclet values to be like "${env.property}", let Xdoclet generate > > > other files, then run my properties file through, replacing what needs > > > to be replaced. It seems to work pretty well, I find that many of my > > > properties are really quite common, and as a result, I only have to > > > change the property in one place to affect a change in my whole build. > > > > > > Obviously, it makes yet another step to get from code to build, and > > > maybe it's a bit difficult to explain to another developer. But you > > > document your build process perfectly anyway, right? ;) > > > > > > Hope that helps. > > > > > > Troy > > > > > >
RE: do something before *.properties files load
I think that we might have missed the primary issue here There are two properties with the same name in the properties file. In regards to the statement "Yes, you can expect that behavior to remain the same", I suspect that this was in terms of one property being able to have an expression of another property. I personally doubt that it was in regard to the load behavior of the property file, in terms of whether "qb.name" gets assigned the value of "Tommy Maddox" or of "Ben Roethlisberger". In any case, "best.qb.ever" will be assigned the final value of "qb.name". -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, November 19, 2004 8:26 AM To: Maven Users List; Ben Anderson Subject: Re: do something before *.properties files load Hi Ben, Yes, you can expect that behaviour to remain the same. maven.src.dir is not what you think it is. You would need to modify pom.build.sourceDirectory, but this is not recommended. Why are you changing sources in different environments? Perhaps you want s? - Brett On Fri, 19 Nov 2004 08:15:27 -0500, Ben Anderson <[EMAIL PROTECTED]> wrote: > Thanks Brett. I ran some tests specifying expressions in the > project.properties file. It's pretty neat how the properties retain a > reference of some kind instead of resolving at the initial assignment. > For instance: > > qb.name=Tommy Maddox > best.qb.ever=${qb.name} > qb.name=Ben Roethlisberger > > now best.qb.ever is "Ben Roethlisberger". I see this works now - is > this indended (I'm assuming is must be)? Am I safe in relying on > maven to stay this way? > > One more general question. The reason I'm asking is because I'd like > to do the following. Maybe this is way off base and there's a better > way: > > command > -- > maven -Denv=qa jar:jar > > maven.xml > > > > > > ... > > project.properties > - > maven.src.dir=${basepath}/src/java > > project.xml > - > ... > > > this is bogus and will never be used > > > Does this make sense? I think this is the best way to be able to flip > things like maven.src.dir by specifying an environment on the command > line. > > One more.. I can't find the property that equates to this tag > . I checked here: > http://maven.apache.org/reference/plugins/test/properties.html > and here: > http://maven.apache.org/reference/user-guide.html#Behavioural_Properti > es > am I just blind or is it not listed? > > Thanks, > Ben > > > > > On Fri, 19 Nov 2004 09:01:48 +1100, Brett Porter > <[EMAIL PROTECTED]> wrote: > > > 1) Can I embed jelly in my build.properties files? > > > > The answer to the question you were trying to ask is yes, but to > > this specific one, no. Jelly is the XML scripting, JEXL is the > > expression language used in Jelly. You can use an expression in > > build.properties, but not embed Jelly - just in case you wanted to > > start doing conditionals :) > > > > eg, > > somedir=${basedir}/src > > otherdir=${maven.build.dir}/other > > > > > 2) Is there a goal that occurs before maven loads the properties > > > file. So I could write a ... > > > ... > > > some.arbitrary.property=qaValue > > > ... > > > some.arbitrary.property=prodValue > > > > No, but the first is nicer and works. > > > > - Brett > > > > > > > > Thanks, > > > Ben > > > > > > -- > > > --- > > > 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] This message and any attachments contain information, which may be confidential or privileged. If you are not the intended recipient, please refrain from any disclosure, copying, distribution or use of this information. Please be aware that such actions are prohibited. If you have received this transmission in error, kindly notify us by calling 1-800-262-4723 or e-mail to [EMAIL PROTECTED] We appreciate your cooperation. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: do something before *.properties files load
that's a pretty slick solution. I'm going to use that. On Fri, 19 Nov 2004 12:06:02 -0500, Jean-Marc Lavoie <[EMAIL PROTECTED]> wrote: > Would it be possible to use something like this in the POM: > > ./opt/${myenvironmenttype}/project.xml > > So depending on the property you specify you can inherit from > ./opt/dev/project.xml or ./opt/prod/project.xml, and their respective > *.properties. The dev and prod folder only contains maven files. The opt > folder should prevent the multiproject plug-in to go through these > folders. > > Just an idea, let me know if this make sense. > > > > > > -Original Message- > > From: Ben Anderson [mailto:[EMAIL PROTECTED] > > Sent: Friday, November 19, 2004 11:44 AM > > To: Maven Users List > > Subject: Fwd: do something before *.properties files load > > > > -- Forwarded message -- > > From: Ben Anderson <[EMAIL PROTECTED]> > > Date: Fri, 19 Nov 2004 11:43:26 -0500 > > Subject: Re: do something before *.properties files load > > To: "Poppe, Troy" <[EMAIL PROTECTED]> > > > > > > Yes, same code essentially, except that one directory is a users > > working directory and one is from the SCM repository. > > > > > > > > > > On Fri, 19 Nov 2004 11:30:37 -0500, Poppe, Troy > <[EMAIL PROTECTED]> > > wrote: > > > > > > So you deploy different code to different environments? > > > > > > T > > > > > > > > > > > > -Original Message- > > > From: Ben Anderson [mailto:[EMAIL PROTECTED] > > > Sent: Friday, November 19, 2004 11:29 AM > > > To: Maven Users List > > > Subject: Re: do something before *.properties files load > > > > > > Neither of those will work, because I want to dynamically change > these: > > > > > > ${basepath}/src/java > > > > ${basepath}/src/test > > > ... > > > The properties file that specifices ${basepath} must be set before > the > > maven.xml > > > is parsed. > > > > > > On Fri, 19 Nov 2004 11:02:55 -0500, Poppe, Troy > <[EMAIL PROTECTED]> > > wrote: > > > > > > > > I am coming to a similar problem as you, Ben. I can see two > possible > > > > solutions, I've yet to decide which fits our setup the best. > > > > > > > > The first solution is to use Ant's property replacement task. For > > > > example, let's say your environment specific properties are in > your > > > > web.xml file. You'd create a generic web_template.xml file with > all > > > > the environment specific information written in the form of: > > > > ${env.specific.property}. Then, you'll create a .properties file > for > > > > each of your environments, (dev.properties) which will contain > your > > > > environment specific properties for development. Then create a > > > > preGoal for war:war (maybe something else), and use the ant > properties > > > > replacement task ( I believe) to get those values into > the > > > > newly generated web.xml. Then use this new web.xml will be used > in > > > > the newly generated war file. You'll have to create some switch > that > > > > can be used on the command line, or maybe even some project level > > > > goals in your maven.xml files that will generate what you need > (think > > > > of something like "build-dev" to create in your top most maven.xml > > > > file). > > > > > > > > Another solution would be to create a separate web.xml for each > > > > environment, web_dev.xml for example. Then in your preGoal for > > > > war:war, you could switch on a property specified on the command > line, > > > > and copy the selected xml file to web.xml. Then the newly > generated > > > > war file will contain the right web.xml. > > > > > > > > Personally, I like the first solution a bit better. In a way, it > > > > makes you declare what the environment specific properties are, > and > > > > you must provide a value for them to work. It also allows you to > > > > replace properties into different types of files, like source > code. > > > > > > > > I've used this approach for some of my Xdoclet code. I'll set > some > > > > Xdoclet values to be like "${env.property}", let Xdoclet g