> How would you recommend we accomplish this? The first idea that strikes me is to use the source control system first. This is not a build tool problem. A build tool should "simply" make the artifacts for the given codeline. The current setup you describe has partial code for customer customizations, not a true codeline, and (to me) stretches what a build tool should do.
What SCM product is in use there? A good SCM with good branching and merging capabilities (such as Perforce) will very easily solve the file movement needs and problems. Not all SCMs can do this very well... The basic idea is to create a full codeline for each customer's unique release, branching from your main codeline (the Standard one). This is not just the files that changed, but the whole product source as a reproducible build. Then, when needing to update customer versions from the Standard, it is simply an SCM merge operation to get those updates to them. A given client customization can stay at an earlier version as needed by not merging again (or at least merging only from the versions of the prior releases); the SCM merge operation determines what level they are at. Your current build process handles copying all the files around, so let's have it reproducible, source controlled, more easily managed, and out of the build process by using SCM well. Your build time will reduce too, as the file copy is eliminated for each build. Additional codeline management patterns may benefit you further too, such as mainline and release line, so that you manage the standard web app that way and merge to customer release codelines from your standard app release codelines. This approach will eliminate the problems you listed, and easily enable different customers based on different versions of the Standard. The extra effort it requires is the need for proper codeline maintenance. I tried to be brief while answering the issues, so this may not be fully clear... -----Original Message----- From: krupa Vyaghra [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 19, 2007 9:03 AM To: users@maven.apache.org Subject: Request for advice: webapp customisations as an overlay to an existing WAR Hello, I am working on a project where we have a standard webapp - let's call this Standard Webapp - which is a project with a WAR packaging. It in turn depends on some JAR projects, which are largely irrelevant to the question in hand. The Standard Webapp WAR project contains all the config and presentation layer code (jspx, tagx, html, JavaScript, CSS etc.) for a plain vanilla version of our application. The Standard Webapp WAR project and it's dependency JAR projects are all set up in a multi project hierarchy, and all is hunky dory. Each project can have its own version, and during development everything is a snapshot. We branch in source control for each versioned release (when the projects get assigned a real version) and we build and deploy from the branch. We are using Maven 2.0.6 and have an internal repository to which we deploy our released versions. We have a large number of clients, and for each client we create client-specific customisations of this Standard Webapp WAR where there are small variations to the application - largely around look and feel (accomplished through CSS) and terminology (accomplished through message resource bundles), but occasionally there are variations in functionality (accomplished through having a different version of a JSP or a config files). The plain vanilla Standard Webapp is what we develop and build internally, but what gets released for each client is a client WAR that has all the files from the Standard Webapp plus any client customisations - only those files that are different from the standard are replaced. Each client customisation is set up as a project in itself - let's call one of these Client Customisation - with a WAR packaging. The contents of the project (source) have the same structure as the App WAR, but contain only those files that are different from the Standard Webapp. There is a home-grown plug-in that copies all the files from the source of the Standard Webapp project into the target of the Client Customisation project prior to it being built, so the variation files from the source of the Client Customisation project then overwrite any files that came from the Standard Webapp. This gives us a complete Client WAR which is a copy of all the latest code from the Standard WAR plus any variations, which we can deploy. With me so far? While this works for us, the problem that I have is threefold. Firstly, this does not seem to be really in the spirit of Maven. It is fiddling about with directories and files rather than thinking about packages and components. I feel there should be a more Maven-ish way to accomplish this. Secondly, and more importantly, this process does not always work. We have found that if a source file in the Client Customisation is older than the equivalent file from the Standard Webapp, it does not overwrite the file in the target. Thirdly, and even more importantly, we have a business requirement that client customisations should not necessarily apply to the latest Standard Webapp code. That is to say, when assembling a Client WAR, we should be able to base it on any arbitrary versioned Standard Webapp WAR, not the latest one. We want to be able to say that Client 1 is to be given version 2.0.7 of the webapp, and their customisations will be developed for that version, while Client 2 is to be given 2.0.8 of the applications, and their customisations should be developed against that version. i.e. we should be able to define a Client 1 Customisation project that has a dependency on the Standard Webapp version 2.0.6. This project should contain all those files that are different from the Standard Webapp, and the resulting artifact should be a Client 1 WAR that is based on the Standard Webapp WAR 2.0.6 and has all the Client 1 variations in it. Likewise we should have a Client 2 Customisation project that has a dependency on Standard Webapp version 2.0.7 which generated a Client 2 WAR based on Standard Webapp 2.0.7 and has all the Client 2 customisations in it. How would you recommend we accomplish this? Ant plug-in? Assembly plug-in? Dependency plug-in? Combination of all? Or perhaps a custom packaging type (say, 'customisation') that accomplishes all we need to do in code? Regards, Krupa No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.472 / Virus Database: 269.9.0/853 - Release Date: 18/06/2007 15:02 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]