19 Apr
2012
19 Apr
'12
6:36 p.m.
On Wed, Apr 11, 2012 at 6:52 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
Hi Thomas,
I am not sure we are going the right way here !
As far as I know, the difference between XE or XEM distribution are really
small, and does not really implies the XAR that should be finally
They are not that small actually right now: in XEM you have
appmanager, wikimanager and workspacesmanager plus some custom pages
added to XE xar.
installed. So the information you propose to store are
not so pertinent
IMO. Moreover, the war may be expanded and some of its jar replaced, which
may change its behavior a lot, while the information you store in the
property file are left untouched.
Currently we may prevent installing a XAR incompatible with the current
core, just by using dependency, and this works without any additional
information about the deployed war. What you want to introduce is the
reverse, and even if I understand your goal, I do not like much this
bilateral dependency.
If, what you target is to facilitate the upgrade, I would prefer to see a
new feature of EM, that would check for new version of an installed XAR,
and if the new version is installable (its dependencies could be
satisfied), have a proposal for an upgrade. So, upgrading some jars, would
trigger new proposal to upgrade xar, and this would work as well with the
deployment of an upgraded distribution.
Adding an UpgradePlanJob to check for new compatible versions of
various installed extensions is obviously planned but this proposal is
not about that.
This is not a system to upgrade all installed extensions, this is a
system to know that there is tasks left to do to finish a proper
install or upgrade of a distribution and propose to automatically do
theses required tasks or at least indicate what the user need to do
when it can't be done automatically. There is the need to install some
specific extensions like the corresponding standard XAR yes (and the
plan is not to upgrade all installed extensions) but not just that, we
will want to check the configuration and report what seems wrong
(wrong database rights, persistent directory same as temporary
directory, etc...) and later even setup the database or any other task
that the user has to do when installing XWiki.
Upgrade is one thing but if the xar hasn't been installed as an
extension you are not going to upgrade much so the main target in this
proposal is actually the install step.
We could decide that we don't want any specific distribution upgrade
UI and just let the user go to EM UI and upgrade the distribution xar
among other extensions but I don't find it very friendly. Since this
is needed in install I tough it would be nice to do the same thing for
upgrade too (at upgrade too you potentially have other things to check
than upgrading some extensions, new required property not properly set
etc...). But then you need to know when to display this general
upgrade Ui and you are not going to display it each time any extension
has available updates so you need to differentiate what's actually
required for a distribution upgrade and what is just something that
can be left to standard EM UI.
There is always the risk that the current xar based UI is broken with
a new version of the war (would not be the first time) while a
template based upgrade UI which would always be in sync with the war
since it comes with it is safer.
Another issue if that checking for available new versions of installed
extensions can be pretty expensive so either we block the startup a
long time or we let the user do whatever he want in old version of the
UI until we are ready to tell him some extension actually need to be
upgraded in order to have the XWiki instance in a proper state.
Regarding the initial setup, I see no real difficulties when a database is
empty, to propose the installation of the latest compatible version of some
distribution XAR. The only thing we need is to know is what is a
distribution XAR opposed to other extensions. And, we may imagine that we
had finally only one WAR, and that choosing between XE, XEM or anything is
done later, through this mechanism. So, this has nothing to do with storing
additional information on the FS or in the database.
The goal here is to do something in 4.1 with the current multiple
distributions we have, I'm not working on a 5.x proposal when we will
refactor entirely what we release. If later some information become
redundant then good we will simply stop providing then in the released
distribution package.
A user who is installing XE war will expect that we propose to install
corresponding distribution xar.
Right now I don't see any way to know what XAR to install when
starting XWiki the first time to finish the installation. There is
nothing in the existing informations that can help with that. We have
the version in version.properties, some core extensions (only coming
from commons/rendering/platform or completely external dependencies)
and that's all. The distribution war is just an assembly of different
things as it should.
I am currently almost -1 to introduce a mechanism that store somewhat
arbitrary information in a war, and this same information in databases, to
provide an installation/upgrade mechanism. My feeling is that we should
work with the existing dependency mechanism provided by EM, extending it a
little bit. This should be more flexible, solid and less prone to weird
issues. It will also scale more easily, especially when we will reduce our
core war to a minimal extension deployer, since at the end, this will be
all we really need.
It's not some configuration file that the user is supposed to setup
and in which he can make mistakes. It's stable informations (we pretty
much never changes them) which are in the sources or generated at
build time for the version for example. Exactly like
version.properties which already exists, it's just an extension of
this file basically.
Hope you get my idea. I am available to discuss this more in depth if you
need further clarification.
Thanks,
IMO this file does not really force anything on the long run since
it's very internal stuff with both the data and the system dealing
with theses datas coming with the war. We can remove it or part of it
any version we want as soon as we find another way we prefer to
provide what's in it or make this information useless (by doing a huge
refactoring of what's a XWiki distribution for example).
In the meantime it provide very quickly a way to display a handy and
safe distribution install/upgrade UI to make sure admins stop
importing the distribution xar as plain xar with lots of embedded and
hidden extensions and as a bonus a good entry point to start putting
other stuff like setup validation check etc.
On Fri, Apr 6, 2012 at 09:49, Thomas Mortagne <thomas.mortagne(a)xwiki.com>wrote;wrote:
--
Thomas Mortagne
Hi dev,
To get a proper setup of installed extensions we want to make sure
everything is installed trough Extension Manager instead of being
imported as a plain xar. So the idea come up to finally start the long
awaited installer/upgrader UI.
First step is to find how to know when to display this UI so here is a
proposal (ref
http://dev.xwiki.org/xwiki/bin/view/Design/Installerandupgrader):
= The new informations
* deprecate version.properties for a more complete
distribution.properties that would contains at least the following
** version of the distribution
** top extension id of the distribution (to display general
informations about the distribution). For example in XE it would be
distribution.id=xwiki-enterprise
** name of the distribution (I'm not 100% sure for this one since we
can find it with the id using Extension Manager but I think it's safer
in case we don't have access to any repository to display something
nicer than a technical id). For example for XE it would be
distribution.name=XWiki Enterprise (who would have guessed :)).
** war extension id of the distribution (generate a default id like
<product-id>-web when none is provided). For example in XE it would be
distribution.web.id=xwiki-enterprise-web
** ui extension id of the distribution (generate a default id like
<product-id>-ui when none is provided). For example in XE it would be
distribution.ui.id=xwiki-enterprise-ui
** then come custom properties specific to the distribution. For
example in XE I think we could add commons.version, rendering.version,
etc.
= The current informations
* store all that in a table of the DB to compare the current with what
comes with the war. If the DB does not contain anything its a new
install, if the DB contain something different it's an upgrade (note
that this also support downgrade or moving from one distribution to
another like XE -> XEM the same way). The idea is that we store theses
informations only when the installer/upgrader is fully passed or that
the user explicitly indicated tat he does not want to install or
upgrade anything so that if you only did part of it before restoring
you can come back and continue the install/upgrade process.
= The manager
* introduce a xwiki-platform-distribution to manipulate all that
= Some questions
1) "distribution" or "product" ?
2) reuse the same table where we currently store the DB version ?
I don't want to talk about the installed/upgrader UI itself for now,
it will be the subject of another mail. I would like to concentrate of
one step at a time since that's going to be pretty important system.
WDYT ?
The may goal that started this proposal is the installer/upgrader UI
but those as also very useful for different use case. Some lib could
want to know the version of platform or commons to choose what to do,
we will be able to add the id of the distribution itself and the war
extension as core extension to allow some extension to put it as
dependency, we will finally display a proper footer without putting
the distribution name in the XWikiPreferences.
Here is my +1.
1) my +1 goes to "distribution"
2) my +1 goes to another table to not mix different subjects
Thanks,
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs