Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Reusable OSGi implementations

Avatar

Level 3

I came across this architectural challenge, which is maintaining all shared business Java logic in a separate Common-Project that includes some common API in a bundle Common-Bundle and also a Common-Bundle-Impl that provides the shared implementation for that general API.

The issue here is that sharing the implementation, therefore exporting the impl package, violates one of the OSGi best practises: you should never export implementation packages to consumers.

I will try to explain it with an example, that might help understand my argument:

As exposed above, say we have a Common-Project, which includes 2 bundles in its package:

- Common-Bundle, with all the exposed API

- Common-Bundle-Impl, which provides the implementation for this API that will be used by other bundles.

In the other hand we have ProjectA and ProjectB, that need to consume this API and implementation.

Both need to add some specific methods by extending the API classes, at the same time they want to be able to extend the existing implementation instead of copying and pasting the code from the Common-Bundle-Impl.

The only approach I found to implement this is by exporting the implementation packages in Common-Bundle-Impl

          <plugin>

                <groupId>org.apache.felix</groupId>

                <artifactId>maven-bundle-plugin</artifactId>

                <extensions>true</extensions>

                <configuration>

                    <instructions>

                        <Export-Package>my.org.common.package.impl.*</Export-Package>

                    </instructions>

                </configuration>

            </plugin>

And from the ProjectA and ProjectB, add the dependency to this package.

Is there any workaround/approach I am missing here? In the real world scenario I might have 10+ projects making use of this implementation, so it would not be ideal to have the same code implemented across all projects in their corresponding impl classes. I would also like to avoid exporting impl packages and follow OSGi best practises.

Any ideas, feedback, comments would be greatly appreciated.

1 Accepted Solution

Avatar

Correct answer by
Level 10

If your projects need the APIs in this package - then from what i am seeing - you need to export this package. Typically, an Impl is only consumed by the APIs in that package.

View solution in original post

1 Reply

Avatar

Correct answer by
Level 10

If your projects need the APIs in this package - then from what i am seeing - you need to export this package. Typically, an Impl is only consumed by the APIs in that package.