On 5/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Carlos,
--> re FILTERING PROPERTIES FILES FOR ENVIRONMENTS
My suggestion is to externalie that configuration options in a way
that your artifact is always the same, and only configuration changes.
You can do reading your config files from the classpath or better
using JNDI.
++++++++++++++++++++
Sorry to harp on this, but I think I am having trouble thinking beyond
the way I have used ant the past few years.
100% of the differences between the developer workstation,
pre-production and production builds on my various projects are isolated
into properties files. These are then pulled into Spring as classpath
resources.
If I understand you correctly, you are suggesting that the project
artifacts, wars and jars alike, should not include these properties
files. These files should either:
- be accessed as classpath resource. Presumably some other
build/release process would deposit them on the classpath, or they would
be added to the container's classpath at startup.
- accessed via JNDI. The JNDI entries would either be name/value pairs,
the properties files themselves or a combo. When the war is deployed,
part of the deployment process would be to configure the JNDI tree.
Is this correct?
You could use the assembly plugin and create different assemblies for
each deployment environment. I'm not sure if there is a way to filter
the properties files during assembly, but if you don't have a lot of
properties and you are not adding properties or changing the names of
properties on a regular basis, then it wouldn't hurt to keep separate
files for assembly.
--
Craig McDaniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
