-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Rick,
> I know this must be a common question, and I've been googling for the best
> practice for using a different configuration file (say a different
> hibernate.cfg.xml file) for different profiles (based on a profile, local,
> itr, etc.)
>
> Normally I rely on a single file that is filtered based on a different
> filter file (prepended by the profile environment name), however the files
> now might be drastically different for a local build (where I define
> properties for a datasource) and a production build which will have
> different properties in the file for locating a datasource, so just using in
> place substitution isn't the best (I'd prefer a way to copy a completely
> different config file based on the profile being run.)
>
> Basically how to you include different property/xml files for your different
> builds (using profiles)
Best practices IMHO:
1. Separate configurations from your application artifacts.
This allows to deploy the same application artifacts in
test environments and production. Only pure configuration
artifacts differ.
2. Load configurations from classpath rather than filesystem
3. use filtering for environment specific configs wherever
possible. You might simply add a filter like
filter-${my.environment}.properties
and add ${my.environment} to finalName.
Then you can build such configuration project multiple times
with different values for -Dmy.environment=...
4. for commerical use:
ask the operators how to deal with env. specific configs.
It might be fine for developers to package configs in JARs
while this would be kinda awkward for an operator who has
to maintain such configs.
Hope this helped a little
Regards
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqYL1kACgkQmPuec2Dcv//JFACfbs6nI71xuX7v6Lfws5yFy8uQ
pMAAnjeVWckwc8p+neSwLO0Ra1GFMQRA
=ix6N
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
