Re: [xwiki-devs] One WAR with everything, one empty WAR and/or one WAR per database?
I think a script to generate the config files for the database post-WAR is also the right thing. A) generate the WAR B) perhaps have a config-wizard/scripty/whatsit to manage DB config (could perhaps even guide creation of original xwiki.cfg file... On 9/12/07, David Ward <[EMAIL PROTECTED]> wrote: > Vincent, > > I'll add to this thread even though I mentioned it in the other thread. > > I'm all for #3 as long as it can be configured using a script to add > the driver and configuration files to the war before deployment (such > as for auto-deployments to our development environment). > > I suspect that it shouldn't be difficult to do this (just need to add > the driver). > > > David > -- > > On 9/11/07, Vincent Massol <[EMAIL PROTECTED]> wrote: > > 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: > > > > > 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. > > > > > > 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 > > > > > > 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
Re: [xwiki-devs] One WAR with everything, one empty WAR and/or one WAR per database?
Vincent, I'll add to this thread even though I mentioned it in the other thread. I'm all for #3 as long as it can be configured using a script to add the driver and configuration files to the war before deployment (such as for auto-deployments to our development environment). I suspect that it shouldn't be difficult to do this (just need to add the driver). David -- On 9/11/07, Vincent Massol <[EMAIL PROTECTED]> wrote: > 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: > > > 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. > > > > 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 > > > > 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) > > > > WDYT? > > > > Thanks > > -Vincent > > > > ___ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailm
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: > 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. > > 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 > > 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) > > WDYT? > > Thanks > -Vincent > ___ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
