Mailing-List: contact jackrabbit-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jackrabbit-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Non JSR 170 - JackRabbit Dependencies
Date: Tue, 28 Jun 2005 11:30:07 +0100
Message-ID: 
 <8D07567F3496FA4797E37564D4B4DC0E8465DC@delboy.lan.gossinteractive.com>
Thread-Topic: Non JSR 170 - JackRabbit Dependencies
thread-index: AcV7yibGWM1bEEupQVa+6Zq4MUM2JgAAKe+Q
From: "Simon Gash" <Simon.Gash@gossinteractive.com>
To: <jackrabbit-dev@incubator.apache.org>,
	"Stefan Guggisberg" <stefan.guggisberg@gmail.com>

Thanks for that Stefan, I guessed as much. I know this is a bit of a
guess but do you think there will be enough common ground amongst the
vendors for me to write an interface so that I can try to plug-in vendor
specific node type management.

I keep thinking this is a bit of a mad question, how on earth can anyone
anticipate how the vendors will implement node type management. I just
thought it might be worth a stab in the dark ;)

Thanks

Simon=20

-----Original Message-----
From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]=20
Sent: 28 June 2005 11:14
To: jackrabbit-dev@incubator.apache.org
Subject: Re: Non JSR 170 - JackRabbit Dependencies

ok, i see. your app is probably registering custom node types.=20
node type management has intentionally been left out
in version 1.0 of the spec. it's a very complicated matter
and it's difficult to reach a consensus. in the rdbms world
there's no standard for schemas and DDL, i guess for=20
similar reasons. the next version of the jsr 170 spec
will probably cover node type management but for the
time being you have to write vendor specific code if=20
you want to register your own node types.

as for your list of dependencies, i guess only the following
are really required:

import org.apache.jackrabbit.core.nodetype.NodeTypeDef;
import org.apache.jackrabbit.core.nodetype.NodeDefImpl;
import org.apache.jackrabbit.core.nodetype.NodeTypeRegistry;
import org.apache.jackrabbit.core.nodetype.PropDef;
import org.apache.jackrabbit.core.nodetype.PropDefImpl;
import org.apache.jackrabbit.core.QName;
import org.apache.jackrabbit.core.value.ValueHelper;
import org.apache.jackrabbit.core.util.ISO8601;

cheers
stefan

On 6/28/05, Simon Gash <Simon.Gash@gossinteractive.com> wrote:
> I've removed most of them but the following remain, I'm not sure if
I'm
> just using the API incorrectly but here they are :-
>=20
> import org.apache.jackrabbit.core.nodetype.NodeTypeDef;
> import org.apache.jackrabbit.core.nodetype.NodeDefImpl;
> import org.apache.jackrabbit.core.nodetype.NodeTypeImpl;
> import org.apache.jackrabbit.core.nodetype.NodeTypeRegistry;
> import org.apache.jackrabbit.core.nodetype.PropDef;
> import org.apache.jackrabbit.core.nodetype.PropDefImpl;
> import org.apache.jackrabbit.core.nodetype.PropertyDefinitionImpl;
>=20
> import org.apache.jackrabbit.core.QName;
> import org.apache.jackrabbit.core.value.ValueHelper;
> import org.apache.jackrabbit.core.util.ISO8601;
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> Sent: 28 June 2005 09:54
> To: jackrabbit-dev@incubator.apache.org
> Subject: Re: Non JSR 170 - JackRabbit Dependencies
>=20
> On 6/28/05, Simon Gash <Simon.Gash@gossinteractive.com> wrote:
> > What is everyone doing about the non-JSR 170 parts of JackRabbit. I
> > think there was already a mention of a commons type area. I'm trying
> to
> > remove all JackRabbit references from my solution but I've got a
bunch
> > left behind. I was hoping to be able to get to the situation where I
> can
> > just swap out JSR170 repositories is this going to be possible ?
>=20
> if you stick to the JCR api (javax.jcr.*) you should be safe.
> what jackrabbit references do you have?
>=20
> stefan
>=20
> >
> >
> >
> > My plan for now, was to hide them behind a common interface of my
own
> > design but will there be enough commonality between implementations
> for
> > this to work. Any ideas welcome...
> >
> >
> >
> > Thanks
> >
> >
> >
> > Simon
> >
> >
> > Come visit us at:
> >
> > Government Computing Expo. June 21 & 22, Earls Court, Stand # 804
> >
> > SOCITM Annual Event. October 16 - 18 Brighton Hotel, Stand # 28
> > GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and
> 88th in the Deloitte Technology Fast 500 EMEA.
> >
> > This email contains proprietary information, some or all of which
may
> be legally privileged. It is for the intended recipient only. If an
> addressing or transmission error has misdirected this email, please
> notify the author by replying to this email. If you are not the
intended
> recipient you may not use, disclose, distribute, copy, print or rely
on
> this email.
> >
> >
> >
> > Email transmission cannot be guaranteed to be secure or error free,
as
> information may be intercepted, corrupted, lost, destroyed, arrive
late
> or incomplete or contain viruses. This email and any files attached to
> it have been checked with virus detection software before
transmission.
> You should nonetheless carry out your own virus check before opening
any
> attachment. GOSS Interactive Ltd accepts no liability for any loss or
> damage that may be caused by software viruses.
> >
> >
> >
> >
>