jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: [VOTE] Revert the great split
Date Mon, 12 Sep 2005 10:38:16 GMT
On 9/12/05, Felix Meschberger <Felix.Meschberger@day.com> wrote:
> Hi,
> 
> >commons will go to: org.apache.jackrabbit.util.*
> >
> >
> Considering, what is now found in the commons library (name, util, uuid,
> value), I don't think those should be moved down the package hierarchy.
> In fact, these already are four distinct packages. The remaing classes
> in o.a.j, are not really "util" classes. They are rather common grounds,
> which IMHO is very well suited for o.a.j.
> 
> BTW: BaseException does not sound very interesting - what is it a basis
> for anyway ? How about renaming it to JackrabbitException ?

BaseException is the the *base* class of all implementation specific 
exceptions thrown by jr. i agree it's not a very significant name, 
therefore i wouldn't object to renaming it to JackrabbitException
if the result would be considered worth the considerable refactoring
effort.

> 
> BTW2: Is there are reason, why BaseException does not extend
> RepositoryException ?

to clearly distinguish between implementation specific (i.e. jackrabbit)
and api (i.e. jcr) exceptions. it my experience it helped a lot while 
implementing the jcr interfaces.

cheers
stefan

> 
> >core will go to: org.apache.jackrabbit.jcr.*
> >
> >
> Sounds good for me :-)
> 
> >api would go to: org.apache.jackrabbit.* but is currently empty.
> >
> >i'm not happy with the api packaging, but i can't come up with a
> >better solution.
> >
> >
> As there is no defined Jackrabbit API yet and considering that this API
> will not be that big, I think we can currently live with that situation.
> 
> >please note, that the refactoring will break all existing
> >configurations, since the class names (eg of the persistence managers)
> >are referenced in the xmls. maybe we could provide a backward
> >compatibility mapping in the config reader which logs a deprecation
> >warning. on the other hand, 1.0 is not released yet, and we should not
> >respect backward compatibility too much.
> >
> >
> I tend to agree with the last statement and not introduce deprecation
> and backward compatibility hacks in a not-yet-released product.
> 
> Regards
> Felix
> 
>

Mime
View raw message