NOTE: For many situations, this is not appropriate.... we are an exception.
1. Check Out the revision / tag you want to re-configure. 2. Alter appropriate properties file(s), commit. 3. Do release:prepare release:perform This utilizes the SCM as a configuration management tool (in addition to source control). There are several advantages to this and several drawbacks. I now use a pom module, with several war executions to overlay a war. This works well. <project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd";> <modelVersion>4.0.0</modelVersion> <parent> <artifactId>acme-project</artifactId> <groupId>com.acme</groupId> <version>0.1.0.0-SNAPSHOT</version> <relativePath>..</relativePath> </parent> <artifactId>acme-project-webapp-env</artifactId> <packaging>pom</packaging> <dependencies> <dependency> <groupId>${project.groupId}</groupId> <artifactId>acme-project-webapp</artifactId> <type>war</type> </dependency> </dependencies> <build> <pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <version>2.2</version> <configuration> <overlays> <overlay> <groupId>${project.groupId}</groupId> <artifactId>acme-project-webapp</artifactId> <includes> <include>WEB-INF/*.properties</include> <include>WEB-INF/*.props</include> </includes> <filtered>true</filtered> </overlay> <overlay> <groupId>${project.groupId}</groupId> <artifactId>acme-project-webapp</artifactId> <filtered>false</filtered> </overlay> </overlays> </configuration> </plugin> </plugins> </pluginManagement> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-war-plugin</artifactId> <executions> <!-- build with dev config --> <execution> <id>dev</id> <phase>package</phase> <goals> <goal>war</goal> </goals> <configuration> <classifier>dev</classifier> <filters> <filter>${basedir}/env-dev.properties</filter> </filters> </configuration> </execution> <!-- build with staging config --> <execution> <id>staging</id> <phase>package</phase> <goals> <goal>war</goal> </goals> <configuration> <classifier>staging</classifier> <filters> <filter>${basedir}/env-staging.properties</filter> </filters> </configuration> </execution> <!-- build with prod config --> <execution> <id>prod</id> <phase>package</phase> <goals> <goal>war</goal> </goals> <configuration> <classifier>prod</classifier> <filters> <filter>${basedir}/env-prod.properties</filter> </filters> </configuration> </execution> </executions> </plugin> </plugins> </build> </project> On Thu, Apr 19, 2012 at 9:26 PM, Ron Wheeler <[email protected] > wrote: > 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"<rwheeler@artifact-**software.com<[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=150> >>> > >>> http://blog.artifact-software.****com/tech/?p=58<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.**apac**he.org<http://apache.org> >>>>> <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: >>> 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] >
