maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Poppe, Troy" <Troy.Po...@eia.doe.gov>
Subject RE: do something before *.properties files load
Date Fri, 19 Nov 2004 16:30:37 GMT

So you deploy different code to different environments?

T

-----Original Message-----
From: Ben Anderson [mailto:benanderson.us@gmail.com] 
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 <troy.poppe@eia.doe.gov> 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:benanderson.us@gmail.com]
> 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, viretp@postfinance.ch 
> <viretp@postfinance.ch>
> 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:benanderson.us@gmail.com]
> > 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 
> > <brett.porter@gmail.com> 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
> > >
> > >
> > > <benanderson.us@gmail.com> 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
> > <brett.porter@gmail.com> 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 
> > > > > <benanderson.us@gmail.com> 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
> > <brett.porter@gmail.com> 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: 
> > > > > > > > users-unsubscribe@maven.apache.org
> > > > > > > > For additional commands, e-mail:
> > > > > > > > users-help@maven.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > --------------------------------------------------------------------
> > -
> > > > > >
> > > > > >
> > > > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > > > For additional commands, e-mail: users-help@maven.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > --------------------------------------------------------------------
> > -
> > > >
> > > >
> > > > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > > > For additional commands, e-mail: users-help@maven.apache.org
> > > >
> > > >
> > >
> >
> > --------------------------------------------------------------------
> > -
> >
> >
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> > --------------------------------------------------------------------
> > -
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> 
> 
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message