16 Jun
2012
16 Jun
'12
10:05 a.m.
On Fri, Jun 15, 2012 at 7:18 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
--
Thomas Mortagne
On Fri, Jun 15, 2012 at 12:26 PM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com
This comparison does not make any sense. It's like saying a browser
should not know its own version to be sure it's not going to indicate
it.
If you had read my mail more carefully you would have seen one example
I gave: "among other things it allows to check for available updates".
This is one of the perfectly valid use case for wanting to know what
is the distribution and there is others I'm sure. For example right
now by default you get the distribution name and version in the footer
and this is done by putting it in the name in XWikiPreferences page at
build time which could hardly be worst. It will also make the
version.properties useless and all the build configuration to generate
it since you will get a generic API to get the version of the
distribution and also any extension like you can do already.
wrote:
Hi devs,
Since I got some veto on http://markmail.org/message/feavtmfokcsaalpo
lets cut all that in small peaces.
The today's episode is about finding what is the war we are running it
at runtime to list it in the core extensions (among other things it
allows to check for available updates).
Like the JAR packages, a WAR contains pom.xml file, problem is that
this pom.xml file is not in a "stable" location
(META-INF/<groupId>/<artifactId>/pom.xml) and I can't find any generic
way to scan a WAR like Reflection allows to scan jars files from the
classpath.
So as a last resort solution I propose to include the extension
identifier in the METAINF.MF at build time. This will give me the
entry point I need to find the pom.xml and gather more detailed
informations about the war to put it as core extension.
WDYT ?
Currently, I do not really see what it changes compare to our previous
thread.
Let me try to better explains myself with a similar example from another
domain.
In Javascript, you sometime needs to detect in which browser you are
running in, and we all know that this is bad.
The good way to do is to detect available features, and not the browser as
a whole.
I see the war here as the browser, and the deployed jars/xars as the
available features. Providing a way to know which was the initial WAR
deployed, is therefore encouraging the bad way to know what features are
available. This is even worse than in the browser detection, since XWiki is
really modular, and you can install a XEM war, but setup XE over it. So, I
really do not understand currently why you really want to better know on
which WAR you are running ?
Moving further in the future, we may expect to have a single minimal WAR,
and a bunch of extentions choosen freely by the user, using something
similar to a linux setup, using recommended groups of extensions to build
Linux is not a good example for what you are trying to say. Many
distributions like Ubuntu to cite just one have the concept of
distribution as a whole with version and distribution upgrade.
XWiki well suited for this or that purpose. And
therefore, the WAR will
completely loose its meaning. IMO, currently, a WAR is simply the minimal
core, and a pre-selected set of extensions, just to ease an initial setup.
After being deployed, it loose its meaning completely, and could fully
changed. I know that these "core" extensions are installed for ever, but
this more a limitation than a feature, except for the minimal needed set.
Please lets do things one step at a time. Also don't assume that the
future is settled, I still don't agree with you that it is a good
thing to completely loose the concept of XWiki distribution that you
can upgrade etc.
It's not like I was proposing a very complex thing that is going to
make XWiki stuck for any evolution of the architecture, it's just
adding one perfectly valid information to the MANIFEST.MF file. This
is not something built at the hearth of extension manager that you are
running in a WAR, it's just one more information when this information
is available. It will not change anything at all in the way to deal
with extensions in general.
Could you explain why you really want to give that initial set of
extensions some properties as a whole ? or am I missing something
fundamental ?
Where did I said exactly that I want to replace the list of core
extensions by the single WAR entry ? The goal is not to make all
extensions put the war as dependency instead of the proper core
extensions but to provide an information that should be provided
simply because it exists and can be useful.
The fear that a bad developer will put XWiki Enterprise 4.0 as
dependency instead of listing the actual modules his extension needs
should not prevent us to provide this information for other needs than
dependency resolution.
+1
--
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