[xwiki-dev] One WAR with everything, one empty WAR and/or one WAR per database?

[David Ward]

On 7/10/07, Vincent Massol <vincent at massol.net> wrote:
> Hi,
>
> With the 1.1M3 release we have currently only released a hsql version
> of the platform WAR. That war only includes the HSQL JAR but not the
> driver JARS for other DBs.
> In our current build we can generate the platform WAR for other DBs
> using for ex: mvn install -Pmysql. That includes the driver JAR for
> that DB.
>
> Before we were bundling all driver JARs into our WAR so our users may
> be a bit confused and we need to decide on the strategy we want to
> have. I can see 3 possible strategies:
>
> 1) 1 WAR per database
> - We could start by releasing only 2 WARs: one for HSQL and one for
> MySQL. I don't think we need more and releasing more is going to be a
> pain as each WAR weights 40MB.

 + easiest to deploy as configuration is always close
 - more difficult to change from one db to another once one has
figured things out

> 2) 1 WAR with everything
> - Cons: having all these DB drivers makes our WAR fatter
> - Possible solution: we only release the HSQL and MySQL drivers

 + easiest to change from one db to another
 + total WAR size is smaller than multiple WARs
 - a little larger WAR than is needed

> 3) 1 empty WAR
>
> I feel 3) might actually be the best solution for the following reasons:
> - if the user is non technical he'll install the standalone version
> - if the user is technical it means he shouldn't have any problem
> following install instructions that tell him to download such driver
> at such location and put it in WEB-INF/lib
> - we only release one common WAR and our XWiki Platform is
> environment independent (which is a new property to have I think)
> - releasing one WAR makes our release process simpler (only 40MB to
> release once)

 + easiest to test before release
 - more difficult to upgrade deployments (not just configuration changes)
 + requires really good documentation


I do not know how many users use the standalone release vs. mysql vs.
postgresql vs..., but this should probably be a factor in which
strategy is used (make it easy to deploy for 80% of users).

I think #2 has my vote, as this seems to be the more standard practice
with other products (just requires configuration changes unless you
want to do something that is non-standard).


David
--