[xwiki-devs] [VOTE] Add extension id in the MANIFEST.MF in WAR distributions
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 ? +1 -- Thomas Mortagne
+1 On Fri, Jun 15, 2012 at 12:26 PM, Thomas Mortagne <[email protected]
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 ?
+1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/
On Fri, Jun 15, 2012 at 12:26 PM, Thomas Mortagne <[email protected]> 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.
See http://jira.xwiki.org/browse/XWIKI-7895 for more details.
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 ?
+1 -- Thomas Mortagne
-- Thomas Mortagne
On 06/15/2012 06:26 AM, Thomas Mortagne 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 ?
+1
+1 -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Fri, Jun 15, 2012 at 12:26 PM, Thomas Mortagne <[email protected]
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 a 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. 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 ?
+1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Fri, Jun 15, 2012 at 7:18 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Jun 15, 2012 at 12:26 PM, Thomas Mortagne <[email protected]
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 ?
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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Sat, Jun 16, 2012 at 10:05 AM, Thomas Mortagne <[email protected]
wrote:
On Fri, Jun 15, 2012 at 7:18 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Jun 15, 2012 at 12:26 PM, Thomas Mortagne < [email protected]
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 ?
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.
Finally, trying to make analogy to clarify my point does not make it :( There is absolutely no issue with putting somewhere the version of the core, but this is for me completely different to put in the distribution.
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".
I had read it carefully ! So the only goal would be to automate the update of the war itself ? Not sure to know if this could be done, but you may have a better view than I have on this specific point. I do not see the exact relation with EM however. So, if your goal is to build a war upgrade procedure, when the war has been the deployment method, than you have probably the only valid use case IMO, and you have my agreement, but this is really lot of work for a very simple admin procedure for which containers already provide an interface.
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
Really curious to know about other valid usages, and in particular, to know how to avoid bad one.
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.
AFAIK, we have only 2 distributions, XE and XEM, and the difference between these two wars are really small. This is probably mainly why I do not understand your goals. Writing the distribution next to the version is not so easy since you may setup the XEM war and finally use it as you would use XE. or the reverse.
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.
I was not referring to distributions, but to the way dselect provided a presets features for different purposes. Which only append at initial setup, but does not persist later. Upgrading later, is only based on installed packages.
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.
Ok, maybe you should currently explains me what is the advantages of the two distributions we have. I have already found this so confusing, because you can so easily switch from one to the other without reinstallation.
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
This exactly the meaning of what you want to add that I do not understand.
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.
If the information as no meaning, it would be useless. So what is the meaning of that information ? XE and XEM are so similar, and each could be turned into the other one with very simple configuration changes. So I do not understand the meaning of the information you are adding, and for which use case it is valid to be used. 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.
No fear of that, only of the meaning and usage intended for the information you were adding.
+1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Sat, Jun 16, 2012 at 2:29 PM, Denis Gervalle <[email protected]> wrote:
On Sat, Jun 16, 2012 at 10:05 AM, Thomas Mortagne <[email protected]
wrote:
On Fri, Jun 15, 2012 at 7:18 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Jun 15, 2012 at 12:26 PM, Thomas Mortagne < [email protected]
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 ?
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.
Finally, trying to make analogy to clarify my point does not make it :( There is absolutely no issue with putting somewhere the version of the core, but this is for me completely different to put in the distribution.
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".
I had read it carefully ! So the only goal would be to automate the update of the war itself ? Not sure to know if this could be done, but you may have a better view than I have on this specific point. I do not see the exact relation with EM however.
All it cost right now and the only thing this vote is about is to indicate in the METAINF.MF what is it exactly, it's one line. That's exactly what METAINF.MF is for and IMO Maven itself should even put those informations but it's no unfortunately. I'm not even proposing to introduce some custom distribution file... It also allow to remove the custom version.properties files which will be made useless since we will get all informations we need from the pom like we do with any core extension jar. Said another way it's about knowing what is the distribution and not just what is the distribution version.
So, if your goal is to build a war upgrade procedure, when the war has been the deployment method, than you have probably the only valid use case IMO, and you have my agreement, but this is really lot of work for a very simple admin procedure for which containers already provide an interface.
I don't understand what you mean, tomcat is never going to tell you that there is a new version of XE. I appreciate your concern on the the work to do but that's not what I'm asking. All I'm asking is if everyone OK with the way I plan to extract distribution related informations.
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
Really curious to know about other valid usages, and in particular, to know how to avoid bad one.
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.
AFAIK, we have only 2 distributions, XE and XEM, and the difference between these two wars are really small.
XWiki ecosystem is not just about what's in https://github.com/xwiki/. Here hare several examples of distributions of XWiki I know about with they own versions and customizations: * XWiki Cloud * Curriki * Nearbee And there is lots of others I never heard about. Even if we were proposing only one distribution in https://github.com/xwiki/ we would still don't know anything about it at platform level which mean we can't suggest the default corresponding XAR to install for it to be complete, we can't check and warn the admin that there is a new version etc. I really don't see what you don't understand in the fact that we need to know what is the distribution before doing distribution related actions.
This is probably mainly why I do not understand your goals. Writing the distribution next to the version is not so easy since you may setup the XEM war and finally use it as you would use XE. or the reverse.
I don't really care that you customized a XE and installed some extensions to manager wikis, your distribution will still be XE and what you will get is XE related informations. All the rest is extensions.
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.
I was not referring to distributions, but to the way dselect provided a presets features for different purposes. Which only append at initial setup, but does not persist later. Upgrading later, is only based on installed packages.
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.
Ok, maybe you should currently explains me what is the advantages of the two distributions we have. I have already found this so confusing, because you can so easily switch from one to the other without reinstallation.
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
This exactly the meaning of what you want to add that I do not understand.
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.
If the information as no meaning, it would be useless. So what is the meaning of that information ? XE and XEM are so similar, and each could be turned into the other one with very simple configuration changes. So I do not understand the meaning of the information you are adding, and for which use case it is valid to be used.
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.
No fear of that, only of the meaning and usage intended for the information you were adding.
The whole idea is to extract as much informations as we can from the currently installed stuff to make admin life easier and allow to propose distribution related actions. If you can't admit that we do have official distributions (even if it was only XE) and that 99% of the users don't choose the jars/resources themself one by one to create their own WAR or whatever other way of packaging I can't really say much more. What I propose if something that allow to manage distributions and that obviously also work if you don't have any declared distribution, you will just not get any distribution related informations.
+1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
I think one way of seeing things is that a war is not only a collection of jars which are easily (un)installable/upgradable with the EM. If we don`t do this, we have no way of updating the velocity templates for example, or the filesystem skin, or js resources, etc. Each distribuion could have its own customization of these things that it might like to upgrade. Without what Thomas is proposing, from what I can tell, we can only upgrade jars and wiki pages. +1 Thanks, Eduard On Mon, Jun 18, 2012 at 12:31 PM, Thomas Mortagne <[email protected]
wrote:
On Sat, Jun 16, 2012 at 2:29 PM, Denis Gervalle <[email protected]> wrote:
On Sat, Jun 16, 2012 at 10:05 AM, Thomas Mortagne < [email protected]
wrote:
On Fri, Jun 15, 2012 at 7:18 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Jun 15, 2012 at 12:26 PM, Thomas Mortagne < [email protected]
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 ?
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.
Finally, trying to make analogy to clarify my point does not make it :( There is absolutely no issue with putting somewhere the version of the core, but this is for me completely different to put in the distribution.
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".
I had read it carefully ! So the only goal would be to automate the update of the war itself ? Not sure to know if this could be done, but you may have a better view than I have on this specific point. I do not see the exact relation with EM however.
All it cost right now and the only thing this vote is about is to indicate in the METAINF.MF what is it exactly, it's one line. That's exactly what METAINF.MF is for and IMO Maven itself should even put those informations but it's no unfortunately. I'm not even proposing to introduce some custom distribution file...
It also allow to remove the custom version.properties files which will be made useless since we will get all informations we need from the pom like we do with any core extension jar. Said another way it's about knowing what is the distribution and not just what is the distribution version.
So, if your goal is to build a war upgrade procedure, when the war has been the deployment method, than you have probably the only valid use case IMO, and you have my agreement, but this is really lot of work for a very simple admin procedure for which containers already provide an interface.
I don't understand what you mean, tomcat is never going to tell you that there is a new version of XE.
I appreciate your concern on the the work to do but that's not what I'm asking. All I'm asking is if everyone OK with the way I plan to extract distribution related informations.
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
Really curious to know about other valid usages, and in particular, to
know
how to avoid bad one.
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.
AFAIK, we have only 2 distributions, XE and XEM, and the difference between these two wars are really small.
XWiki ecosystem is not just about what's in https://github.com/xwiki/.
Here hare several examples of distributions of XWiki I know about with they own versions and customizations: * XWiki Cloud * Curriki * Nearbee
And there is lots of others I never heard about.
Even if we were proposing only one distribution in https://github.com/xwiki/ we would still don't know anything about it at platform level which mean we can't suggest the default corresponding XAR to install for it to be complete, we can't check and warn the admin that there is a new version etc. I really don't see what you don't understand in the fact that we need to know what is the distribution before doing distribution related actions.
This is probably mainly why I do not understand your goals. Writing the distribution next to the version is not so easy since you may setup the XEM war and finally use it as you would use XE. or the reverse.
I don't really care that you customized a XE and installed some extensions to manager wikis, your distribution will still be XE and what you will get is XE related informations. All the rest is extensions.
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.
I was not referring to distributions, but to the way dselect provided a presets features for different purposes. Which only append at initial setup, but does not persist later. Upgrading later, is only based on installed packages.
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.
Ok, maybe you should currently explains me what is the advantages of the two distributions we have. I have already found this so confusing, because you can so easily switch from one to the other without reinstallation.
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
This exactly the meaning of what you want to add that I do not understand.
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.
If the information as no meaning, it would be useless. So what is the meaning of that information ? XE and XEM are so similar, and each could be turned into the other one with very simple configuration changes. So I do not understand the meaning of the information you are adding, and for which use case it is valid to be used.
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.
No fear of that, only of the meaning and usage intended for the information you were adding.
The whole idea is to extract as much informations as we can from the currently installed stuff to make admin life easier and allow to propose distribution related actions. If you can't admit that we do have official distributions (even if it was only XE) and that 99% of the users don't choose the jars/resources themself one by one to create their own WAR or whatever other way of packaging I can't really say much more.
What I propose if something that allow to manage distributions and that obviously also work if you don't have any declared distribution, you will just not get any distribution related informations.
+1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Le lundi 18 juin 2012, Thomas Mortagne a écrit :
On Sat, Jun 16, 2012 at 2:29 PM, Denis Gervalle <[email protected]<javascript:;>> wrote:
On Sat, Jun 16, 2012 at 10:05 AM, Thomas Mortagne < [email protected] <javascript:;>
wrote:
On Fri, Jun 15, 2012 at 7:18 PM, Denis Gervalle <[email protected]<javascript:;>> wrote:
On Fri, Jun 15, 2012 at 12:26 PM, Thomas Mortagne < [email protected] <javascript:;>
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 ?
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.
Finally, trying to make analogy to clarify my point does not make it :( There is absolutely no issue with putting somewhere the version of the core, but this is for me completely different to put in the distribution.
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".
I had read it carefully ! So the only goal would be to automate the update of the war itself ? Not sure to know if this could be done, but you may have a better view than I have on this specific point. I do not see the exact relation with EM however.
All it cost right now and the only thing this vote is about is to indicate in the METAINF.MF what is it exactly, it's one line. That's exactly what METAINF.MF is for and IMO Maven itself should even put those informations but it's no unfortunately. I'm not even proposing to introduce some custom distribution file...
It also allow to remove the custom version.properties files which will be made useless since we will get all informations we need from the pom like we do with any core extension jar. Said another way it's about knowing what is the distribution and not just what is the distribution version.
+1
So, if your goal is to build a war upgrade procedure, when the war has been the deployment method, than you have probably the only valid use case IMO, and you have my agreement, but this is really lot of work for a very simple admin procedure for which containers already provide an interface.
I don't understand what you mean, tomcat is never going to tell you that there is a new version of XE.
I appreciate your concern on the the work to do but that's not what I'm asking. All I'm asking is if everyone OK with the way I plan to extract distribution related informations.
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
Really curious to know about other valid usages, and in particular, to
know
how to avoid bad one.
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.
AFAIK, we have only 2 distributions, XE and XEM, and the difference between these two wars are really small.
XWiki ecosystem is not just about what's in https://github.com/xwiki/.
Here hare several examples of distributions of XWiki I know about with they own versions and customizations: * XWiki Cloud * Curriki * Nearbee
And there is lots of others I never heard about.
Even if we were proposing only one distribution in https://github.com/xwiki/ we would still don't know anything about it at platform level which mean we can't suggest the default corresponding XAR to install for it to be complete, we can't check and warn the admin that there is a new version etc. I really don't see what you don't understand in the fact that we need to know what is the distribution before doing distribution related actions.
This is probably mainly why I do not understand your goals. Writing the distribution next to the version is not so easy since you may setup the XEM war and finally use it as you would use XE. or the reverse.
I don't really care that you customized a XE and installed some extensions to manager wikis, your distribution will still be XE and what you will get is XE related informations. All the rest is extensions.
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.
I was not referring to distributions, but to the way dselect provided a presets features for different purposes. Which only append at initial setup, but does not persist later. Upgrading later, is only based on installed packages.
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.
Ok, maybe you should currently explains me what is the advantages of the two distributions we have. I have already found this so confusing, because you can so easily switch from one to the other without reinstallation.
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
This exactly the meaning of what you want to add that I do not understand.
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.
If the information as no meaning, it would be useless. So what is the meaning of that information ? XE and XEM are so similar, and each could be turned into the other one with very simple configuration changes. So I do not understand the meaning of the information you are adding, and for which use case it is valid to be used.
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.
No fear of that, only of the meaning and usage intended for the information you were adding.
The whole idea is to extract as much informations as we can from the currently installed stuff to make admin life easier and allow to propose distribution related actions. If you can't admit that we do have official distributions (even if it was only XE) and that 99% of the users don't choose the jars/resources themself one by one to create their own WAR or whatever other way of packaging I can't really say much more.
This just that war are not a single entity, it could be modified on the way. So, all I was saying is that the information you get is not really useful in all cases. We should check for feature to upgrade more than distribution when possible. But for now, I agree, go ahead.
What I propose if something that allow to manage distributions and that obviously also work if you don't have any declared distribution, you will just not get any distribution related informations.
+1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] <javascript:;> http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] <javascript:;> http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] <javascript:;> http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] <javascript:;> http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] <javascript:;> http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Jun 15, 2012, at 12:26 PM, Thomas Mortagne 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 ?
So this means that we put our extension ids in META-INF/MANIFEST.MF to have self-describing extensions. That seems a good idea to me. It also allows to recognize if a given artifact is a xwiki extension or not. Thanks -Vincent
On Tue, Jun 19, 2012 at 10:34 AM, Vincent Massol <[email protected]> wrote:
On Jun 15, 2012, at 12:26 PM, Thomas Mortagne 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 ?
So this means that we put our extension ids in META-INF/MANIFEST.MF to have self-describing extensions.
That seems a good idea to me. It also allows to recognize if a given artifact is a xwiki extension or not.
Yes I tough it was a nice information to add to the META-INF/MANIFEST.MF for all sort of uses cases anyway.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (6)
-
Denis Gervalle -
Eduard Moraru -
Jerome Velociter -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol