Hi, We started to work on bundle definition with JB to have a quick fix for the next 1.4.1 release.
I tagged all the OSGi and Karaf related issues in Jira to the 1.4.1: https://issues.apache.org/jira/projects/SHIRO/versions/12344826 I think we can fix most of them with maven-bundle-plugin but other OSGi works need more impact like: * package refactoring * library upgrade * JDK upgrade to 8 This work will be a part of the 2.x release :) @Steinar: thanks for your contributions! Regards, François Papon [email protected] Le 14/01/2019 à 23:37, Brian Demers a écrit : > Thanks! I'll take another look! > > Moving forward for 2.x we can fix any package names and make sure we doing > have any overlap between modules (which should help with this too) > > On Mon, Jan 14, 2019 at 12:27 PM Steinar Bang <[email protected]> wrote: > >>>>>>> Brian Demers <[email protected]>: >> >>> I gave this a quick try, I added this config to the root pom and rebuilt >>> master. There are still duplicate classes added to shiro-core (from at >>> least the "lang" module) >>> Any ideas? >> Firstly: the config I posted wasn't complete. What I posted was just >> the part related to make it run on projects with packaging jar and war. >> >> I'll post my most recent top-POM pluginManagement below. >> >> Secondly: the only sure way I've found to avoid the duplicate imported >> classes issue, is to explicitly list the exported packages. >> >> I've seen this issue mostly when rebundling non-bundle jars. >> >> Here's my most recent parent-POM pluginManagment entry for >> maven-bundle-plugin: >> <plugin> >> <groupId>org.apache.felix</groupId> >> <artifactId>maven-bundle-plugin</artifactId> >> <version>3.5.1</version> >> <configuration> >> <supportedProjectTypes> >> >> <supportedProjectType>jar</supportedProjectType> >> >> <supportedProjectType>bundle</supportedProjectType> >> >> <supportedProjectType>war</supportedProjectType> >> </supportedProjectTypes> >> <instructions> >> <!-- Enable processing of OSGI DS component >> annotations --> >> <_dsannotations>*</_dsannotations> >> <!-- Inherit service injections from base >> class --> >> >> <_dsannotations-options>inherit</_dsannotations-options> >> <!-- Enable processing of OSGI metatype >> annotations --> >> <_metatypeannotations>*</_metatypeannotations> >> </instructions> >> </configuration> >> <executions> >> <execution> >> <id>bundle</id> >> <goals> >> <goal>bundle</goal> >> </goals> >> </execution> >> </executions> >> </plugin> >> >> The actual <plugins> entry for the service definition module (contains >> only interfaces and beans used as parameters and return values) looks >> like this: >> <plugin> >> <groupId>org.apache.felix</groupId> >> <artifactId>maven-bundle-plugin</artifactId> >> </plugin> >> >> This enough to get no foreign classes being pulled into the bundle and a >> manifest.mf looking like this: >> Manifest-Version: 1.0 >> Bnd-LastModified: 1547486363159 >> Build-Jdk: 1.8.0_181 >> Built-By: sb >> Bundle-ManifestVersion: 2 >> Bundle-Name: Handleregistrering OSGi service definitions >> Bundle-SymbolicName: no.priv.bang.handlereg.services >> Bundle-Version: 1.0.0.SNAPSHOT >> Created-By: Apache Maven Bundle Plugin >> Export-Package: no.bang.priv.handlereg.services;uses:="javax.sql";vers >> ion="1.0.0" >> Import-Package: javax.sql >> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))" >> Tool: Bnd-3.5.0.201709291849 >> >> But I wonder if this is because the package matches the >> bundle-symbolicname...? >> >> The bundle-symbolicname is created by combining the groupId and >> artifactId in a way that overlaps (the default bundle plugin behaviour >> if I remember correctly). >> >> Ie. >> <groupId>no.priv.bang.handlereg</groupId> >> <artifactId>handlereg.services</artifactId> >> results in >> Bundle-SymbolicName: no.priv.bang.handlereg.services >> and if that also is the package name then everything works >> automagically. >>
