You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Francesco Mari <ma...@gmail.com> on 2015/10/22 16:01:00 UTC
Implementation classes in o.a.j.o.spi package
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?
Re: Implementation classes in o.a.j.o.spi package
Posted by Francesco Mari <ma...@gmail.com>.
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 <ma...@gmail.com>:
> 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 <an...@adobe.com>:
>> 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" <ma...@gmail.com> 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?
>>
Re: Implementation classes in o.a.j.o.spi package
Posted by Francesco Mari <ma...@gmail.com>.
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 <an...@adobe.com>:
> 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" <ma...@gmail.com> 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?
>
Re: Implementation classes in o.a.j.o.spi package
Posted by Angela Schreiber <an...@adobe.com>.
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" <ma...@gmail.com> 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?