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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
