Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of tripod@day.com designates
 62.192.10.254 as permitted sender)
Message-ID: <ffd6aaa90805082357y42bfe5aub087d10575da95e2@mail.gmail.com>
Date: Fri, 9 May 2008 08:57:30 +0200
From: "Tobias Bocanegra" <tobias.bocanegra@day.com>
Sender: tripod@day.com
To: dev@jackrabbit.apache.org
Subject: Re: extending the jackrabbit-api
In-Reply-To: <A047748A00BCDC4794D0D3FB35009F841D8130@repbex02.amer.bea.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <ffd6aaa90805081248l7b9c4541i126fc766cb418ad2@mail.gmail.com>
	 <A047748A00BCDC4794D0D3FB35009F841D8130@repbex02.amer.bea.com>

On 5/9/08, Esteban Franqueiro <efranque@bea.com> wrote:
> I think it's a good idea, as long as we don't have to keep those interfaces there for
> backcompatibility, and we can drop them quickly.
yes, that was the idea. alternatively we could also create an interim
project module, jackrabbit-jsr283-api and drop that later. this way,
we don't need to "clutter" the jackrabbit-api.

--
toby


>  Regards,
>
>  Esteban Franqueiro
>  esteban.franqueiro@bea.com
>
>  ________________________________
>
>  De: tripod@day.com en nombre de Tobias Bocanegra
>  Enviado el: jue 08/05/2008 16:48
>  Para: dev@jackrabbit.apache.org
>  Asunto: extending the jackrabbit-api
>
>
>
>
>  hi,
>  as the implementation of the new features for jsr283 have started, i
>  suggest to put the new jsr283 interfaces to jackrabbit-api instead to
>  core (where possible). this way, we can already figure out
>  inter-module dependency issues and people can start using experimental
>  features through an API than rather through casting objects to core
>  interfaces.
>
>  suggestion: use 'org.apache.jackrabbit.api.jsr283' as base package for
>  the new jsr283 interfaces and classes.
>
>  for example, use
>  org.apache.jackrabbit.api.jsr283.nodetype.NodeDefinitionTemplate
>  for the future javax.jcr.nodetype.NodeDefinitionTemplate
>
>  once jcr2.0 is released, we can either extend them from the 'real'
>  interfaces or just drop them. in any case it might make sense to mark
>  them as deprecated from start.
>
>  WDYT?
>
>  --
>  regards, toby
>
>
>
>
> Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
>