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:
>
> <extend>./opt/${myenvironmenttype}/project.xml</extend>
>
> 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:
> > > <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]
>
> ---------------------------------------------------------------------
> 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]
