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
