Re: jcr-cmis WS volounteers/approach
Hi Gabriele, On Tue, Dec 9, 2008 at 1:13 PM, Gabriele Columbro [EMAIL PROTECTED] wrote: Hi all, as this is my first post on the JackRabbit @dev list, I guess a bit of introduction is needed: together with my colleague Paolo Mottadelli, I have been following the jcr-cmis sandbox thread with a lot of interest. Searching how we could help, we noticed the WS component of the jcr-cmis connector is ATM quite short handed, so we started having a look at the jcr-cmis REsT branch to try and have a unified strategy and reuse the most between the two implementations. BTW, not having committership rights, I would probably be bugging you a lot with Jira issues and kinda long emails like this one (soffy for that), but hopefully you can still find value in the contribution :) To speed up things, I'll kick Paolo (which is POI committer) to commit to the sandbox possible patches I may attach to issues ;) So, we tried to have a look to the existing codebase and approach for the REsT part and came up with the following approach/findings for the WS part (I would have opened Jira issues already, but not sure which component to use, maybe sandbox [1] or better have a specific component for jcr-cmis) : __Maven parent In the superpom I find a parent reference to the 1.5-SNAPSHOT of Jackrabbit which is neither the last development version (1.5 has been released) nor it's available in any of the POM specified repositoritories (I guess most of you have apache.snapshots repo in their settings.xml) . My question here is: - is there a real need for the parent reference here? - If so, why can't we depend on 1.5 released version? (or on 1.6-SNAPSHOT still adding apache.snapshots repo in the POM) By the time, I created this pom.xml, 1.5 was not officially released yet, and I copied a pom.xml from some other sandbox project. We could very well depend on the latest development version or on the released version, whatever seems more appropriate, or even drop the parent reference as well. __Testing framework In the quasi-pure TDD spirit, we started by thinking about the testing framework (to create a RepositoryServiceTest), also looking at what's in the REsT part. My idea, please correct me if I'm wrong, was to have a: - maven-jetty-plugin configured in the build to run a jackrabbit war bundled with the jcr-cmis extension - configure maven-surefire-plugin to run integration tests after jetty - tear down the jetty instance I see instead there that an instance of Jetty is programmatically created and bound to the abdera servlet in the REsT part. Is it a best practice/approach we could reuse for both implementations? I'm not familiar with using Jetty programmatically so I may just be being so old ;) Sorry, this was my just initial approach. I quickly felt that abdera was extensible enough to fill the atompub binding part. In order to have a minimal startup time, so that I could tweak the responses the way I wanted them, I used this programmatical test setup. It surely makes more sense to have jackrabbit.war extended by jcr-cmis, as you suggest. I'm not sure, however, whether we can still use the abdera servlet then. __Core technologies (Axis or CXF) Which WS framework would you suggest? At the moment I have a better feeling for CXF with respect to Axis(2), maybe for the lower footprint it seems to have, but I never had hands on expertise with both frameworks. Any suggestion/direction here of course more than welcome. Axis is the only framework I heard of right now, but I was hoping that there is some better approach ;) __'jcr-cmis' component in Jira As I mentioned before, does it make sense to have a specific component for this bit of the sandbox or just use the 'sandbox' component? I'd prefer having a specific component. __Design document to map JCR - CIMS objects I read someone mentioning the creation of a 'mapping design' document. Has this been done and I'm missing something or someone can create it already? As far as I know, this hasn't been done yet. __Dynamically generate services interfaces and commit wsdl files? As a starting point, we were thinking of generating the Java interfaces from committed WSDL files with cxf as described here [3]. Also committing the WSDL, we could automatically regenerate the interfaces upon specs changes using the maven plugin [4]. Do you have any objections/suggestions for this approach? Sounds good to me. I started creating a couple of interfaces from the spec, but if we can have them generated through WSDL and use them in the atompub part as well, even better :) Kind regards Dominique Eager to hear your comments/suggestions (if you could make it trough this long email :). Ciao, Gab [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10591component=12310830resolution=-1sorter/field=prioritysorter/order=DESC : [2] http://people.apache.org/repo/m2-snapshot-repository [3]
Re: jcr-cmis WS volounteers/approach
Dominique Pfister wrote: On Tue, Dec 9, 2008 at 1:13 PM, Gabriele Columbro [EMAIL PROTECTED] wrote: __Core technologies (Axis or CXF) Which WS framework would you suggest? At the moment I have a better feeling for CXF with respect to Axis(2), maybe for the lower footprint it seems to have, but I never had hands on expertise with both frameworks. Any suggestion/direction here of course more than welcome. Axis is the only framework I heard of right now, but I was hoping that there is some better approach ;) some time ago I found this comparison quite helpful. but I'm not sure whether it is still up to date: http://wiki.apache.org/ws/StackComparison regards marcel
Re: jcr-cmis WS volounteers/approach
Hi all, find my comments below. By the time, I created this pom.xml, 1.5 was not officially released yet, and I copied a pom.xml from some other sandbox project. We could very well depend on the latest development version or on the released version, whatever seems more appropriate, or even drop the parent reference as well. In the spirit of implementing a JCR compliant CMIS, if we don't have any technical reason of having Jackrabbit as a parent project, I'd opt for dropping the parent reference untill we'll need it. __Core technologies (Axis or CXF) Which WS framework would you suggest? At the moment I have a better feeling for CXF with respect to Axis(2), maybe for the lower footprint it seems to have, but I never had hands on expertise with both frameworks. Any suggestion/direction here of course more than welcome. Axis is the only framework I heard of right now, but I was hoping that there is some better approach ;) ATM I'm playing with CXF and it is making me confident enough; the main reasons for which I've chosen it for these test are: _ they say CXF has better support for JAX-WS _ it has a simpler approach to make things start __'jcr-cmis' component in Jira As I mentioned before, does it make sense to have a specific component for this bit of the sandbox or just use the 'sandbox' component? I'd prefer having a specific component. +1 for a specific component for me, as well __Dynamically generate services interfaces and commit wsdl files? As a starting point, we were thinking of generating the Java interfaces from committed WSDL files with cxf as described here [3]. Also committing the WSDL, we could automatically regenerate the interfaces upon specs changes using the maven plugin [4]. Do you have any objections/suggestions for this approach? Sounds good to me. I started creating a couple of interfaces from the spec, but if we can have them generated through WSDL and use them in the atompub part as well, even better :) I've generated interfaces starting from the WSDL using the CXF wsdl2java command. For this first phase, it would be reasonable to consider these as a commodity we could add; I'd focus more on validating the better technology for us. Cheers, -- Paolo Kind regards Dominique Eager to hear your comments/suggestions (if you could make it trough this long email :). Ciao, Gab [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10591component=12310830resolution=-1sorter/field=prioritysorter/order=DESC : [2] http://people.apache.org/repo/m2-snapshot-repository [3] http://cwiki.apache.org/CXF20DOC/wsdl-to-java.html [4] http://cwiki.apache.org/CXF20DOC/maven-integration-and-plugin.html -- Gabriele Columbro Alfresco ECM Product Strategy Consultant +31 627 565 103 Sourcesense - Making sense of open Source (http://www.sourcesense.com) -- Paolo Mottadelli: http://www.paolomottadelli.com Sourcesense - making sense of Open Source: http://www.sourcesense.com
Re: jcr-cmis WS volounteers/approach
Hi Jukka, On Tue, Dec 9, 2008 at 3:00 PM, Jukka Zitting [EMAIL PROTECTED] wrote: How about if I created a new Jira project like JCRCMIS for this? Having sandbox issues in the JCR project has always been a bit distracting for release management purposes, and with a specialized Jira project for the CMIS effort you could also have more fine-grained component labels like ws or atompub. From our perspective it sounds better for the same reason :-) +1 for me -- Paolo Mottadelli: http://www.paolomottadelli.com Sourcesense - making sense of Open Source: http://www.sourcesense.com
jcr-cmis WS volounteers/approach
Hi all, as this is my first post on the JackRabbit @dev list, I guess a bit of introduction is needed: together with my colleague Paolo Mottadelli, I have been following the jcr-cmis sandbox thread with a lot of interest. Searching how we could help, we noticed the WS component of the jcr-cmis connector is ATM quite short handed, so we started having a look at the jcr-cmis REsT branch to try and have a unified strategy and reuse the most between the two implementations. BTW, not having committership rights, I would probably be bugging you a lot with Jira issues and kinda long emails like this one (soffy for that), but hopefully you can still find value in the contribution :) To speed up things, I'll kick Paolo (which is POI committer) to commit to the sandbox possible patches I may attach to issues ;) So, we tried to have a look to the existing codebase and approach for the REsT part and came up with the following approach/findings for the WS part (I would have opened Jira issues already, but not sure which component to use, maybe sandbox [1] or better have a specific component for jcr-cmis) : __Maven parent In the superpom I find a parent reference to the 1.5-SNAPSHOT of Jackrabbit which is neither the last development version (1.5 has been released) nor it's available in any of the POM specified repositoritories (I guess most of you have apache.snapshots repo in their settings.xml) . My question here is: - is there a real need for the parent reference here? - If so, why can't we depend on 1.5 released version? (or on 1.6-SNAPSHOT still adding apache.snapshots repo in the POM) __Testing framework In the quasi-pure TDD spirit, we started by thinking about the testing framework (to create a RepositoryServiceTest), also looking at what's in the REsT part. My idea, please correct me if I'm wrong, was to have a: - maven-jetty-plugin configured in the build to run a jackrabbit war bundled with the jcr-cmis extension - configure maven-surefire-plugin to run integration tests after jetty - tear down the jetty instance I see instead there that an instance of Jetty is programmatically created and bound to the abdera servlet in the REsT part. Is it a best practice/approach we could reuse for both implementations? I'm not familiar with using Jetty programmatically so I may just be being so old ;) __Core technologies (Axis or CXF) Which WS framework would you suggest? At the moment I have a better feeling for CXF with respect to Axis(2), maybe for the lower footprint it seems to have, but I never had hands on expertise with both frameworks. Any suggestion/direction here of course more than welcome. __'jcr-cmis' component in Jira As I mentioned before, does it make sense to have a specific component for this bit of the sandbox or just use the 'sandbox' component? __Design document to map JCR - CIMS objects I read someone mentioning the creation of a 'mapping design' document. Has this been done and I'm missing something or someone can create it already? __Dynamically generate services interfaces and commit wsdl files? As a starting point, we were thinking of generating the Java interfaces from committed WSDL files with cxf as described here [3]. Also committing the WSDL, we could automatically regenerate the interfaces upon specs changes using the maven plugin [4]. Do you have any objections/suggestions for this approach? Eager to hear your comments/suggestions (if you could make it trough this long email :). Ciao, Gab [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10591component=12310830resolution=-1sorter/field=prioritysorter/order=DESC : [2] http://people.apache.org/repo/m2-snapshot-repository [3] http://cwiki.apache.org/CXF20DOC/wsdl-to-java.html [4] http://cwiki.apache.org/CXF20DOC/maven-integration-and-plugin.html -- Gabriele Columbro Alfresco ECM Product Strategy Consultant +31 627 565 103 Sourcesense - Making sense of open Source (http://www.sourcesense.com)
Re: jcr-cmis WS volounteers/approach
Hi, On Tue, Dec 9, 2008 at 3:00 PM, Jukka Zitting [EMAIL PROTECTED] wrote: How about if I created a new Jira project like JCRCMIS for this? Jira projects are cheap so I just went ahead and created the JCRCMIS project, see [1]. I've given the all-developers group the Committer role in JCRCMIS, so all Apache committers (with a developer role in some Jira project) should have the right to resolve issues and update the project configuration (create new components, etc.). The project is setup like the existing JCR project, for example the notification messages should work the same way. There are two differences though: I've enabled wiki markup for description and comment fields and used the 'no-reopen-closed, patch-avail workflow scheme. The latter means that there is a nice new Patch Available state for issues and that a closed (as opposed to just resolved) issue can not be reopened (it's better to create a new issue in such cases). Let's see how the wiki markup and workflow settings work in practice. I'd like to start using them in the JCR project as well if the experience from JCRCMIS is good. [1] https://issues.apache.org/jira/browse/JCRCMIS BR, Jukka Zitting
