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

I'm resurrecting this thread since we now have an urgent need to implement it. See http://www.nabble.com/One-WAR-with-everything%2C-one-empty-WAR- and-or-one-WAR-per-database--tf4054670.html#a11517330 for details. The problem is that I've just discovered we're using Maven wrongly in the platform/web modules. We're using classifiers to release DB- flavors of the XWiki WAR. This is apparently not fully supported by Maven. The problem is that when you release an artifact on a remote repository with Maven it updates a metadata file with the version of that artifact (if it's a SNAPSHOT it's resolved to a timestamped version). The problem is that metadata file doesn't include classifier information so there's single "last updated" version. As we're releasing the HSQLDB and MySQL versions separately this metadata file is always wrong for one of the artifact, thus making dependent projects fail often since the SNAPSHOT version they're trying to retrieve doesn't exist! There are 2 solutions: A) Package a generic WAR and then have 2 separates modules to repackage it with DB data (thus leading to different artifactId - no more issue with classifiers) B) Implement the solution I was recommending below, i.e. generate a XWiki WAR without DB information (i.e. not-configured hibernate.cfg.xml file and no DB drivers). Solution 3 below. So far, if I recap the discussion thread we had: - Sergiu: +1 for solution 3 - Vincent: +1 for solution 3 - Artem: +1 for solution 3 - David: +1 for solution 2 I still think it's better if we have platform artifacts that are independent of databases. For me XWiki configuration is an activity that should be done in XWiki products and not in the platform. Another point is that since we now have a 1.1 branch too, we have to build and release 4 WARs (for 2 Databases - MySQL and HSQLDB). Very soon we'll have XEM which will probably require to use Derby for its standalone installation leading to 6 WARs... Each WAR takes between 5 minutes to 30 minutes to build and upload (35MB) so that's starting to weight on our dev process too (not counting the bandwidth cost and disk space issues). Using Solution 3) will also solve the problem of having to define an arbitrary location for the HSQLDB database files which is an ugly hack we currently have... We also now have nice installers and the next step for these installers is to allow users to decide what DB to use at installation time. We need to move quickly since this issue is causing false positives in our builds. If you haven't guessed I'm still in favor of solution 3... ;) Thanks -Vincent On Jul 10, 2007, at 10:46 AM, Vincent Massol wrote: