jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabriele Columbro" <g.colum...@sourcesense.com>
Subject jcr-cmis WS volounteers/approach
Date Tue, 09 Dec 2008 12:13:21 GMT
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=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)

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message