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=true&&pid=10591&component=12310830&resolution=-1&sorter/field=priority&sorter/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) >
