---------- 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: > <build> > <sourceDirectory>${basepath}/src/java</sourceDirectory> > <unitTestSourceDirectory>${basepath}/src/test</unitTestSourceDirectory> > ... > 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 (<replace> 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'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 <sourceModification>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 > > > > > > > ---------------- > > > > > > > <preGoal name="build:start"> <!-- I think this is always > > > called first --> > > > > > > > <j:choose> > > > > > > > <j:when test="${env == 'qa'}"> > > > > > > > <j:set var="basepath" value="~/myproject"/> > > > > > > > ... > > > > > > > > > > > > > > project.properties > > > > > > > ------------------------- maven.src.dir=${basepath}/src/java > > > > > > > > > > > > > > project.xml > > > > > > > ----------------- > > > > > > > ... > > > > > > > <build> > > > > > > > <sourceDirectory> > > > > > > > this is bogus and will never be used > > > > > > > </sourceDirectory> > > > > > > > > > > > > > > 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 <unitTestSourceDirectory/>. I checked here: > > > > > > > http://maven.apache.org/reference/plugins/test/properties.ht > > > > > > > ml > > > > > > > and here: > > > > > > > > > > http://maven.apache.org/reference/user-guide.html#Behavioural_Proper > > > ti > > > 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 <preGoal name="something"> > > > > > > > > > <j:if>... ... 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] > > > > > > -------------------------------------------------------------------- > > > - > > > 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]
