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.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 <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]
