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