In the Seam.Next Announcement blog post, Shane talks about how the Seam community has encouraged projects to own their own CDI extensions:
"By enabling CDI support in as many places as possible, our goal is to make developer productivity stronger than ever. To that end, we have been encouraging and assisting other project teams to provide CDI integration directly from their own projects."
Since neither the Jackrabbit nor ModeShape projects have directly provided CDI extensions, the Seam community created the Seam JCR module do do this.
Should ModeShape 3.0 natively provide CDI extensions for JCR? It seems like this is certainly possible and straightforward, but it also raises a number of questions.
- If we do this, what happens to Seam JCR (or to the corresponding module in the proposed Apache DeltaSpike project), especially if Jackrabbit does not provide their own CDI injection?
- Do the benefits of a single CDI extension for multiple JCR implementations outweigh those of ModeShape-specific CDI extension?
- If both ModeShape and Jackrabbit were to provide their own CDI extensions, what's the impact of the two CDI extensions diverging? (After all, even with Seam JCR they extensions for ModeShape and Jackrabbit do have some differences.)
- Should we instead push the JSR-333 (aka "JCR 2.1") effort to include standard CDI extensions, and is that even possible given the varied implementations?
I've created MODE-1316 as a placeholder. If the outcome of this discussion is that ModeShape 3 should provide CDI extensions, then we'll flesh out the work under that issue. On the other hand, if the outcome is that Seam JCR (or DeltaSpike JCR) is the better approach, then we'll document this on the issue and close it.
So, what are your thoughts?
BTW, George Gastaldi and John Ament are contributors to ModeShape and the creators of Seam JCR, so I thought this might be a useful location for this discussion.