You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by krupa Vyaghra <kv...@alito.co.uk> on 2007/06/19 16:03:23 UTC
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
RE: Request for advice: webapp customisations as an overlay to an existing WAR
Posted by Jeff Jensen <je...@upstairstechnology.com>.
> 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:kvyaghra@alito.co.uk]
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org