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
angela
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<[email protected]> 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
