jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Consolidate oak Utilities
Date Fri, 27 Apr 2012 16:02:40 GMT
hi all

i created the oak-commons module and as of now moved
mk-PathUtils and mk-ArrayUtils there. that's an intermediate
state, more to come.
consequently i merged the Arrays utility in oak-jcr to the
ArrayUtils (include getting rid of duplicate unused methods).

with that step the Paths utility got reduced to just the toOak
and toJcr methods and i decided to change the utility
to a PathMapper interface + implementation according to the
one we have for the name mapping and adjusted SessionContext and
the various usages accordingly.

hope that's fine with everyone :)

kind regards

ps: while working on the latter i got a tck-test-failure due
to namemapper throwing illegalargumentexception instead of
NamespaceException... don't know why that passed before.
anyway: i commented the test-case for now.
the exception handling stuff is in fact covered by another
thread but due to the progress we made during the last
days this now all comes together :)

On 4/27/12 4:02 PM, Angela Schreiber wrote:
> 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

View raw message