One WAR with everything, one empty WAR and/or one WAR per database?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

One WAR with everything, one empty WAR and/or one WAR per database?

vmassol
Administrator
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




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: One WAR with everything, one empty WAR and/or one WAR per database?

David Ward-8
On 7/10/07, Vincent Massol <[hidden email]> 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
--



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: One WAR with everything, one empty WAR and/or one WAR per database?

vmassol
Administrator

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

> On 7/10/07, Vincent Massol <[hidden email]> 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




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: One WAR with everything, one empty WAR and/or one WAR per database?

Artem Melentyev-2
In reply to this post by vmassol
+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



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: One WAR with everything, one empty WAR and/or one WAR per database?

Sergiu Dumitriu
In reply to this post by vmassol
+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 <[hidden email]> 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



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: One WAR with everything, one empty WAR and/or one WAR per database?

vmassol
Administrator

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 <[hidden email]> 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
>



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: One WAR with everything, one empty WAR and/or one WAR per database?

vmassol
Administrator
In reply to this post by vmassol
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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: One WAR with everything, one empty WAR and/or one WAR per database?

David Ward-8
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 <[hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: One WAR with everything, one empty WAR and/or one WAR per database?

ebullient
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 <[hidden email]> 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 <[hidden email]> 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
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>


--
'Waste of a good apple' -Samwise Gamgee
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Configuration Wizard (was Re: One WAR with everything, one empty WAR and/or one WAR per database?)

vmassol
Administrator

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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs