[xwiki-devs] [Discussion] OSGi POC result and base for the Extension Manager
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. 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/
On May 18, 2010, at 7:24 PM, 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. 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).
Also note that having a single classloader for the moment solves the problem of having a wiki page using script macros to access classes located in extensions. With classloader isolation it's more complex and we would need something like {{script extension="extensionid"/}} so that the extension's classloader is used when evaluating the script macro. Thanks -Vincent
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/
On Tue, May 18, 2010 at 19:24, Vincent Massol <[email protected]> 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. 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?
Surprisingly I'm +1 ;)
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/
Indeed Pomegranate sounds good if we can use it outside of Resin.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On May 18, 2010, at 10:39 PM, Thomas Mortagne wrote:
On Tue, May 18, 2010 at 19:24, Vincent Massol <[email protected]> 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. 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?
Surprisingly I'm +1 ;)
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/
Indeed Pomegranate sounds good if we can use it outside of Resin.
There are 3 problems: 1) it's not available separately, you can only get it as part of Resin 4.x sources 2) the sources are under GPL 3) I'm not sure it can be used as is; I think the container has to integrate with it at its classloader level Thanks -Vincent
+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? XARs will be dependent on other XARs? Will the dependencies be automatically downloaded? Is this something for farther in the future? 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
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/
Hi Vincent Here are some comments inlined... Le 18/05/2010 19:24, Vincent Massol a écrit :
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
As OSGi use the service layer (µservice as we should say now) to interoperate, everything that is service can talk with another service. It doesn't matter if your µservice was produced by hand, with iPOJO, Blueprint (any OSGi component model you want). So if the XWiki programming model produces/consume µservices other µservices can be used too, they just have to conform to the µservice API/Interface.
3) ClassLoader isolation and thus ability to have several versions of classes 4) OBR (Bundle Repository) for downloading and installing remote jars
OBR is not something that will help to download and install remote bundles. With a "naked" gateway, you can always download and install remote bundles (http://....). The goal of OBR is to help installling a *set* of bundles with dependencies between them. For example, if Bundle A depends on Bundle B, you should have to manually download and install 2 Bundles. With OBR, you just "say": "I want A installed" and B will be installed too.
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
In that case, It's possible to have the webapp launching an OSGi gateway. You could have the core classes in the WEB-INF/lib/*.jar (or WEB-INF/classes) and have a selected set of packages (from the core) exported by the gateway (through the System Bundle). So your extensions (standard bundles) can use the packages from the core. The only thing you cannot do with that case is to update the core classes (since they are not really in a bundle, but considered as part of the JDK packages).
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.
You're absolutely right, it's easier when everything is OSGified.
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.
Agree, OSGi will help you to bind a bundle to an exported package using a specified version (may be a version range). If what you produce is a wiki page, not some java code, it will be more difficult to requires a given package version... As OSGi targets Java, it's more usable (and there are more tools available) if you write directly Java code: Bnd can automatically deduce your imports and service-oriented component models handles dynamic service dependencies for you. Cheers --Guillaume
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
On May 19, 2010, at 2:02 PM, Guillaume Sauthier wrote:
Hi Vincent Here are some comments inlined...
Le 18/05/2010 19:24, Vincent Massol a écrit :
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
As OSGi use the service layer (µservice as we should say now) to interoperate, everything that is service can talk with another service. It doesn't matter if your µservice was produced by hand, with iPOJO, Blueprint (any OSGi component model you want).
yep
So if the XWiki programming model produces/consume µservices other µservices can be used too, they just have to conform to the µservice API/Interface.
yep
3) ClassLoader isolation and thus ability to have several versions of classes 4) OBR (Bundle Repository) for downloading and installing remote jars
OBR is not something that will help to download and install remote bundles. With a "naked" gateway, you can always download and install remote bundles (http://....). The goal of OBR is to help installling a *set* of bundles with dependencies between them. For example, if Bundle A depends on Bundle B, you should have to manually download and install 2 Bundles. With OBR, you just "say": "I want A installed" and B will be installed too.
Yes, that's actually what I meant by "installing remote jars" (the jars + their deps) but I should have been more explicit :)
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
In that case, It's possible to have the webapp launching an OSGi gateway. You could have the core classes in the WEB-INF/lib/*.jar (or WEB-INF/classes) and have a selected set of packages (from the core) exported by the gateway (through the System Bundle). So your extensions (standard bundles) can use the packages from the core.
Yes that could be done. We'd need to use the Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA config property and manually list all packages (this is a pain!). I guess an alternative would be to create a xwiki core bundle that is empty except for Bundle-Classpath in its manifest, generated by the maven bundle plugin and pointing to WEB-INF/lib/*.jar.
The only thing you cannot do with that case is to update the core classes (since they are not really in a bundle, but considered as part of the JDK packages).
Yes but that's acceptable I think and is not our primary need.
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.
You're absolutely right, it's easier when everything is OSGified.
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.
Agree, OSGi will help you to bind a bundle to an exported package using a specified version (may be a version range). If what you produce is a wiki page, not some java code, it will be more difficult to requires a given package version... As OSGi targets Java, it's more usable (and there are more tools available) if you write directly Java code: Bnd can automatically deduce your imports and service-oriented component models handles dynamic service dependencies for you.
Note: I like what I saw in OSGi and I still think one goal of xwiki should be to integrate with OSGi (or with the JSR294 to be more generic, if that JSR is implemented one day... ;)). It's just that for the Extension Manager use case, I'm not sure we need OSGi from the onstart. Thanks for the info Guillaume, -Vincent PS: I'm still discovering all this and I'm not yet 100% sure of what I say. There's a little nagging thought in the back of my head that tells me that going with OSGi now is the best thing to do even though we might not need all its power (and complexity) right now but that it would be easier to shift now than later... ;)
Cheers --Guillaume
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/
Le 19/05/2010 14:44, Vincent Massol a écrit :
On May 19, 2010, at 2:02 PM, Guillaume Sauthier wrote:
Hi Vincent Here are some comments inlined...
Le 18/05/2010 19:24, Vincent Massol a écrit :
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
As OSGi use the service layer (µservice as we should say now) to interoperate, everything that is service can talk with another service. It doesn't matter if your µservice was produced by hand, with iPOJO, Blueprint (any OSGi component model you want).
yep
So if the XWiki programming model produces/consume µservices other µservices can be used too, they just have to conform to the µservice API/Interface.
yep
3) ClassLoader isolation and thus ability to have several versions of classes 4) OBR (Bundle Repository) for downloading and installing remote jars
OBR is not something that will help to download and install remote bundles. With a "naked" gateway, you can always download and install remote bundles (http://....). The goal of OBR is to help installling a *set* of bundles with dependencies between them. For example, if Bundle A depends on Bundle B, you should have to manually download and install 2 Bundles. With OBR, you just "say": "I want A installed" and B will be installed too.
Yes, that's actually what I meant by "installing remote jars" (the jars + their deps) but I should have been more explicit :)
Yep, I've understood what you meant when you were comparing with Maven3 Embedder (making clear that you talked about dependencies) :)
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
In that case, It's possible to have the webapp launching an OSGi gateway. You could have the core classes in the WEB-INF/lib/*.jar (or WEB-INF/classes) and have a selected set of packages (from the core) exported by the gateway (through the System Bundle). So your extensions (standard bundles) can use the packages from the core.
Yes that could be done. We'd need to use the Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA config property and manually list all packages (this is a pain!).
Not all packages, only the ones you want to be exported (basically your APIs). In fact, you'll choose to export the packages that you think could be used by extensions.
I guess an alternative would be to create a xwiki core bundle that is empty except for Bundle-Classpath in its manifest, generated by the maven bundle plugin and pointing to WEB-INF/lib/*.jar.
Hmm, not sure it will work. Bundle-Classpath refers to some inner jar file theoretically ...
The only thing you cannot do with that case is to update the core classes (since they are not really in a bundle, but considered as part of the JDK packages).
Yes but that's acceptable I think and is not our primary need.
You'll need to simply reload your webapp with the new core classes
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.
You're absolutely right, it's easier when everything is OSGified.
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.
Agree, OSGi will help you to bind a bundle to an exported package using a specified version (may be a version range). If what you produce is a wiki page, not some java code, it will be more difficult to requires a given package version... As OSGi targets Java, it's more usable (and there are more tools available) if you write directly Java code: Bnd can automatically deduce your imports and service-oriented component models handles dynamic service dependencies for you.
Note: I like what I saw in OSGi and I still think one goal of xwiki should be to integrate with OSGi (or with the JSR294 to be more generic, if that JSR is implemented one day... ;)). It's just that for the Extension Manager use case, I'm not sure we need OSGi from the onstart.
This time, it's me that doesn't really know what will go in this ExtensionManager, and more generally, what is an Extension :) All depends of what extensions are. If you have a small core and everything else provided as extensions, putting OSGi from the onstart may be a good choice. If extensions are java classes (that can be seen as services), using OSGi just for them also may be a good soft introduction to OSGi. If extensions are not java code, OSGi is a bad idea :)
Thanks for the info Guillaume, -Vincent
PS: I'm still discovering all this and I'm not yet 100% sure of what I say. There's a little nagging thought in the back of my head that tells me that going with OSGi now is the best thing to do even though we might not need all its power (and complexity) right now but that it would be easier to shift now than later... ;)
I understand, moving to OSGi for JOnAS has been a long work (and still not completely finished to some aspects), but we started with a non modular architecture, spaghetti code, ... :'( In your case, I've understood that you have clean APIs, already have modules, so the move should be easier :) --G
Cheers --Guillaume
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
On May 19, 2010, at 3:06 PM, Guillaume Sauthier wrote:
Le 19/05/2010 14:44, Vincent Massol a écrit :
On May 19, 2010, at 2:02 PM, Guillaume Sauthier wrote:
Hi Vincent Here are some comments inlined...
Le 18/05/2010 19:24, Vincent Massol a écrit :
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
As OSGi use the service layer (µservice as we should say now) to interoperate, everything that is service can talk with another service. It doesn't matter if your µservice was produced by hand, with iPOJO, Blueprint (any OSGi component model you want).
yep
So if the XWiki programming model produces/consume µservices other µservices can be used too, they just have to conform to the µservice API/Interface.
yep
3) ClassLoader isolation and thus ability to have several versions of classes 4) OBR (Bundle Repository) for downloading and installing remote jars
OBR is not something that will help to download and install remote bundles. With a "naked" gateway, you can always download and install remote bundles (http://....). The goal of OBR is to help installling a *set* of bundles with dependencies between them. For example, if Bundle A depends on Bundle B, you should have to manually download and install 2 Bundles. With OBR, you just "say": "I want A installed" and B will be installed too.
Yes, that's actually what I meant by "installing remote jars" (the jars + their deps) but I should have been more explicit :)
Yep, I've understood what you meant when you were comparing with Maven3 Embedder (making clear that you talked about dependencies) :)
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
In that case, It's possible to have the webapp launching an OSGi gateway. You could have the core classes in the WEB-INF/lib/*.jar (or WEB-INF/classes) and have a selected set of packages (from the core) exported by the gateway (through the System Bundle). So your extensions (standard bundles) can use the packages from the core.
Yes that could be done. We'd need to use the Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA config property and manually list all packages (this is a pain!).
Not all packages, only the ones you want to be exported (basically your APIs). In fact, you'll choose to export the packages that you think could be used by extensions.
Yes but this is still some hard work since anytime a new API is introduced we'll need to remember to update that configuration.
I guess an alternative would be to create a xwiki core bundle that is empty except for Bundle-Classpath in its manifest, generated by the maven bundle plugin and pointing to WEB-INF/lib/*.jar.
Hmm, not sure it will work. Bundle-Classpath refers to some inner jar file theoretically ...
From what I understand from http://www.aqute.biz/Blog/2007-02-19 it should work I think.
The only thing you cannot do with that case is to update the core classes (since they are not really in a bundle, but considered as part of the JDK packages).
Yes but that's acceptable I think and is not our primary need.
You'll need to simply reload your webapp with the new core classes
Yes.
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.
You're absolutely right, it's easier when everything is OSGified.
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.
Agree, OSGi will help you to bind a bundle to an exported package using a specified version (may be a version range). If what you produce is a wiki page, not some java code, it will be more difficult to requires a given package version... As OSGi targets Java, it's more usable (and there are more tools available) if you write directly Java code: Bnd can automatically deduce your imports and service-oriented component models handles dynamic service dependencies for you.
Note: I like what I saw in OSGi and I still think one goal of xwiki should be to integrate with OSGi (or with the JSR294 to be more generic, if that JSR is implemented one day... ;)). It's just that for the Extension Manager use case, I'm not sure we need OSGi from the onstart.
This time, it's me that doesn't really know what will go in this ExtensionManager, and more generally, what is an Extension :) All depends of what extensions are.
It's a mix of wiki pages, jars containing xwiki component implementations (like a xwiki java macro) and external jars (third party libraries). See http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManager for more details of what we'd like. Note that I need to update this page since Thomas has almost convinced me that we don't need a super XAR format and that we can keep the XAR format for wiki page as it is now and not have a single jar/zip by using a special empty artifact made only of a POM listing what an extension is (ie a list of dependencies on XARs and jars).
If you have a small core and everything else provided as extensions, putting OSGi from the onstart may be a good choice. If extensions are java classes (that can be seen as services), using OSGi just for them also may be a good soft introduction to OSGi. If extensions are not java code, OSGi is a bad idea :)
We have both (and code can be provided by wiki pages in the form of scripts and macros) but we cannot have different versions of wiki pages right now inside a single xwiki instance (I'm not talking about page history but about branches, each having its history). Another problem I mentioned would be to decide what classloader to use when executing a {{script}} macro. Thanks -Vincent
Thanks for the info Guillaume, -Vincent
PS: I'm still discovering all this and I'm not yet 100% sure of what I say. There's a little nagging thought in the back of my head that tells me that going with OSGi now is the best thing to do even though we might not need all its power (and complexity) right now but that it would be easier to shift now than later... ;)
I understand, moving to OSGi for JOnAS has been a long work (and still not completely finished to some aspects), but we started with a non modular architecture, spaghetti code, ... :'( In your case, I've understood that you have clean APIs, already have modules, so the move should be easier :)
--G
Cheers --Guillaume
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/
In that case, It's possible to have the webapp launching an OSGi gateway. You could have the core classes in the WEB-INF/lib/*.jar (or WEB-INF/classes) and have a selected set of packages (from the core) exported by the gateway (through the System Bundle). So your extensions (standard bundles) can use the packages from the core.
Yes that could be done. We'd need to use the Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA config property and manually list all packages (this is a pain!).
Not all packages, only the ones you want to be exported (basically your APIs). In fact, you'll choose to export the packages that you think could be used by extensions.
Yes but this is still some hard work since anytime a new API is introduced we'll need to remember to update that configuration.
Yes, but in an ideal world you should not introduce new core APIs every days :)
I guess an alternative would be to create a xwiki core bundle that is empty except for Bundle-Classpath in its manifest, generated by the maven bundle plugin and pointing to WEB-INF/lib/*.jar.
Hmm, not sure it will work. Bundle-Classpath refers to some inner jar file theoretically ...
From what I understand from http://www.aqute.biz/Blog/2007-02-19 it should work I think.
I'm not convinced :) I think the example Peter put on this page is what you could do if you were transforming a war into a bundle. In the case we're discussing, we're talking about having a normal webapp that launch an OSGi framework.
Note: I like what I saw in OSGi and I still think one goal of xwiki should be to integrate with OSGi (or with the JSR294 to be more generic, if that JSR is implemented one day... ;)). It's just that for the Extension Manager use case, I'm not sure we need OSGi from the onstart.
This time, it's me that doesn't really know what will go in this ExtensionManager, and more generally, what is an Extension :) All depends of what extensions are.
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. It's a mix of wiki pages, jars containing xwiki component implementations (like a xwiki java macro) and external jars (third party libraries).
See http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManager for more details of what we'd like. Note that I need to update this page since Thomas has almost convinced me that we don't need a super XAR format and that we can keep the XAR format for wiki page as it is now and not have a single jar/zip by using a special empty artifact made only of a POM listing what an extension is (ie a list of dependencies on XARs and jars).
An extension could be seen as a bundle (containing librairies and resources), importing some packages and providing some µservices (making them available for other to use them).
If you have a small core and everything else provided as extensions, putting OSGi from the onstart may be a good choice. If extensions are java classes (that can be seen as services), using OSGi just for them also may be a good soft introduction to OSGi. If extensions are not java code, OSGi is a bad idea :)
We have both (and code can be provided by wiki pages in the form of scripts and macros) but we cannot have different versions of wiki pages right now inside a single xwiki instance (I'm not talking about page history but about branches, each having its history). Another problem I mentioned would be to decide what classloader to use when executing a {{script}} macro.
If you think in OSGi terms, something that you use is probably a dependency on a µservice. So the wiki page would be "linked"/injected to/with the "script" µservice. The difficulty here is that the dependency is actually kind of hidden in the wiki page, it's not explicit (like an @Inject field for example). It's easier when we start with a component model, because theses models are designed to explicitely declares dependencies so that a container can handle them for you. What I have the habit to say is that : "OK, OSGi have a powerful Classloading model, but most of the time we should not touch or even think about ClassLoaders". When you look at µservices that run on top of OSGi, they're never using ClassLoaders, they always talk to other services through API. I mean that ClassLoaders handling is the job of the OSGi framework. The consummer service will be injected with a compatible dependency service (compatible in terms of packages, so versioned) and will just call the dependency, not worrying about ClassLoading issue. --G
Thanks -Vincent
Thanks for the info Guillaume, -Vincent
PS: I'm still discovering all this and I'm not yet 100% sure of what I say. There's a little nagging thought in the back of my head that tells me that going with OSGi now is the best thing to do even though we might not need all its power (and complexity) right now but that it would be easier to shift now than later... ;)
I understand, moving to OSGi for JOnAS has been a long work (and still not completely finished to some aspects), but we started with a non modular architecture, spaghetti code, ... :'( In your case, I've understood that you have clean APIs, already have modules, so the move should be easier :)
--G
Cheers --Guillaume
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
participants (4)
-
Caleb James DeLisle -
Guillaume Sauthier -
Thomas Mortagne -
Vincent Massol