Re: [modeling-pmc] Re: JCRManagement Project Pre-Proposal

[Sandro Böhme <sandro.boehme@xxxxxx>]

Hello,

please see my comments below.

Sandro Böhme schrieb:
> Hi Rich,
>
> Richard Gronback wrote:
> > Hi,
> >
> > > > From my perspective, while I find the proposal interesting, I wonder 
> > > > about
> thanks - is there anything special that you find interesting or is it 
> just the proposal in general?
> > popularity and diversity from a contribution standpoint.  Also, is 
> > there an
> > initial contribution, or is this all new development?  This can all 
> > come out
> There is no initial contribution. At the moment I'm testing strategies 
> for the implementation of the JCR into EMF. I'm also in a technically 
> discussion with a friend about it.
> The charme of the JCR is, that it already handles lazy loading and 
> transient states while having large content repositories in mind. E.g. 
> reading nodes does not already read the properties and subnodes. Writing 
> content is done in a transient session that can finally get persisted 
> with calling a save() method or it can get reset to the initial state.
> This means if we could find a way how EMF could make use of this 
> features it would help a lot to make EMF handling large content 
> repositories and enrich it with that powerful persistence feature. Once 
> the node model of the JCR is integrated I think it could not be too hard 
> to also offer the content services of the JCR to EMF. Of course 
> everything can be done while being based on standards.
> I would be glad if we could find a way how EMF could offer the JCR 
> features to their community.
> At the moment I created a simple implementation for 
> org.eclipse.emf.ecore.resource.impl.ResourceImpl that directly loads
> > from and saves to a Jackrabbit repository. One idea is, to model a 
> EMFNode that extends the EObjectImpl and implements the jcr.Node.
> This EMFNode could wrap a jcr.Node object and delegate the JCR method 
> calls to the jcr.Node object. Additionally the EList could directly 
> operate on nodes. But I will need to evaluate this strategy in more detail.
In the meantime I did that and found out, that I can model an EMFNode 
classifier whose properties directly operate on a wrapped jcr.Node 
object. This means the project does not need to duplicate the node 
properties from the jcr.Node Object to the EMFNode.

As a result I'm quite happy that I could generate an editor that can 
read a node tree from a Jackrabbit repository, add nodes, change node 
names and save the result back to the repository.

Thanks to Ed's hint in the newsgroup regarding the didAdd(),... method 
of the EList it was not too hard to implement and I think that the 
barrier for contributions will not be too high.

> > during the proposal phase (technically, you're in the pre-proposal phase
> > now), but it will be important.
> If the project is technically not too hard to implement (which would of 
> course raise the barrier for contributions) I'm sure it will get popular 
> and diverse to create a healty community. In my opinion the problems 
> this project could solve are very valuable for the CMS market and also 
> for other use cases. Please see also the background details in my 
> initial email to Ed and the use cases in my proposal (but you will 
> probably have already read it).
> As soon as we all think this project is straight forward enough to 
> implement, has not too much risks left, it is feasable in general and is 
> accepted by the EMO I would like to write to channels like CMSWatch.com, 
> Contentmanager.de and InfoQ.com to present the proposal, the solution 
> processes and use cases to attract the commmunity. I will create a 
> survey (maybe at SurveyMonkey.com) to find out how big the community is. 
> It will also motivate for contribution as people (hopefully) see that 
> there is an interest in the results of their work.
> However - if it turns out, that it will not work out for sure I would 
> rather declare the project as failed before too many people put too much 
> work in it.
>
> > Also, notice that under the newly updated and Board approved development
> > process, you'll need to find 2 mentors from the Architecture Council 
> > willing
> > to sponsor this project, among other process points:
> > http://wiki.eclipse.org/index.php/Development_Process_2006_Revision_Final#Pr 
> >
> > oject_Lifecycle
> Thanks for the pointer.
>
> Best regards,
>
> Sandro

Bye,

Sandro