[xwiki-devs] [Proposal] Preparing for the Extension Manager
Hi devs, I've been researching what it would take to be able to support the Extension Manager use case regarding components isolation and dependency versioning. I won't go over the details of all I've researched (you can ask questions for that). I'm just proposing a series of steps and a vision of the future for our component model. If you're interested in the topic I would recommend that you read the Weld tutorial on CDI: docs.jboss.org/weld/reference/1.0.0/en-US/html_single/ Here are the steps I'm willing to work on and implement. Step 1: timeframe from now: 1 month * Use JSR330 annotations Step 2: timeframe from now: 1 month * Do a POC of integrating xwiki-component with OSGi (as a xwiki-component-osgi module). - No versioning management yet. - Need to use a maven osgi plugin to generate Manifest files from the POMs * Revise further steps based on result from Step 2. Step 3: timeframe from now: 2 months * If step 2 is successful add what's needed to the XWiki Component API to perform generic lookup: CM.lookup(Class, Properties) where Properties is a set of properties registered with the component. It would contain the role hint and the version for example. Also add annotations for specifying dependency version ranges. Note: After step 3 we have the prereqs for the Extension Manager done. The other steps below are improvements and steps to put us in the standards direction. Step 4: timeframe from now: 6 months-2 years * When CDI (JSR299) has taken over the world (ie several DI frameworks migrate to it, it becomes a JavaSE de facto standard at least), migrate to it. We need 2 features not in the spec right now: - support for dynamic bean registration - ability to implement CDI over OSGi * Work with the Weld dev team to add support for those 2 items above. They're interested to implement it if we help them and if these 2 items get done relatively quickly we could migrate to CDI earlier than the timeframe above * In the meantime we can monitor it carefully to see its progress and we could start migrating to it slowly. Some ideas: - use the CDI annotations instead of the xwiki-specific ones for the binding part - introduce new concepts that comes from CDI: decorators, interceptors, producers - refactor our observation module to use the CDI event model Step 5: timeframe for now: 2-4 years * When JSR294 is approved and final (will require at least JDK 7, so XWiki needs to be on JDK7 at least for this, so that's a few years in the future...) migrate to CDI over JSR294 over (Jigsaw, OSGi). The good part is that since we would be using CDI we won't need to change much in our code to do that. WDYT? Thanks -Vincent Links: - Weld/JSR299: docs.jboss.org/weld/reference/1.0.0/en-US/html_single/ - Jigsaw: openjdk.java.net/projects/jigsaw/ - JSR330: atinject.googlecode.com/svn/trunk/javadoc/javax/inject/package-summary.html - JSR294: See description on openjdk.java.net/projects/jigsaw/
Vincent Massol wrote:
Hi devs,
I've been researching what it would take to be able to support the Extension Manager use case regarding components isolation and dependency versioning. I won't go over the details of all I've researched (you can ask questions for that). I'm just proposing a series of steps and a vision of the future for our component model.
If you're interested in the topic I would recommend that you read the Weld tutorial on CDI: docs.jboss.org/weld/reference/1.0.0/en-US/html_single/
Here are the steps I'm willing to work on and implement.
Step 1: timeframe from now: 1 month * Use JSR330 annotations +1 this looks like it is necessary since these annotations are apparently used by JSR299 and JSR330 and are almost exactly the same as Guice's API.
Step 2: timeframe from now: 1 month * Do a POC of integrating xwiki-component with OSGi (as a xwiki-component-osgi module). - No versioning management yet. - Need to use a maven osgi plugin to generate Manifest files from the POMs * Revise further steps based on result from Step 2.
Step 3: timeframe from now: 2 months * If step 2 is successful add what's needed to the XWiki Component API to perform generic lookup: CM.lookup(Class, Properties) where Properties is a set of properties registered with the component. It would contain the role hint and the version for example. Also add annotations for specifying dependency version ranges.
Note: After step 3 we have the prereqs for the Extension Manager done. The other steps below are improvements and steps to put us in the standards direction.
Step 4: timeframe from now: 6 months-2 years * When CDI (JSR299) has taken over the world (ie several DI frameworks migrate to it, it becomes a JavaSE de facto standard at least), migrate to it. We need 2 features not in the spec right now:
Why JSR299 over Guice API?
- support for dynamic bean registration - ability to implement CDI over OSGi Why CDI over OSGi? One package can't do all that is needed?
* Work with the Weld dev team to add support for those 2 items above. They're interested to implement it if we help them and if these 2 items get done relatively quickly we could migrate to CDI earlier than the timeframe above * In the meantime we can monitor it carefully to see its progress and we could start migrating to it slowly. Some ideas: - use the CDI annotations instead of the xwiki-specific ones for the binding part - introduce new concepts that comes from CDI: decorators, interceptors, producers - refactor our observation module to use the CDI event model
Step 5: timeframe for now: 2-4 years * When JSR294 is approved and final (will require at least JDK 7, so XWiki needs to be on JDK7 at least for this, so that's a few years in the future...) migrate to CDI over JSR294 over (Jigsaw, OSGi). The good part is that since we would be using CDI we won't need to change much in our code to do that.
WDYT?
Thanks -Vincent
Links: - Weld/JSR299: docs.jboss.org/weld/reference/1.0.0/en-US/html_single/ - Jigsaw: openjdk.java.net/projects/jigsaw/ - JSR330: atinject.googlecode.com/svn/trunk/javadoc/javax/inject/package-summary.html - JSR294: See description on openjdk.java.net/projects/jigsaw/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Apr 16, 2010 at 10:55, Caleb James DeLisle <[email protected]> wrote:
Vincent Massol wrote:
Hi devs,
I've been researching what it would take to be able to support the Extension Manager use case regarding components isolation and dependency versioning. I won't go over the details of all I've researched (you can ask questions for that). I'm just proposing a series of steps and a vision of the future for our component model.
If you're interested in the topic I would recommend that you read the Weld tutorial on CDI: docs.jboss.org/weld/reference/1.0.0/en-US/html_single/
Here are the steps I'm willing to work on and implement.
Step 1: timeframe from now: 1 month * Use JSR330 annotations +1 this looks like it is necessary since these annotations are apparently used by JSR299 and JSR330 and are almost exactly the same as Guice's API.
Step 2: timeframe from now: 1 month * Do a POC of integrating xwiki-component with OSGi (as a xwiki-component-osgi module). - No versioning management yet. - Need to use a maven osgi plugin to generate Manifest files from the POMs * Revise further steps based on result from Step 2.
Step 3: timeframe from now: 2 months * If step 2 is successful add what's needed to the XWiki Component API to perform generic lookup: CM.lookup(Class, Properties) where Properties is a set of properties registered with the component. It would contain the role hint and the version for example. Also add annotations for specifying dependency version ranges.
Note: After step 3 we have the prereqs for the Extension Manager done. The other steps below are improvements and steps to put us in the standards direction.
Step 4: timeframe from now: 6 months-2 years * When CDI (JSR299) has taken over the world (ie several DI frameworks migrate to it, it becomes a JavaSE de facto standard at least), migrate to it. We need 2 features not in the spec right now:
Why JSR299 over Guice API?
- support for dynamic bean registration - ability to implement CDI over OSGi Why CDI over OSGi? One package can't do all that is needed?
JSR299 is only an API you need something to implement it.
* Work with the Weld dev team to add support for those 2 items above. They're interested to implement it if we help them and if these 2 items get done relatively quickly we could migrate to CDI earlier than the timeframe above * In the meantime we can monitor it carefully to see its progress and we could start migrating to it slowly. Some ideas: - use the CDI annotations instead of the xwiki-specific ones for the binding part - introduce new concepts that comes from CDI: decorators, interceptors, producers - refactor our observation module to use the CDI event model
Step 5: timeframe for now: 2-4 years * When JSR294 is approved and final (will require at least JDK 7, so XWiki needs to be on JDK7 at least for this, so that's a few years in the future...) migrate to CDI over JSR294 over (Jigsaw, OSGi). The good part is that since we would be using CDI we won't need to change much in our code to do that.
WDYT?
Thanks -Vincent
Links: - Weld/JSR299: docs.jboss.org/weld/reference/1.0.0/en-US/html_single/ - Jigsaw: openjdk.java.net/projects/jigsaw/ - JSR330: atinject.googlecode.com/svn/trunk/javadoc/javax/inject/package-summary.html - JSR294: See description on openjdk.java.net/projects/jigsaw/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Apr 16, 2010, at 10:55 AM, Caleb James DeLisle wrote:
Vincent Massol wrote:
Hi devs,
I've been researching what it would take to be able to support the Extension Manager use case regarding components isolation and dependency versioning. I won't go over the details of all I've researched (you can ask questions for that). I'm just proposing a series of steps and a vision of the future for our component model.
If you're interested in the topic I would recommend that you read the Weld tutorial on CDI: docs.jboss.org/weld/reference/1.0.0/en-US/html_single/
Here are the steps I'm willing to work on and implement.
Step 1: timeframe from now: 1 month * Use JSR330 annotations +1 this looks like it is necessary since these annotations are apparently used by JSR299 and JSR330 and are almost exactly the same as Guice's API.
Indeed, Guice's code in trunk already supports JSR330 and that's the direction anyway.
Step 2: timeframe from now: 1 month * Do a POC of integrating xwiki-component with OSGi (as a xwiki-component-osgi module). - No versioning management yet. - Need to use a maven osgi plugin to generate Manifest files from the POMs * Revise further steps based on result from Step 2.
Step 3: timeframe from now: 2 months * If step 2 is successful add what's needed to the XWiki Component API to perform generic lookup: CM.lookup(Class, Properties) where Properties is a set of properties registered with the component. It would contain the role hint and the version for example. Also add annotations for specifying dependency version ranges.
Note: After step 3 we have the prereqs for the Extension Manager done. The other steps below are improvements and steps to put us in the standards direction.
Step 4: timeframe from now: 6 months-2 years * When CDI (JSR299) has taken over the world (ie several DI frameworks migrate to it, it becomes a JavaSE de facto standard at least), migrate to it. We need 2 features not in the spec right now: Why JSR299 over Guice API?
You mean "why not"? The reason is that Guice doesn't implement JSR299. It only implements JSR330. IMO if CDI becomes adopted for JavaSE then Guice in the current form is dead. They'll need to implement CDI at that time. I'd be curious to know Bob's opinion nowadays (since he wrote that piece in 2009: www.mail-archive.com/[email protected]/msg01243.html ;)).
- support for dynamic bean registration - ability to implement CDI over OSGi Why CDI over OSGi? One package can't do all that is needed?
CDI is a spec. You need an implementation. And one that goes beyond the spec in order to support dynamic bean registration and dependency isolation and versioning for ex. Weld is good candidate to provide this and they're interested in doing so. Thanks -Vincent
* Work with the Weld dev team to add support for those 2 items above. They're interested to implement it if we help them and if these 2 items get done relatively quickly we could migrate to CDI earlier than the timeframe above * In the meantime we can monitor it carefully to see its progress and we could start migrating to it slowly. Some ideas: - use the CDI annotations instead of the xwiki-specific ones for the binding part - introduce new concepts that comes from CDI: decorators, interceptors, producers - refactor our observation module to use the CDI event model
Step 5: timeframe for now: 2-4 years * When JSR294 is approved and final (will require at least JDK 7, so XWiki needs to be on JDK7 at least for this, so that's a few years in the future...) migrate to CDI over JSR294 over (Jigsaw, OSGi). The good part is that since we would be using CDI we won't need to change much in our code to do that.
WDYT?
Thanks -Vincent
Links: - Weld/JSR299: docs.jboss.org/weld/reference/1.0.0/en-US/html_single/ - Jigsaw: openjdk.java.net/projects/jigsaw/ - JSR330: atinject.googlecode.com/svn/trunk/javadoc/javax/inject/package-summary.html - JSR294: See description on openjdk.java.net/projects/jigsaw/
participants (3)
-
Caleb James DeLisle -
Thomas Mortagne -
Vincent Massol