RE: Non JSR 170 - JackRabbit Dependencies

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 

-----Original Message-----
From: Stefan Guggisberg [mailto:stefan.guggisberg@xxxxxxxxx] 
Sent: 28 June 2005 11:14
To: jackrabbit-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: Non JSR 170 - JackRabbit Dependencies

ok, i see. your app is probably registering custom node types. 
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 
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 
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@xxxxxxxxxxxxxxxxxxx> 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 :-
> 
> 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;
> 
> import org.apache.jackrabbit.core.QName;
> import org.apache.jackrabbit.core.value.ValueHelper;
> import org.apache.jackrabbit.core.util.ISO8601;
> 
> 
> 
> 
> -----Original Message-----
> From: Stefan Guggisberg [mailto:stefan.guggisberg@xxxxxxxxx]
> Sent: 28 June 2005 09:54
> To: jackrabbit-dev@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: Non JSR 170 - JackRabbit Dependencies
> 
> On 6/28/05, Simon Gash <Simon.Gash@xxxxxxxxxxxxxxxxxxx> 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 ?
> 
> if you stick to the JCR api (javax.jcr.*) you should be safe.
> what jackrabbit references do you have?
> 
> stefan
> 
> >
> >
> >
> > 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.
> >
> >
> >
> >
>