On 19/04/2012 6:40 AM, Andrew Hughes wrote:
My app uses CDI (Weld), I know all about DI. I agree with you both :)
We would rather re-release (a new) version (not snapshot). If we want to we
can always change a deployment at runtime if we choose.
I am not sure what you mean by this.
Cheers
On 19/04/2012 3:22 PM, "Ron Wheeler"<rwhee...@artifact-software.com> wrote:
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=150>
http://blog.artifact-software.**com/tech/?p=58<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<wayne...@gmail.com> 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:
users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
