One WAR with everything, one empty WAR and/or one WAR per database?
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
On 7/10/07, Vincent Massol <[email protected]> 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 --
On Jul 10, 2007, at 5:23 PM, David Ward wrote:
On 7/10/07, Vincent Massol <[email protected]> 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
+1 to 3) I agree with Vincent. The less platform depend on the environment, the better. Vincent Massol wrote:
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?
-- Artem Melentyev, UralSU
+1 for option 3. Indeed, if a user finds it hard to configure the database, then he should use the standalone package. On 7/10/07, Vincent Massol <[email protected]> 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
Sergiu -- http://purl.org/net/sergiu
On Jul 11, 2007, at 12:51 AM, Sergiu Dumitriu wrote:
+1 for option 3. Indeed, if a user finds it hard to configure the database, then he should use the standalone package.
Yes, and I have now started an installer package in which we could let the user decide its database option on a screen and in which we could package the different JDBC drivers. -Vincent
On 7/10/07, Vincent Massol <[email protected]> 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
Sergiu -- http://purl.org/net/sergiu
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
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 - 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- 'Waste of a good apple' -Samwise Gamgee
On Sep 14, 2007, at 7:01 PM, Erin Schnabel wrote:
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...
We have a place for this already inside our new shiny installers. I think we should do the following: 1) Let the user choose his Database in the Installer. 2) Have a Configuration Wizard Application (as a XAR for example) that gets executed automatically the first time you run an XWiki instance. That wizard would detect existing installs and perform required upgrade, ask questions to the user to configure XWiki, etc. To summarize: DB config is done in the installer (since XWiki needs a DB config to start) and the rest is done in that Config Wizard. WDYT? Thanks -Vincent
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 - 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
participants (5)
-
Artem Melentyev -
David Ward -
Erin Schnabel -
Sergiu Dumitriu -
Vincent Massol