Stephen, Many thanks for taking the time to write this long and valuable response; I'll follow your advise, and work sprint by sprint in trying to get into the maven way.
Best regards Jean-Noël On 27 Feb 2013, at 10:25, Stephen Connolly <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> 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" <[email protected] >>> >>>> 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 <[email protected]> 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 <[email protected] >>> >>>>>> 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 <[email protected]> >>>>>>>> >>>>>>>>> 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 >>>>>> <[email protected]> >>>>>>>>> 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: [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] >>>>>>>>>> >>>>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Baptiste <Batmat> MATHUS - http://batmat.net >>>>>>>>> Sauvez un arbre, >>>>>>>>> Mangez un castor ! nbsp;! <[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] >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
