12 Apr
2012
12 Apr
'12
9:28 a.m.
On Wed, Apr 11, 2012 at 7: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
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.
I like this idea. We could also trigger the check on specific events
(like application start) or even allow the user to trigger the check
manually.
Thanks,
Marius
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.
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.
Hope you get my idea. I am available to discuss this more in depth if you
need further clarification.
Thanks,
On Fri, Apr 6, 2012 at 09:49, Thomas Mortagne <thomas.mortagne(a)xwiki.com>wrote;wrote:
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