Yes, we use the same technique. The trouble is not to have different config
sets, but to replace files in the standard src/main/webapp directory with
files from the config sets.
Thomas
"Jean-Yves LEBLEU" <[EMAIL PROTECTED]> schrieb am 07.11.2007 21:01:16:
> We have a project from which we can produce three different web
applications.
> We are using resource filtering to generate config files with
> properties defined in different profiles.
> In this case we hare 3 different profiles with 3 different pom properties
sets.
>
>
> JY
>
> On Nov 6, 2007 5:41 PM, Thomas Fischer <[EMAIL PROTECTED]> wrote:
> >
> > We develop a web application and test it on our development machines.
The
> > application has a bunch of configuration files.
> > When we package the web application, we want to replace the dev
> > configuration files, including the web.xml, with production config
files.
> > So we have our production configuration files in
> > src/main/config/${configDir}, where ${configDir} is set by the profile
(to
> > care for for different production environments). The war plugin is
> > configured as follows:
> >
> > <plugin>
> > <artifactId>maven-war-plugin</artifactId>
> > <version>2.0.2</version>
> > <configuration>
> > <webResources>
> > <resource>
> > <directory>src/main/config/${configDir}</directory>
> > <targetPath>WEB-INF</targetPath>
> > </resource>
> > </webResources>
> > </configuration>
> > </plugin>
> >
> >
> > Then we issue "mvn cIean package". However, this does not always
replace
> > the files in src/main webapp with the files in
> > src/main/config/${configDir}, but depends on the file modification
dates.
> > If the file in src/main/config/${configDir}is newer than the file in
> > src/main/webapp, the war plugin uses the file in
> > src/main/config/${configDir}; otherwise it uses the file in
> > src/main/webapp. The reason is probably that the war plugin tries to
> > replace only changed files when "clean" is not issued. This is at least
> > very confusing, if not a bug.
> >
> > To prevent this, we tried using the <warSourceExcludes> setting of the
war
> > plugin. For example,
> >
> > <warSourceExcludes>**/someConfigFile.properties</warSourceExcludes>
> >
> > However, if someConfigFiles.properties is newer in the src/main/webapp
> > directory than the file in in src/main/config/${configDir}, the file
is
> > missing in the jar (but not in the "exploded" war directory).(note :
> > web.xml seems to be an exception, I could not create a case where
web.xml
> > is incorrect or missing with this configuration)
> >
> > So my questions are:
> > - Is the current behaviour of the war plugin considered correct or is
it a
> > bug ?
> > - Is there a better way of managing different configurations ? Or, to
put
> > it differently, is there a good workaround to avoid these problems ? It
> > seems that putting the web content in a non-standard directory and then
> > assembling the war content manually using webResources would work, but
I'd
> > rather avoud this, as it does not play cleanly e.g. with the maven
eclipe
> > plugin's wpt option.
> >
> > This is using current versions of maven (2.0.7) and the maven war
plugin
> > (2.0.2)
> >
> > Thanks in advance for any hints,
> >
> > Thomas
> >
> >
> > ---------------------------------------------------------------------
> > 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]
