That's correct. My mistate. I thought i replied to your msg last night - but
my reply seems to have disapered.
Details of my new approach, and issues can be found here:
http://forum.springframework.org/showthread.php?t=42314
I will change it to use multiple PropertyPlaceholderConfigurer beans.
Even better - you can do away with the system property requirement if you use
Maven Filtering with spring. That way you can set the parameters at build
time, and not have to depend on a system parameter existing.
e.g. you use maven filtering to replace ${dev} inside your spring xml files
with
Wouldn't this still result in different artifacts for different environments?
If so, this is what I want to avoid. I would like my artifacts to be
environment agnostic. If you are building a single artifact, perhaps you
could explain how this works.
Thanks,
John
Antony Stubbs wrote:
Even
Good summary of the different options Franz!
For the moment I'm happy with the solution I have found but I may
revisit it in the future, who knows.
For those interested here's a working example:
svn checkout svn://svn.forge.objectweb.org/svnroot/xwiki/xwiki/trunk/web
Check the
G'Day,
I've just come across this thread. This is a problem that I too have
been wrestling with for the last few months, particularly with
respect to producing target environment (sit, uat, prod) dependent
artifacts.
I tend to agree with one of the respondents in that it is best to
I have found a solution that works well for me. I use spring in conjuction
with a bootstrap variable called env. When I start my container in
development env=dev in production it's env=prod. I then use spring to
resolve properties based on the environment. For example, a property file
would
I think several of us would be interested in this approach. Some
sample code etc would be great.
Wayne
On 4/26/07, jp4 [EMAIL PROTECTED] wrote:
I have found a solution that works well for me. I use spring in conjuction
with a bootstrap variable called env. When I start my container in
Coming from a strong ANT background, that approach seems very familiar!
On 26/04/07, Wayne Fay [EMAIL PROTECTED] wrote:
I think several of us would be interested in this approach. Some
sample code etc would be great.
Wayne
On 4/26/07, jp4 [EMAIL PROTECTED] wrote:
I have found a solution
Hi Franz,
On Apr 20, 2007, at 4:50 AM, franz see wrote:
Good day,
If the only thing different with the variations are the config
files and
some dependencies, then I suggest you use #2.
Thanks for your help. How is #2 better than the solution I'm now
using (which used the assembly
Good day,
What remote resources plugin does is that it extracts the resources from a
specified artifact, into ${basedir}/target/maven-shared-archive-resources.
And add those resources to your build's list of resources.
* [Filtering of remote resources]: Yes, it is possible to do so. It uses
Hi John and everyone,
Sorry for answering you so late on this and thanks again for your
feedback.
Following your direction I think I've found something slightly better:
* I use a pom packaging
* I use the assembly plugin to directly generate a WAR using the
following assembly descriptor:
Good day,
If the only thing different with the variations are the config files and
some dependencies, then I suggest you use #2. With regards to the shared
resources, you can do that now with the maven-remote-resources-plugin. So
you now have something like...
.
|-- core
`-- variations
Hi,
I've never found a good answer to this use case so far so I'm curious
about how others have implemented it.
Imagine a project that generates a WAR. This WAR contains a config
file (say in WEB-INF/classes) that configures connection parameters
for the database.
Now imagine that your
Hi Vincent,
I use filtering with profiles (option 1) and rebuild the entire project when
I need another configuration.
This is far from ideal..
Perhaps you could keep your runtime configuration in a separate module and
include the one you need as a dependency by activating a profile?
I like
I do my best to avoid needing a separate build per environment. A release
is a release, and while reproducibility is not the issue, I find it silly to
do so.
In my customer work, I found two key strategies that have worked well, both
from new system and streamlining an existing system:
Option 3
Hi,
Vincent Massol wrote:
Hi,
I've never found a good answer to this use case so far so I'm curious
about how others have implemented it.
Imagine a project that generates a WAR. This WAR contains a config file
(say in WEB-INF/classes) that configures connection parameters for the
Hi Jeff,
On Mar 16, 2007, at 1:00 PM, Jeff Jensen wrote:
I do my best to avoid needing a separate build per environment. A
release
is a release, and while reproducibility is not the issue, I find it
silly to
do so.
In my customer work, I found two key strategies that have worked
well,
On Mar 16, 2007, at 1:20 PM, Kenney Westerhof wrote:
Hi,
Vincent Massol wrote:
Hi,
I've never found a good answer to this use case so far so I'm
curious about how others have implemented it.
Imagine a project that generates a WAR. This WAR contains a config
file (say in WEB-INF/classes)
Ah! Your use case is not internal app use/release, but public distribution to
uncontrolled environments. :-) You can tell how I answered the question...
In your context, I agree that option 4 isn't very good (unless you want to dump
on the customer to get the environment specific dependencies
Hi folks,
we have a workable solution for moving around 40+ configuration files
and different database configurations - but it might not fit your needs
and might be overly complex ... :-)
Some background information
=
+) the
I came up with a third path. Mutliple projects, but with a slight
difference.
In the base project, an assembly would create an archive of unfiltered
configuration files. So the base project has the war (or jar) and a zip of
unfiltered configuration files. This project does not put any app
21 matches
Mail list logo
