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.
Cheers On 19/04/2012 3:22 PM, "Ron Wheeler" <[email protected]> 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<[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: >>> users-unsubscribe@maven.**apache.org<[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] >
