hi all
ok... i will give it a try and create a oak-commons module.
i think this will help removing obvious redundancies and cleanup
code... we can still drop it later on or move things to a
generic jackrabbit-commons package if we find it isn't useful.
> On Fri, Apr 27, 2012 at 12:08 PM, Angela Schreiber<anchela@adobe.com> wrote:
>> a) create oak-commons module and move the various utilities
>> used in multiple projects there... including merging
>> 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).
agreed.
> 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
>> standard form in all oak layers this would allow even
>> 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.
that's yet another story... the problem is that jcr-commons isn't
just about jcr-specific stuff but contains all kind of utilities
that have nothing to do with JCR.
i will just focus on the plain utilities in a first step
angela
> BR,
>
> Jukka Zitting
|