Separating API/SPI in different bundles (was: svn commit: r1561926 - /jackrabbit/oak/tags/jackrabbit-oak-core-0.15.2/pom.xml)

[Tobias Bocanegra <tr...@apache.org>]

Hi,

On Tue, Jan 28, 2014 at 1:54 AM, Chetan Mehrotra
<ch...@gmail.com> wrote:
> On Tue, Jan 28, 2014 at 7:41 AM,  <tr...@apache.org> wrote:
>> +              org.apache.jackrabbit.oak;version="0.15.0",
>> +              org.apache.jackrabbit.oak.api;version="0.15.0",
>> +              org.apache.jackrabbit.oak.api.jmx;version="0.15.0",
>
> We should version packages independent of Oak release version.
definitely!

> Probably a better way would be to
>
> 1. Add explicit package-info.java with correct bnd version
> annotations. Then we need not explicitly list down package names in
> pom.xml
yes. I always wanted to do this, but was too lazy/busy in the end. I created
https://issues.apache.org/jira/browse/OAK-1362 to track this.

> 2. Untill we have  a 1.0 release we can set the package version to
> 1.0.0 and not change it if even if any API changes considering that
> pre 1.0 builds are to be considered as unstable wrt API
right.

> Post 1.0 we take care to bump the version as per OSGi Sematic Version
> guidelines [1]
definitely.

I also think that the amount of exported packages is very large. It
looks like we didn't really know how to modularize oak and just
exported basically everything :-) I suggest to separate some API (and
SPI) bits into separate bundles (see OAK-1238 and OAK-1239). This
certainly raises awareness of the modularization also for non-osgi
setups.

regards, toby

>
> Chetan Mehrotra
> [1] http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf

Re: Separating API/SPI in different bundles (was: svn commit: r1561926 - /jackrabbit/oak/tags/jackrabbit-oak-core-0.15.2/pom.xml)

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Jan 28, 2014 at 2:32 PM, Tobias Bocanegra <tr...@apache.org> wrote:
> I also think that the amount of exported packages is very large. It
> looks like we didn't really know how to modularize oak and just
> exported basically everything :-)

That's a pretty broad statement. Yes, there are a few cases where the
package-level dependencies should be fixed to avoid exporting too many
details, but most of the exported packages don't fall into this
category. In fact one could come to the exact opposite conclusion: a
modular system necessarily exports lots of packages. At least one
package for each distinct extension point and often a supporting
package of base classes and utility code related to that extension
point. Just look at the number of exported packages in a Sling system.

Instead of splitting code to separate API/SPI bundles (What would the
SPI bundle be anyway? Instead of one monolithic facade, the Oak SPI
consists of various more or less independent extension points, whose
main shared feature is just that they're used by oak-core, making a
standalone SPI bundle an odd construct.), a more productive approach
would IMHO be to look at the exports individually and refactor the
code to fix cases where an export shouldn't exist.

BR,

Jukka Zitting