The problem with o.a.j.o.api depending on Guava has been solved with OAK-3544. I plan to move the API package in its own bundle as part of OAK-3538.
After that, I will focus on the o.a.j.o.spi package. This is part of a bigger effort (OAK-3537) so, to keep things simple, I could also move in different bundles only some subpackages of o.a.j.o.spi, leaving the rest of oak-core for the time being. Anyway, I will have more concrete information as soon as I start digging into the problem. 2015-10-22 16:57 GMT+02:00 Francesco Mari <[email protected]>: > 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? >>
