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.
