I am not sure that these were the options suggested by Wayne.
It appears that you are building a very common type of application that
hundreds of people build with Maven.
A lot of people use Spring which has dynamic configuration.
Web services have endpoint definitions.
Most applications have some sort of database that has run-time information.
The problem of injecting run-time information into webapps is well known
and Wayne gave you some Best Practices.
One of the key principles of building reliable systems is that you
should take what you have tested in your test environment and run it
unaltered in production.
Rebuilding the artifact after testing it, puts you in the position of
putting something into production that is new and untested.
Wayne suggested some alternatives.
We used JNDI and I documented this in 2 blog articles:
http://blog.artifact-software.com/tech/?p=150
http://blog.artifact-software.com/tech/?p=58
Your approach is not a "Best Practice".
Part of the reason that it is difficult to do under Maven is that it
should not be done this way.
The developers should not have any interest in the run-time environment
and should produce code that runs unaltered in any properly setup
environment.
If the system administrator changes an IP address or a database
password, he should be able to change the information in the system in
one place without having to ask the developer to produce a new application.
This should be well documented in the applications installation and
system administration procedures.
Database passwords, IP addresses, hostnames, etc. are not the concern of
a developer. These are under the control of the system administrator.
If the developer builds run-time environment information into the
application, the system administrator's changes will get overwritten
with each new release.
This could result in a nasty surprise when the application restarts.
If you are wearing both hats, you need to be aware of which role you are
performing at any given time and build your application so that it
respects the roles.
This is a universal problem and Wayne identified several ways to fix
this easily.
As you may be able to gather from my notes, we also went through the
process that you are grappling with before we got some good advice and
did the right thing.
It was very easy to do it right and once we had the first run-time stuff
into JNDI, it was easy to see how to handle each new issue.
We started with database and then added web services endpoints and other
properties.
I hope that this helps.
Ron
On 19/04/2012 12:33 AM, Andrew Hughes wrote:
I have looked into several options.
Assembly with Qualifiers (new module):
Looks good because I can run multiple<executions>, each with a unique
<filter>somefile.property</filter>. However I can't re-use the same
assembly description because the classifier is now obatined from the<id>
in the assembly descriptor :'( . That kinda sucks, it means I would have to
duplicate the assembly xml for each target classified artifact (or
copy/filter/rename the assembly xml during a gererate-sources or similar).
IMHO, this is not the best solution.
Profiles:
Only allow one build property set to exist, and thus each build can't use
filtering on the config. For this reason the resulting duplication and
deviation on each build would introduce bloat and increase the likelyhood
of breakage.
War Overlays :
This is (unfortunately) the best solution I have.
+acme (pom)
++acme-webapp (war)<--- all config options remain as ${someProperty} (ie.
No Filtering here!)
++acme-webapp-overlay (pom)
++acme-webapp-overlay-dev (war)
++acme-webapp-overlay-uat (war)
++acme-webapp-overlay-prod (war)
The acme-webapp-overlay will configure the
<plugin>...<artifactId>maven-war-plugin</artifactId><overlays>... (as well
as configure a dependecy too acme-webapp) the and each child module
(dev,uat,prod) provides their<properties>, which will filter selected
parts of acme-webapp (war) as it is overlayed.
This works, but I'm over it :)~
Thanks for all the advice
On Thu, Apr 19, 2012 at 2:38 AM, Wayne Fay<[email protected]> wrote:
I will read up some more. But, I was more wondering in regards to
classifiers if I could release x3 (or more) builds of the same module (at
the moment I have one module per conf, each is a war overlay).
I am not a huge fan of producing multiple artifacts (thus, your
suggestion of classifiers) for these types of purposes.
Instead, you should think about what kinds of things you could do that
would allow to produce a single artifact and then push it unchanged
into your various deployment environments. There are lots of
strategies to help with this problem: JNDI, Spring, other DI
solutions, etc.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
