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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
