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

[Vincent Massol]

On Jul 10, 2007, at 5:23 PM, David Ward wrote:

> 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

Also the user still needs to configure the hibernate file.

>> 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)

Actually not quite true as the database driver can be put in the  
container system classpath and not in the WAR's WEB-INF/lib.

> + requires really good documentation

What would you add more to our current documentation? (You just made  
me realize we need to modify it to mention that the jdbc driver could  
also be added to the container's common lib rather than into WEB-INF/ 
lib)

> 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).

Actually I think the standard practice is 3. This is also the  
strategy used by Confluence.

The fact that 3) requires libraries to be added is a non-issue IMO as  
a) upgrading can be made simple by dropping the lib in container's  
common lib directory and 2) users need anyway to reinstall their  
plugins, etc.

OTOH solutions 1) and 2) bring lots of disadvantages.

The more I think about it the more strongly I am for solution 3.

Thanks
-Vincent