On Tue, Aug 28, 2012 at 11:35 PM, Denis Gervalle <[email protected]> wrote: > On Tue, Aug 28, 2012 at 6:29 PM, Vincent Massol <[email protected]> wrote: > >> >> On Aug 28, 2012, at 6:04 PM, Marius Dumitru Florea < >> [email protected]> wrote: >> >> > On Tue, Aug 28, 2012 at 5:37 PM, Vincent Massol <[email protected]> >> wrote: >> >> >> >> On Aug 28, 2012, at 4:26 PM, Thomas Mortagne <[email protected]> >> wrote: >> >> >> >>> On Tue, Aug 28, 2012 at 4:20 PM, Vincent Massol <[email protected]> >> wrote: >> >>>> >> >>>> On Aug 28, 2012, at 3:44 PM, Thomas Mortagne < >> [email protected]> wrote: >> >>>> >> >>>>> On Tue, Aug 28, 2012 at 3:35 PM, Vincent Massol <[email protected]> >> wrote: >> >>>>>> >> >>>>>> On Aug 28, 2012, at 3:31 PM, Thomas Mortagne < >> [email protected]> wrote: >> >>>>>> >> >>>>>>> On Tue, Aug 28, 2012 at 3:23 PM, Thomas Mortagne >> >>>>>>> <[email protected]> wrote: >> >>>>>>>> On Tue, Aug 28, 2012 at 3:18 PM, Vincent Massol < >> [email protected]> wrote: >> >>>>>>>>> >> >>>>>>>>> On Aug 28, 2012, at 2:50 PM, Thomas Mortagne < >> [email protected]> wrote: >> >>>>>>>>> >> >>>>>>>>>> On Tue, Aug 28, 2012 at 1:37 PM, Vincent Massol < >> [email protected]> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>> On Aug 28, 2012, at 1:15 PM, Thomas Mortagne < >> [email protected]> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> Hi guys, >> >>>>>>>>>>>> >> >>>>>>>>>>>> I would like to modify a bit the Maven XAR plugin to add in >> the >> >>>>>>>>>>>> package.xml some extension related informations like the >> extension id >> >>>>>>>>>>>> and version at the very least. >> >>>>>>>>>>> >> >>>>>>>>>>> Why not package the pom.xml instead in META-INF/maven/* as >> it's done by the Maven JAR plugin? >> >>>>>>>>>> >> >>>>>>>>>> Because it's not supposed as part of XAR format by existing XAR >> >>>>>>>>>> parser, you will get an error because it will fail to parse it >> as a >> >>>>>>>>>> document. The proposal here is to use something that already >> exists, >> >>>>>>>>>> does not break anything and is very easy to do. >> >>>>>>>>> >> >>>>>>>>> I personally much prefer to add META-INF support over changing >> the package.xml format because it's much better aligned with all other >> formats like JAR, EAR, WAR, etc and with the way we handle JAR extensions. >> >>>>>>>> >> >>>>>>>> I think you don't understand what I mean here. The issue is not >> that >> >>>>>>>> it's complex to support it, adding support in 4.2 for META-INF >> will >> >>>>>>>> not change the fact that you will get an error in older version >> with >> >>>>>>>> your XAR. >> >>>>>>>> >> >>>>>>>>> >> >>>>>>>>> It doesn't look complex to add either, it's a matter of >> excluding META-INF files from the parser and to use the Maven Archiver (see >> http://maven.apache.org/shared/maven-archiver/). >> >>>>>>> >> >>>>>>> Making the XAR format depends on Maven is not exactly something >> >>>>>>> generic or even very nice. Core extension scanner is looking at the >> >>>>>>> pom located in jar file among other things in order to find as >> much as >> >>>>>>> it can but lets not forget that this is a hack and nothing else. >> >>>>>> >> >>>>>> Whatever the solution we need consistency IMO. If your proposal is >> to create an extension.xml file located in META-INF/xwiki and that we would >> put in all our extension types then I'm all for it too. >> >>>>>> >> >>>>>> I don't like mixing extension information with packaging >> information. For me package.xml shouldn't contain extension information. >> >>>>> >> >>>>> It's exactly the same thing. The package.xml file is the XAR way to >> >>>>> provide informations about the file and is generated from the >> pom.xml. >> >>>>> It already provide the a subset of extension informations (name, >> >>>>> version, license, etc.) so the proposal here is about adding more >> >>>>> things. >> >>>> >> >>>> For me the package.xml should probably even be removed or at least a >> lot of information should be removed. There's no point in listing the files >> explicitly for example. Same for whether it's a backup pack or not. >> >>>> >> >>>> And a lot of the information currently in package.xml should be moved >> to META-INF/xwiki/extension.xml such as author, license, version, name, >> description. >> >>>> >> >>>> So I'm definitely with you about creating a XWiki-specific descriptor >> (not tied to maven) located in META-INF/xwiki/extension.xml for all our >> extensions, but beefing up package.xml goes in the wrong direction IMO. >> >>>> >> >>>> At the very least I'd like that we agree about where we'd like to go >> (I've made a proposal with META-INF/xwiki/extension.xml) and then discuss >> how to get there and what it takes. If it means going through intermediary >> steps, then fine, the important part for me being to agree on where we want >> to go. >> >>> >> >>> Maybe but that's a different subject and IMO it sounds like creating a >> >>> new packaging format for wiki pages. >> >> >> >> There are 2 topics: >> >> * Create a generic format for all xwiki extensions (the >> META-INF/xwiki/extension.xml), nothing to do with wiki pages >> >> * Modify the existing XAR format descriptor (package.xml) to remove >> stuff that are 1) not needed (like the list of files and 2) can be found in >> the extension information (i.e. in META-INF/xwiki/extension.xml) >> >> >> >> So far you/we have decided that the xwiki extension format will be the >> pom.xml format which is why we are using it in our JAR file to discover >> extensions. Based on that it's not logical to invent a new way to add >> extension information even if the existing package.xml contains already >> some information that happens (by pure coincidence) to be the same as the >> one needed by the extension manager (for ex the version in package.xml >> could be a completely different version than the extension version). >> >> >> >> Based on this the logic is to add the pom.xml file to the XAR. >> >> >> >> Now you said that you didn't think using the Maven format is good. >> Fine. This is a change from what we had decided so far and I'm ready to >> accept that we may want to dissociate from Maven; hence my proposal about >> the META-INF/xwiki/extension.xml file. >> >> >> >> So we have 2 choices for me: >> >> * continue with the current rule of using pom.xml files as containing >> extension information >> >> * decide to bite the bullet and invent a new format for holding >> extension information >> >> >> >> Those are the 2 *good* choices for me. Ofc we need to handle backward >> compat as best as we can but that's doable. >> >> >> >> You'd like to do the 3rd choice which IMO is a quick and dirty >> solution. I'd accept it but only as a quick hack for 4.2 and that we would >> need to correct ASAP. >> >> >> >>> I need something for 4.2 and >> >>> adding the id in package.xml along with the other existing extension >> >>> informations is quick, easy, fully retro compatible and does not >> >>> really introduce anything new. >> >> >> >> Sure but it does introduce something new: the new information you add >> to package.xml. And this is exactly like a public API; once it's there we >> have to support it and be retro compatible. So we have to be careful >> because it's a pain to change after. >> >> >> > >> >> I'm curious to know what others think about this. >> > >> > Thomas is proposing to add some new _optional_ information to the XAR >> > _descriptor_. If I understood correctly, you don't think the XAR >> > descriptor is the right place and you propose instead to use a >> > separate file. More over, you'd like that all supported extension >> > types use this file. In other words, you don't want the extension >> > manager to extract information from the descriptor specific to the >> > extension type but from a different file within that extension. I >> > think this has two problems in general: >> > >> > * we need to add support for this separate file for each type of >> > extension (we control the code of XAR packager but this might not be >> > the case with other types of extension that we'd want to support in >> > the future) >> >> It's quite the opposite. Right now, for JAR extensions stored in a Maven >> Repository we extract information from the META-INF/maven/.../pom.xml file. >> We don't control that at all since it's put there by Maven and in a >> Maven-controlled format (which we extend by adding Maven pom properties). >> >> As I've said a few times in this thread, I'm fine to standardize on the >> Maven POM format. I'm also fine to have our own format (I called it >> META-INF/xwiki/extension.xml). If we have our own format then we do control >> it. >> >> Also if we use the same strategy for all extensions (be them JAR or XAR) >> the it's the opposite to what you say: we need only to implement to logic >> to read META-INF/xwiki/extension.xml once whereas now we need a different >> logic for each type: >> * for JAR we read from the META-INF/maven/.../pom.xm >> * for XAR we read from package.xml >> >> > * the dedicated file will most probably duplicate information from the >> > native descriptor (pom.xml, package.xml, etc.) >> >> Yes that's true for pom.xml but it doesn't really matter. We have 2 >> choices: >> - standardize on the pom.xml format >> - use our own format >> > > Vincent, either I have missed something, or you have, but I do not > understand how you expect to manage all the maven dependencies that we > currently importing as dependencies of our extensions, if you choose to > have our own metadata format only ? > > For package.xml it wouldn't be true because we wouldn't keep the same >> information in 2 places. We would have it in extension.xml and not in >> package.xml which would either disappear (not needed) or contain some >> XAR-specific config options, or (third option) we would allow to provide >> generic properties in our extension.xml format and the XAR extension type >> would have whatever it needs in there. >> >> > I'm still +1 for what Thomas proposed. >> >> What I've discussed in this thread is how I view this ideally. Thomas' >> proposal is ok for the short term (4.2) without breaking anything existing. >> >> > Once again, IMO, the way extension are stored, and the way the information > about these extensions are provided to the EM, only depends on the > repository they came from. Extension stored in a maven repository will have > to use the maven way, and therefore store their extension related > information in their pom.xml. Extension coming from other repository may > have other method to provide the same information or not. It is up to the > repository. > > The problem of Thomas relate to how standalone XAR could be seen as > extension and registered in the EM when these XAR are imported from outside > EM, and therefore being not installed from a repository. I have seen this > as an edge case, similar to how we register built-in extension installed in > the lib folder. > > What you to talk about, is to have a more generic way to support these > standalone extensions, but you seems to apply it globally to all extensions. > > IMO, you could not expect or impose that all extension coming from a Maven > repository conform to a unique way of containing meta information, since > these extensions may have been extracted from different repositories. This > would require all built-in jar and all dependencies to be repackaged > properly with the needed metadata, which would simply be counter > productive. This would also reduce the flexibility of the current system. > So, if you really want that, using pom.xml is your only choice.
Yes we don't care a bit what the hell is stored in the file when the extension comes from a repository. Providing metadata is the repository job and it does that in its own format (pom.xml for Maven Repository, custom REST protocoal for XWiki Repository and many others for other kind of reposirories) and that's the only standard for real extensions you install from Extension Manager UI. > > That said, having a standardized, standalone packaging of extension, > independent of a repository, is something that we should think about, and > in that context, your proposal and remarks make sense to me. > > >> When you say you're +1 do you mean you're +1 for now for 4.2 or even more >> generally in the future as the right solution? >> > > I am +1 for now and later, that extension package stored as a standalone > XAR, use the package.xml to store additional information denoting this XAR > to be a special extension XAR. It will helps current issues quickly without > breaking anything and it does not prevent to develop later a standalone > packaging for any kind of extension, that provide extension information in > a more common way. > > WDYT ? Have I misunderstood the situation ? You perfectly understood the situation. > > >> >> Thanks >> -Vincent >> >> > Thanks, >> > Marius >> > >> >> >> >> Thanks >> >> -Vincent >> >> >> >>>> Thanks >> >>>> -Vincent >> >>>> >> >>>>>> Thanks >> >>>>>> -Vincent >> >>>>>> >> >>>>>>>>> Thanks >> >>>>>>>>> -Vincent >> >>>>>>>>> >> >>>>>>>>>>> It would be more generic and similar to how JARs are handled. >> >>>>>>>>>>> >> >>>>>>>>>>> Thanks >> >>>>>>>>>>> -Vincent >> >>>>>>>>>>> >> >>>>>>>>>>>> The idea is to be able to know what a XAR is exactly like we >> have the >> >>>>>>>>>>>> pom.xml packaged with the jar file for example. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Among other things it will cover the following use cases: >> >>>>>>>>>>>> * when someone import a XAR with the standard UI, >> automatically >> >>>>>>>>>>>> register it in the extension index if it happen to be an >> extension >> >>>>>>>>>>>> (i.e. if we find extension informations in its package.xml) >> >>>>>>>>>>>> * wiki manager and workspaces can properly register actual >> extension >> >>>>>>>>>>>> when creating their default template from a XAR the first >> time (this >> >>>>>>>>>>>> is for example required to be able to upgrade a farm with EM >> where >> >>>>>>>>>>>> pretty much all the wiki as been created from this default >> template) >> >>>>>>>>>>>> >> >>>>>>>>>>>> In both cases the idea is to support as much current >> behaviours as we >> >>>>>>>>>>>> can and still be able to use the full power of Extension >> Manager. >> >>>>>>>>>>>> >> >>>>>>>>>>>> There should not be any backward compatibility issue here >> since it >> >>>>>>>>>>>> does not really change anything in the XAR structure. >> >>>>>>>>>>>> >> >>>>>>>>>>>> WDYT ? >> >>>>>>>>>>>> >> >>>>>>>>>>>> Here is my +1 >> _______________________________________________ >> 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
