I already have a working checkout on my local machine where the o.a.j.o.api package is part of its own bundle. This package is quite independent, except for the Type class. The Type class has dependencies on com.google.common.base and com.google.common.collect, that should be somehow removed: who wants an API package depending on Guava?
Another question related to the API package is how to handle o.a.j.o.api.jmx. Even if it may be contained in the same bundle of o.a.j.o.api, we should think twice before putting them together. The ContentRepository API and the monitoring information about the repository have two very different purposes and may change at a very different pace. Maybe using two different bundles for these two packages may be a good idea. 2015-10-22 16:34 GMT+02:00 Angela Schreiber <[email protected]>: > hi francesco > > wouldn't it be easier to start with o.a.j.o.api package first? > also that package has been very stable over the last months > and would IMO be a better candidate than the spi. > > also the spi contains so many different things that most > probably should rather be split (i.e. security from the > state and commit stuff). fwiw we already have other > modules that cover the spi package space. > > kind regards > angela > > On 22/10/15 16:01, "Francesco Mari" <[email protected]> wrote: > >>Hi, >> >>I recently started looking into the o.a.j.o.spi package to figure out >>if it would be possible to decouple it from oak-core, but I found out >>that many implementation classes live there. >> >>In particular, almost every subpackage contains default >>implementations of proper SPI interfaces, like CompositeEditor, >>CompositeHook, EmptyHook, etc. These classes should probably be part >>of a utility package instead. >> >>These default implementations make o.a.j.o.spi (and its subpackages) >>transitively depend on many other implementation packages, while I >>expect an SPI package to depend only on other SPI and API packages. >> >>What about moving the implementation classes into different utility >>packages? >
