27 Oct
2008
27 Oct
'08
6:17 p.m.
On Oct 27, 2008, at 5:57 PM, Sergiu Dumitriu wrote:
Thomas Mortagne wrote:
Yes I agree. We could release only 1 official "standalone"
distribution and make the other available from the build but we could
also make them available from time to time manually. We might need to
do that for the GF+Derby distribution for example since we'll blog/
twit about this. We could also ask Glassfish for help for doing this.
Maybe they have a location where the XWiki GF+Derby distribution could
be hosted if we don't want to host it?
Hi devs,
I finished a maven build for XWiki+GlassFish+derby distribution.
So this means a distribution not based on jetty and we can't use
database profile to decide what distribution to build anymore.
So I propose:
1) havnig distributions like jetty-hsqldb, glassfish-derby, etc. and
to remove distribution we are not releasing/using right now on XE/XEM
like hsqldb-pgsql, hsqldb-derby etc.
On maven build this means that to build XE glassfish-derby you will
need to execute:
- on XE parent : mvn install -Pci,derby,glassfish-derby
- on the distribution : mvn install
This will change all distributions ids but I don't think it's a
problem.
2) jetty-hsqldb remain the default distribution for now
Here is my +1 for both
+1 for 1). I think that the generic "thing" that users can customize
as
they want remains the .war distribution, and we could have several
ready-to-run distributions. Still, do we need several? What is the
advantage of having both jetty and glassfish distributions, besides
the
fact that users can build their own distribution package? I don't know
if we should publish two distributions, as it might confuse users.
"Which one should I use? What is Jetty and what is Glassfish? Can't I
just download ONE file and run it, why must it be so complicated?"
So, I'd rather keep only one package we officially distribute, the
rest
being available as custom maven builds, for those that need them and
know how to build from sources. For 2), what about changing to derby as the default?
+1 but before we switch we need to have well tested distribution + do
some work:
* Update Jetty to latest version
* Use Jetty from a maven repo and not from our SVN (we need to remove
that version)
* Make our CI run on Derby to ensure all the tests pass
Thanks
-Vincent