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