On May 19, 2010, at 7:49 AM, Caleb James DeLisle wrote: > +1 The plan sounds good based on the small research I did earlier. > > I like using/adapting the current component manager (at least for now) > because it is small and easy to understand. As I understand OSGi and > 299 implementations are large with more to go wrong or introduce security > problems so converting should be taken with some caution. > > A little clarification: > Adding an extension will require PR?
No, I don't think this is needed (except for pages requiring PR obviously but we should have some warning when importing these pages). > XARs will be dependent on other XARs? Yes, if a page in one XAR requires a page from another XAR to work. The general mechanism is not fully defined yet but one idea is to have a special "virtual" artifact for each application and its pom would have dependencies on XAR files and jar libraries. > Will the dependencies be automatically downloaded? Yes, transitively. > Is this something for farther in the future? Nope, this is for step 1. Thanks -Vincent > Caleb > > > > > Vincent Massol wrote: >> Hi devs, >> >> I've explored enough of OSGi to get a handle of how it works and what it >> would mean to use it for XWiki as the basis for our Extension Manager >> (Thomas helped me with this too). >> >> The executive summary is that I don't think we need to use OSGi right now >> for the Extension Manager and we can defer its usage for later. >> >> Let me start by listing what would OSGi bring for XWiki: >> 1) Known framework with good documentation, books, etc >> 2) Users would be able to write extensions using OSGi programming model >> (without using XWiki's programming model), this also means the ability to >> reuse OSGi bundles inside XWiki >> 3) ClassLoader isolation and thus ability to have several versions of classes >> 4) OBR (Bundle Repository) for downloading and installing remote jars >> >> Now here are the problems found with OSGi so far: >> A) Impedance mismatch with the webapp/WAR model (classloader and visibility >> issues). Two examples: >> - it would mean having a special directory somewhere, where to put the >> bundles, and this means not going through the standard WAR deployment >> process. >> - if we want to keep WEB-INF/lib in order to have a standard WAR deployment >> then it would mean keeping for ex the core jars in WEB-INF/lib and using >> OSGi only for extensions. However doing this is not really possible since it >> would mean extension (OSGi bundles) would have Imports on core classes but >> this won't work since core classes won't be OSGi bundles >> B) In practice it's very hard to use OSGi with only a part of the modules >> being OSGi bundles and another part being standard external libraries. >> Everything must be OSGified for it to work well. >> >> In addition we might want not need the features listed above: >> 1) Not really needed especially since we have the XWiki programming model >> that we don't want to loose right now >> 2) is a nice to have but not a requirement for the Extension Manager >> 3) in practice it's going to be very hard to support multiple versions of >> classes. Imagine for example an application A which is providing a macro in >> a wiki page. Application B requires version 1.0 of A and application C >> requires version 2.0 of A. How do we support that? OSGi won't help here >> since this is about wiki pages. It's only helping for jars. The jar >> isolation could also easily be implemented using a custom URL classloader >> without too much problem IMO, but I'm inclined to say that we don't need to >> support multiple versions in a first version of the Extension Manager. > Also it sounds like a permgen nightmare. > >> 4) We can easily use the Maven 3 Embedder to download and install maven >> artifacts into a local repository. This is convenient since we already >> deploy our applications/modules to a maven repository. Note that the only >> "difficult" part here might be searching into a remote repository; I don't >> know if a maven api exists for this (but probably). In the worst of cases we >> could use the Nexus REST API to provide this feature for now. >> >> And here's what I think we should do right now: >> i) focus on the 2 features we need for the Extension Manager: >> -- ability to install an application containing not only wiki pages but also >> jars >> -- ability to install an application from a remote repository >> ii) then once i) is done focus on the upgrade part of the extension manager >> >> Implementation note: >> - To implement i) we can do this easily I believe using a custom URL >> ClassLoader (we already have one btw used in the script macro) that we pass >> to the Component Annotation Loader when a new JAR is installed (in order to >> register the components in that jar) + set that custom URL ClassLoader as >> the new thread context classloader (for code that would use the thread >> context classloader to load classes). >> >> WDYT? >> >> Thanks >> -Vincent >> >> PS: I'd be interested to hear from OSGi experts what they have to say about >> this since I'm an OSGi newbie and there might be stuff I have not >> seen/realized. >> PPS: I'm just realizing that the proposal in this mail is close to >> Pomegranate's idea: http://www.caucho.com/projects/pomegranate/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
