Yes, though better is to have the customizations in a separate file and then the war picks up that file and applied the customizations to itself, thus removing the need to customize a war at all.
For example, you could package up the customizations in a .jar file with a customization descriptor at a defined classpath url (e.g. /META-INF/com.mydomain.myapp/customizations.toml ) the customizations descriptor could be as simple as a .properties file that names the resources, or as complex as an XML/yaml descriptor that does all sorts of fancy mapping... a servlet filter could intercept requests for static resources and serve them from the customized resource location, and some other tweaks to your .war's logic, can filter in the modifications to dynamic pages. You then just drop the customizations.jar into the Tomcat shared lib folder and now you just drop the standard war into any customers tomcat and you don't have to worry, no repacking at all... it will just pick up their customizations automagically If you like, the above is much more the "Maven way" of solving your problem... granted right now you may not be able to move to that goal right now, for one it will involve refactoring your current code... so when faced with that kind of problem I would say "OK, I know the end goal, it sounds attractive as it removes a pain point for me (namely having to run the customize step for each customer) and it also removes a potential problem (namely forgetting to customize and deploying an uncustomized .war into a customers instance), but right now there are too many moving pieces, so I will use the stop-gap of using ANT/Chef/Puppet/Gradle/BASH/whatever to unpack, customize and repack the .war for each customer. Next sprint we will start moving towards the ideal customizations architecture" The repack solution is outside of Maven's responsibilities, so it doesn't care whether you do a repack or a customizations.jar... the point is that once you grok the Maven way, you will care, and you will find yourself wanting to do this the "right"* way... If I have 3-5 customers, I'd probably stick with the repack... more than 5 and I'd push for the customizations.jar model -Stephen * There is no "right" way, but we can apply Occam's software release management razor: among competing release processes, the one that uses the fewest manual steps should be selected. On 27 February 2013 08:56, Jean-Noël Colin <jn.co...@gmail.com> wrote: > so basically, what you recommend is to use Maven to build a 'standard' > war, and then write my own scripts to customize the war to each distinct > environment, is that right? > > Jean-Noël > > On 26 Feb 2013, at 17:50, Ron Wheeler <rwhee...@artifact-software.com> > wrote: > > > Since you want to support a "lot" of customers with different > configurations, you may want something that is based on a simple CMS that > provides a database and an editing tool and an API for extracting content. > > You script could then navigate the CMS picking up the right pieces to > make up the war for each client. > > > > If you have to deliver updated documentation, release note and revised > EULAs, then you might want to use your script to prepare an installer > staging area and invoke an installer build package to build a customized > installer for each client. > > > > > > Ron > > > > On 26/02/2013 10:49 AM, Lyons, Roy wrote: > >> I say that you could just run a post-deployment command that performs > any > >> filtering. You could use ant, perl, java, whatever you wanted to... > and > >> perhaps have it pull down content from a centralized git repository or > >> something to make it easy to maintain your properties/configs. > >> > >> The obvious mess comes into play if you are performing deployments using > >> the maven tomcat plugin or something similar instead of a real packaging > >> tool. > >> > >> > >> Thanks, > >> > >> Roy Lyons > >> > >> > >> > >> > >> > >> On 2/26/13 9:43 AM, "Stephen Connolly" <stephen.alan.conno...@gmail.com > > > >> wrote: > >> > >>> I have an answer on Stack Overflow that might help your thought > processes: > >>> > http://stackoverflow.com/questions/14650468/whats-a-practicable-way-for-au > >>> tomated-configuration-versioning-and-deployment/14661186#14661186 > >>> > >>> > >>> On 26 February 2013 15:06, Jean-Noël Colin <jn.co...@gmail.com> wrote: > >>> > >>>> so your suggestion would be to have maven do the compile, and a kind > of > >>>> 'war:exploded', and then run ant to add the customized files and > create > >>>> the > >>>> war file, is that correct? > >>>> > >>>> or should I write a plugin that does that for me? > >>>> > >>>> You write: "Separating run-time deployment from Maven is a best > >>>> practice"; > >>>> but then, what should I use to customise and deploy distribution kits? > >>>> > >>>> Best > >>>> > >>>> Jean-Noël > >>>> > >>>> On 26 Feb 2013, at 10:01, Ron Wheeler <rwhee...@artifact-software.com > > > >>>> wrote: > >>>> > >>>>> On 26/02/2013 2:54 AM, Baptiste MATHUS wrote: > >>>>>> I *think* Ron means: using maven to produce your standard artifacts > >>>>>> (jar/war/ear ?), and then use pure ant somewhere in the process just > >>>> before > >>>>>> deploying for a specific customer to do the replacements you're > >>>> talking > >>>>>> about. > >>>>>> > >>>>>> (By the way, invoking ant from maven (using antrun-maven-plugin) > >>>> should > >>>>>> always be considered something bad and temporary. Writing or using a > >>>>>> dedicated maven plugin is the way to go). > >>>>>> > >>>>> Exactly. > >>>>> My suggestion would be to run the ant after all the maven work is > >>>> complete and you have a full set of release files in your repo > >>>>> Have Ant (or some other process) merge the released code with > >>>> configuration files, logos, etc to make distribution kits. > >>>>> Ron > >>>>>> 2013/2/26 Jean-Noël Colin <jn.co...@gmail.com> > >>>>>> > >>>>>>> Hi Ron, > >>>>>>> > >>>>>>> Do you mean invoking the ant plugin from the pom.xml file? I was > >>>> wondering > >>>>>>> whether this was a good practice, or something to be kept only for > >>>>>>> situations where you really can't avoid it > >>>>>>> > >>>>>>> Best regards > >>>>>>> > >>>>>>> Jean-Noël > >>>>>>> > >>>>>>> On 25 Feb 2013, at 21:31, Ron Wheeler > >>>> <rwhee...@artifact-software.com> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Why not move the production of the software to Maven and leave the > >>>>>>> assembly in Ant. > >>>>>>>> That would give you the best of both worlds. > >>>>>>>> > >>>>>>>> > >>>>>>>> On 25/02/2013 2:41 PM, Jean-Noël Colin wrote: > >>>>>>>>> Hi > >>>>>>>>> > >>>>>>>>> I'm trying to migrate my project from ant to maven, but I'm > >>>> facing a > >>>>>>> few difficulties; I need to build my project for different > >>>> environments > >>>>>>> (customers, so possibly a long list). In my ant project, I had > >>>> several > >>>>>>> .properties file, one per customer; in this file, I had properties > >>>> used to > >>>>>>> customize some config file; I managed to use resource filtering to > >>>> achieve > >>>>>>> this. > >>>>>>>>> However, some properties defined a filename that needed to be > >>>> copied > >>>> to > >>>>>>> the war archive, but under a common name. For instance, I had > >>>> several > >>>>>>> logos: logo_customer1.jpg, logo_customer2.jpg, logo_customer3.jpg; > >>>> the > >>>>>>> source file name was specified in the properties file > >>>>>>> (customer1.properties, customer2.properties, customer3.properties), > >>>> but the > >>>>>>> destination was always logo.jpg. How can I do that? > >>>>>>>>> Second, the properties file defines the name of the file > >>>> (resources) > >>>> to > >>>>>>> be filtered. For instance, I have a template for working with > Spring > >>>>>>> Security in LDAP environment and another template when working when > >>>> Active > >>>>>>> Directory; the customer properties file defined the name of the > >>>> template to > >>>>>>> use, but in both cases, the result file needs to be > >>>>>>> applicationContext-security.xml. How can i achieve this? Or is > >>>> there a > >>>> way > >>>>>>> to define conditional profiles so that in the customer .properties > >>>> file, I > >>>>>>> would say LDAP or AD, and based on that value, different profile > >>>> would > >>>> be > >>>>>>> used? > >>>>>>>>> Many thanks for your help > >>>>>>>>> > >>>>>>>>> Jean-Noël > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>> --------------------------------------------------------------------- > >>>>>>>>> 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 > >>>>>>>> > >>>>>>> > >>>> --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >>>>>>> For additional commands, e-mail: users-h...@maven.apache.org > >>>>>>> > >>>>>>> -- > >>>>>>> Baptiste <Batmat> MATHUS - http://batmat.net > >>>>>>> Sauvez un arbre, > >>>>>>> Mangez un castor ! nbsp;! <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 > >>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >>>> For additional commands, e-mail: users-h...@maven.apache.org > >>>> > >>>> > >> > >> --------------------------------------------------------------------- > >> 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 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
