On Fri, Apr 16, 2010 at 10:55, Caleb James DeLisle
<calebdelisle(a)lavabit.com> 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?
* 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs