You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by ravasthi <ra...@55minutes.com> on 2007/11/08 00:45:00 UTC
Build profiles and overriding resources
I'm having an odd problem to do with overriding resources and build profiles.
I'm hoping someone can give me some insight as to why Maven is behaving as
it does. First, let me give you some background. I recently migrated my Ant
project to a Maven project, and I'm running Maven 2.0.7. I'm relatively new
to Maven, so please bear with me.
This particular project has a large set of properties files that define its
settings, and needs to run in several environments—for example a staging
server that we push releases to, and a QA server that we push nightly builds
to, as well as the usual development and production environments—and so I
need to keep a different set of settings files for each environment it needs
to run in. In addition, in order for the developers on our team to be able
to get up and running quickly, I've got a set of default settings that I
need to have the developers be able to override with settings for their own
machines.
Here's how I've got my settings files arranged: in src/main/resources, i've
created a directory called settings. In src/main/resources/settings, then,
I've got a bunch of subdirectories, each containing a set of properties
files specific to an environment, like so:
src/main/resources/settings/defaults
src/main/resources/settings/stage
src/main/resources/settings/qa
src/main/resources/settings/prod
Note that the full set may not be present in the environment-specific
directory; just the ones that need to change. Also, as I said above, the
developers need to be able to override the settings in
src/main/resources/settings/defaults with their own environment-specific
settings. I'd like them to put settings files as needed into
src/main/resources/settings.
Now let's take a step back for a minute to provide an example. We use Lucene
on our project to index our database to make for faster searches. In case
you're not familiar with it, Lucene stores an index of your database on your
local filesystem, that it can go to at runtime to look for queried items
before actually making a round trip to the database server. Now, Lucene
relies on a properties file, aptly called lucene.properties, to tell it
where on your filesystem you've stored the index.
So for each environment, then, in each of the src/main/resources/settings/
subdirectories, I've got a lucene.properties file. In addition, I could have
a lucene.properties file in src/main/resources/settings that pertains to my
development machine. So based on my build needs, I need to have a
lucene.properties file from any one of these locations take precedence, in
the following order:
- Properties from src/main/resources/settings/defaults should be taken
first.
- If there are any properties files of the same name in
src/main/resources/settings, they should override the default settings.
- If a build profile has been selected, properties files of the same
name should override those in both of the two locations above.
Relatively straightforward, right? But here's where the problem begins.
Originally I needed to filter all my properties files, in both my regular
and special build profiles, so I had the resources declarations placed like
so:
First, in my main build options, I had:
<resource>
<directory>src/main/resources/settings/defaults</directory>
<filtering>true</filtering>
<includes>
<include>*.properties</include>
<include>*.xml</include>
</includes>
</resource>
<resource>
<directory>src/main/resources/settings</directory>
<filtering>true</filtering>
<includes>
<include>*.properties</include>
<include>*.xml</include>
</includes>
</resource>
And then in my build profiles section, I had, for example:
<profile>
<id>stage</id>
<activation>
<property>
<name>env</name>
<value>stage</value>
</property>
</activation>
<build>
<resources>
<resource>
<directory>src/main/resources/settings/defaults</directory>
<filtering>true</filtering>
<includes>
<include>*.properties</include>
<include>*.xml</include>
</includes>
</resource>
<resource>
<directory>src/main/resources/settings/stage</directory>
<filtering>true</filtering>
<includes>
<include>*.properties</include>
<include>*.xml</include>
</includes>
</resource>
</resources>
</build>
</profile>
And this worked like a charm: the files in the resource directory mentioned
second would override the files of the same name obtained from the resource
directory listed first, files from the third directory listed would override
files from the second, and so on.
However, it turned out later on that I needed to turn off resource
filtering, so I went through and set all my <filtering> properties to false.
As soon as I did so, everything went to hell. The overriding stopped
working, and I couldn't use build profiles at all; the files in the first
resource directory mentioned, in this case
src/main/resources/settings/defaults, were the ones that ended up in
target/classes, and everything afterward was ignored.
I was able to get the overriding working again by reversing the order I was
listing directories: the directories whose contents I wanted to take
precedence had to be listed first, not last. However, I couldn't get build
profiles to work at all.
Finally what I did to get build profiles working with filtering off was to
create a new build profile that was active by default, and moved my resource
declarations from the <build>...</build> section into there, leaving no
resource declarations in the <build>...</build> section. Once I did that, I
could select a build profile and my target/classes directory would contain
the correct versions of the properties files.
So my questions are as follows:
- Why do properties files listed last get precedence when filtering is
_on_, and those listed first when filtering is _off_?
- Why do properties from selected profiles not take precedence when
filtering is on and there are resources listed in the main build options?
This may end up being a side-effect of the first phenomenon, but I'm not
sure.
Thanks for sticking with me to the end of this long message, and also for
any insight you may be able to provide.
Richa
--
View this message in context: http://www.nabble.com/Build-profiles-and-overriding-resources-tf4768154s177.html#a13638697
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Build profiles and overriding resources
Posted by Matthew McCullough <ma...@ambientideas.com>.
As a long time Maven (since 0.7) user, one of the most challenging things
I've faced thus far in 2.0 is profiles. It appears there are a lot of
anomalies when a profile is activated. Though it should work just as if
you've defined/set something in the normal sections of the pom, I find that
things like inheritance stop working in some cases, or in the oddest of them
all, <uniqueVersion> gets ignored for snapshots, and all the JARs get unique
timestamps generated. I've logged defects and some how-to-reproduces for
these profile based anomalies, but haven't seen fixes or many replies as of
yet. When I get a little break from work, I might have to try and dig in to
debug them myself. Hopefully, this anecdote just helps you hear that there
are indeed some oddities around profiles and profile activation.
ravasthi wrote:
>
> I'm having an odd problem to do with overriding resources and build
> profiles. I'm hoping someone can give me some insight as to why Maven is
> behaving as it does. First, let me give you some background. I recently
> migrated my Ant project to a Maven project, and I'm running Maven 2.0.7.
> I'm relatively new to Maven, so please bear with me.
>
> This particular project has a large set of properties files that define
> its settings, and needs to run in several environments—for example a
> staging server that we push releases to, and a QA server that we push
> nightly builds to, as well as the usual development and production
> environments—and so I need to keep a different set of settings files for
> each environment it needs to run in. In addition, in order for the
> developers on our team to be able to get up and running quickly, I've got
> a set of default settings that I need to have the developers be able to
> override with settings for their own machines.
>
> [snipped]
>
> - If a build profile has been selected, properties files of the same
> name should override those in both of the two locations above.
>
> [snipped]
>
> And then in my build profiles section, I had, for example:
>
> <profile>
> <id>stage</id>
> <activation>
> <property>
> <name>env</name>
> <value>stage</value>
> </property>
> </activation>
> <build>
> <resources>
> <resource>
>
> <directory>src/main/resources/settings/defaults</directory>
> <filtering>true</filtering>
> <includes>
> <include>*.properties</include>
> <include>*.xml</include>
> </includes>
> </resource>
> <resource>
>
> <directory>src/main/resources/settings/stage</directory>
> <filtering>true</filtering>
> <includes>
> <include>*.properties</include>
> <include>*.xml</include>
> </includes>
> </resource>
> </resources>
> </build>
> </profile>
>
> [snipped]
>
> I was able to get the overriding working again by reversing the order I
> was listing directories: the directories whose contents I wanted to take
> precedence had to be listed first, not last. However, I couldn't get build
> profiles to work at all.
>
> Finally what I did to get build profiles working with filtering off was to
> create a new build profile that was active by default, and moved my
> resource declarations from the <build>...</build> section into there,
> leaving no resource declarations in the <build>...</build> section. Once I
> did that, I could select a build profile and my target/classes directory
> would contain the correct versions of the properties files.
>
>
--
View this message in context: http://www.nabble.com/Build-profiles-and-overriding-resources-tf4768154s177.html#a13648367
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Build profiles and overriding resources
Posted by Vanja Petreski <vp...@gmail.com>.
Instead of having bunch of subdirectories with resources for every
environment, try only one, but use bunch of filters. One filter per
environment ;)
V