jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: EMF Graffito Integration, Plan B
Date Tue, 19 Sep 2006 11:41:47 GMT
Hi,

On 9/19/06, Dan Connelly <dsconnelly@adelphia.net> wrote:
> It appears from Jukka's post yesterday that "jcr-mapping" will be moving
> into Jackrabbit sooner rather than later.

For dev@j.a.o, see
http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200609.mbox/%3c510143ac0609181310p3f2bd71r8fb9c3a4db7a2ce2@mail.gmail.com%3e

> JCR mapping may, in practice, become indistinguishable from Jackrabbit itself.

I wouldn't say "indistinguishable". The Jackrabbit project produces an
implementation of the JCR API as well as a collection of JCR-related
tools. All these components are part of Jackrabbit, but certainly
distinguishable from each other.

> Going *completely* in that direction does eliminate (in my mind) the
> need to surface any dependency name other than "jackrabbit".  There are
> no visible jcr mapping, graffito or otherwise.

I think you're confusing things here. A client application (like your
EMF project) would generally want to depend on the JCR API or a tool
based on the API (like JCR mapping) instead of a specific
implementation of the API. So you'd want a compile-time dependency on
"jcr" or "jackrabbit-jcr-mapping" instead of "jackrabbit-core".

> Ideally, Jackrabbit code would make a default mapping of "object models"
> (not just EMF) cleaner and easier than the Graffito code does.

I don't see any functional changes being introduced if the JCR mapping
tool is to move from Graffito to Jackrabbit.

BR,

Jukka Zitting

-- 
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

Mime
View raw message