Just a couple of comments - sorry for the delay :
* Maven goals are there to build, run unit tests, ... Maybe it is more
simple to use the maven goals and just run "maven eclipse" to create a
new project.
* The OCM tools (subfolder jcr) is not integrated into the complete
Graffito stack.
* There are some contributions that are not committed ( workflow,
scheduler, news management, ...). Due to some important and urgent
activities in my daily job, I didn't found the time to review and
commit them.
* If you are face to some performances issues, you are welcome to
create new Jira issues with details. We will be very happy to receive
some feedbacks. This OCM tools is also targeted for frequent,
transactional updates on objects.
br,
Christophe
On 8/30/06, Dan Connelly <[EMAIL PROTECTED]> wrote:
Ruchi:
I have not looked at the CMS or workflow in Graffito at all. My
interest, for now, is in mapping objects to JCR , and in connecting
Jackrabbit's persistence to Eclipse's design and modeling tools.
(However, at this point my thinking is that Graffito jcr mapping is the
prototype for for what I want, but not the solution. Eclipse's EMF
models are JO but not PO, that is, not POJOs, as Graffito would want.)
Ultimately, the object mapping is to support design-driven business
reporting for portal servers (using, for instance, the Eclipse BIRT
report server). Originally, my interest in Graffito was in its
integration with Jetspeed2. J2 and Liferay are may target portals.
Whether or not a CMS (as commonly defined) is useful for portalized
business reporting is TBD. As I mentioned in a previous post, I have
looked into Eclipse's new Apogee CMS project (to be transferred from
Nuxeo). All things being equal, I would prefer to use Apogee over
Graffito for CMS, but (so far) I do not see good support for JCR custom
node types in Apogee.
If Graffito CMS is better than Apogee CMS at supporting custom node
types or access management for objects mapped into Jackrabbit , then I
would be glad to hear of it. So far, I have not done this
investigation myself.
-- Dan
ruchi goel wrote:
> Hi Dan,
> Thanks for detailed response . I will try this out and let you
> know my experiences. Don't you think that the cms model should be
> directly talking to jcr mapping tool at least for the services which
> are part of jsr170 (Workflow is exception).
>
> Another question : Is workflow implemented as a service ? I don't see
> anything in the source tree ?
>
> Thanks,
> Ruchi
>
> Dan Connelly wrote:
>
>> Hi Ruchi:
>>
>> I am also a newcomer to Graffito (and a refugee from Eclipse Apogee).
>>
>> What I did to get started with jcr mapping is to Check Out the
>> jcr-mapping code (under jcr folder) as a project in Eclipse. With
>> Eclispe SVN Repository perspective, the project creation is automatic
>> on the Check Out.. A no-brainer. (Note: mapping itself does not
>> require anything else from Graffito.)
>>
>> Then you will try to run the JUnit tests (in Eclipse) from your jcr
>> mapping project. The tests are in the download.
>>
>> You will need to fetch a bunch of libraries to get rid of the initial
>> errors in this testing. An easy way to get these libraries (most of
>> them anyway) is to import the Jackrabbit server war (as an Eclipse
>> Dynamic Web project) and ref its jars from your mapping project.
>>
>> You do NOT need the graffito api at all. The Graffito jcr mapping
>> uses Jackrabbit directly (as far as I can tell).
>>
>> ---------------------------
>> 2 hints:
>>
>> 1) A small change is needed in custom_nodetypes.xml in the test
>> config. Move graffito:documentstream ahead of
>> graffito:documentimpl in this file.
>>
>> 2) Get the Jackrabbit core source and put this in a third Eclipse
>> project. Reference this project from your jcr mapping project.
>> This is not a requirement but it will make Eclipse's debug traces a
>> lot easier to follow.
>>
>> -----------------------------
>> 3 observations:
>>
>> 1) The object mapping itself is a pretty simple affair, maybe too
>> simple. (Jury is still out on this.) You must create the mapping by
>> hand, but this is much easier than for Hibernate or JPOX mappings.
>> However, the Graffito documentation is somewhat behind its code.
>> For instance, you need to read the comments in the mapping DTD and
>> look at the code to figure out inheritance mapping. Also, it
>> appears that for non-containment references, you need to program
>> these references as JCR Paths. Simple object constraints (like no
>> dangling references), may be missing from Graffito. JCR versioning
>> may mitigate (or exacerbate?) the dangling ref problem. This is
>> still a mystery for me.
>>
>> 2) Jackrabbit transaction locking is still new territory for me
>> too. However, with or without transactions, any object updates are
>> "very" slow. Concurrency, too, may be limited if big chunks of
>> content get locked during a transaction. If you want frequent,
>> transactional updates on objects and you want high concurrency (like
>> optimistic locking), it may be that you need to stick with Hibernate
>> over a RDBMS. On the other hand, if your applications are mainly
>> read-only (like a business reporting tool) then jcr mapping may
>> provide much better access control than you would get using
>> Hibernate. (Jury is still out here, too.)
>>
>> 3. Multiple inheritance is a valid association of objects in a model
>> (though Java does not support it well). Ideally jcr mapping
>> should deal with such a model. It does not appear to so at this
>> time. With mixin types available in JCR, I had hoped for more.
>> ("Mixin" being C++ slang for multiple inheritance.)
>>
>> -- Dan Connelly
>>
>>
>>
>> ruchi goel wrote:
>>
>>> Hi,
>>> I am a newcommer to graffito area and am in process of
>>> evaluating graffito for integration with our portal server.
>>>
>>> I am mainly interested in knowing the navigation as to how graffito
>>> stores its java objects in JSR170 compliant repository. I understand
>>> that graffito uses Jackrabbit. I have gone through the documentation
>>> on graffito's web site and my understanding is that graffito is
>>> mapping a java object to a jcr node (via mapping's file) , and then
>>> use JSR170 on the node to talk to Jackrabbbit repository.
>>>
>>> I have downloaded the latest bits , build, installed and deployed
>>> on jetspeed. I use debugger to check the flow , but I am finding
>>> that it uses GraffitoOJBStore .
>>>
>>> *Is the jcr mapping layer not being used in the current code to talk
>>> to JSR170 repository. ?*
>>>
>>> Though I see the code in place in the source tree : packages
>>> org.apache.portals.graffito.jcr
>>>
>>>
>>> Help appreciated.
>>>
>>> Thanks,
>>> Ruchi
>>>
>>
>
>
--
Best regards,
Christophe
