Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com
 designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F9A7006.2050802@adobe.com>
References: <4F9A7006.2050802@adobe.com>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Fri, 27 Apr 2012 12:39:27 +0200
Message-ID: 
 <CAOFYJNYc_BAZSM3HEqGZmUym3yHGA5wd6VA0DYERR6sGS-FDFQ@mail.gmail.com>
Subject: Re: Consolidate oak Utilities
To: oak-dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, Apr 27, 2012 at 12:08 PM, Angela Schreiber <anchela@adobe.com> wrot=
e:
> a) create oak-commons module and move the various utilities
> =A0 used in multiple projects there... including merging
> =A0 redundant/duplicate/very-similar code.

+1 for cases where there's obvious duplication of code across
components. However, to me many such cases seem like warning signs of
potentially broken interface design, so it would be good to review
such cases (possibly after they've been moved to a shared commons
component).

For example (and I know this has been discussed at length already),
much of the path and json/p handling code shared between -core and -mk
is just there to first generate jsop strings and then parse them
again. It's obviously good to avoid duplicating such code, but even
better if we could avoid it in the first place.

> b) move the utilities to jcr-commons. since we use jcr
> =A0 standard form in all oak layers this would allow even
> =A0 a broader audience to take advantage of those utilities.

+1 to things that are needed in oak-jcr and some of the JCR-specific
plugins (name and type validation, etc.) in oak-core.

BR,

Jukka Zitting