Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <1b0d43d00709080230n3e959438x6c9e0d9f30989155@mail.gmail.com>
Date: Sat, 8 Sep 2007 11:30:26 +0200
From: "David Nuescheler" <david@day.com>
Sender: uncled@day.com
To: users@jackrabbit.apache.org
Subject: Re: [OT] JCR and legacy systems?
In-Reply-To: <fd7bdf180709080206i168f471bp1b789118942ec769@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070907161127.7e1e88db@n428.planconnect.net>
	 <fd7bdf180709080206i168f471bp1b789118942ec769@mail.gmail.com>

Hi Guys,

I think there is a short to medium-term need for JCR connectors
to closed source legacy repositories.

Many of those legacy repositories to my knowledge don't offer
licenses that allow people to build connectors in open source.

There are JCR connectors available in particular to popular
legacy DMS from various connector vendors.

At Day Software we for example ship connectors to
the following systems:

EMC Documentum V5.2.5, V5.3
FileNet P8 Content Manager 3.5
IBM Lotus Notes V6.5, V7.0
Interwoven TeamSite 6.5
Microsoft SharePoint 2003
OpenText Livelink 9.5, 9.6, 9.7
Vignette V7.3.0.5

http://www.day.com/site/en/index/products/content-centric_infrastructure/Content_Repository_Connectors.html

which from a technical perspective vary slightly in functionality but
are roughly Level 1 + Observation and a couple of other JCR features.

I agree with Jukka that the SPI route seems to be the most effective approach
to get to a "Level 2 and up" connector. This is also the approach that we are
using at Day for rolling out the "Level 2 and up" features into our connectors.

regards,
david

On 9/8/07, Jacco van Weert <1111software@gmail.com> wrote:
> On 9/7/07, Kristian Rink <kawazu@zimmer428.net> wrote:
> >
> >
> > Folks;
> >
> >
> > But: I don't have no clue how to get started implementing JCR against a
> > legacy system. So far, we do have rather clear ideas how the data (and,
> > thus, the repository) structure inside the DMS looks, how this will
> > have to look like in JCR, and we're also clear about most of the
> > infrastructure aspects (user authorization). I'd simply start over
> > implementing the interfaces provided by the JCR API package and hope
> > for the best... Is this a sane way to do things? Are there pitfalls
> > I've not yet taken into consideration? Is it a good idea at all? Or
> > could I do better by, say, slightly modifying parts of jackrabbit to
> > just, say, build a virtual repository rather than completely
> > implementing JCR for our environment?
>
>
>
> Hello Kristian,
>
> I did wrote a number of custom JCR implementations for the company I work
> for.
> Like Jukka says the problem lies with the "write" access.
>
> Creating a read only JCR interface is not that difficult if you only want to
> have simple NodeIterator/PropertyIterator access. I used my own JDots
> framework (http://jdots.sourceforge.net) to build the in-memory JCR tree,
> with JDots it's also more easier to create a write repository.
>
> The other problems;
>
> - node/propertytype definitions, it is doable to create a write-JCR
> repository without the JCR nodetypes constrains especially if your legacy
> provides these constrains themselves.
>
> - searching, well I guess that is a real problem because it's quite hard map
> the JCR standard search mapping to your legacy system. I choose to just
> define my own search language, more or less adapting the legacy system
> search.
>
> The big advantage of having a JCR interface to you legacy system is to have
> a seamless transition to a full JCR repository.
>
>
> Greetings,
>
>   Jacco
>
>
>
>
>
> --
> > -------------------------------------
> > Jacco van Weert -- 1111software@gmail.com
> > JCR Controller -- http://www.xs4all.nl/~weertj/jcr
>