[ https://issues.apache.org/jira/browse/DERBY-7056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16955390#comment-16955390 ]
Christoph Läubrich commented on DERBY-7056: ------------------------------------------- If you want to learn and understand all the details, you should start here as it is the normative source: https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#i3065034 the interesting most relevant parts for this issue are: * *Bundle-ManifestVersion* (is alway 2) * *Bundle-SymbolicName* recommended here is the package name / reverse domain name, some projects choose to use the name of the jar, for example 'org.apache.derby.client' * *Bundle-Version* you would probably choose the release version here, even though in a perfect world this would be a [semantic version|https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf] * *Import-Package* this list all packages you +require from the outside world+ (excluding java.* packages if you target for java below v9 or including them if you target for java >= 9) or packages from other derby modules not part of the current jar * *Export-Package* this list all packages you want to +make available to the outside world+ e.g there might be so called 'internal packages' that are not intended for client to use you might want to choose not export them but as a first step you simply can export all * Import/Export should, whenever possible, try to use the semantic-versioning for provider/consumer constraint as described in short [here|https://osgi.org/specification/osgi.core/7.0.0/framework.module.html#framework.module-semantic.versioning], a more detailed description can be found in this [whitepaper|https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf]. For external dependencys you should always use that, for interal (derby) dependencies you might want to use release-versions as well. As this can become tricky, bnd offers a way to compute this headers as part of your build, its a while since I used ant, but will try to take a look at the source and come up with an example later. > Make Derby modules usable by OSGi-aware applications > ---------------------------------------------------- > > Key: DERBY-7056 > URL: https://issues.apache.org/jira/browse/DERBY-7056 > Project: Derby > Issue Type: Task > Components: Build tools > Affects Versions: 10.15.1.3 > Reporter: Richard N. Hillegas > Assignee: Richard N. Hillegas > Priority: Major > > OSGi R7 introduced support for JPMS modules in 2018 according to > https://blog.osgi.org/2018/02/osgi-r7-highlights-java-9-support.html. This > includes additional information which goes into jar file manifests. Support > for this OSGi information was requested by an email thread on the user list: > http://apache-database.10148.n7.nabble.com/OSGi-manifest-headers-td150560.html. > We need advice from OSGi experts on how to make Derby modules usable by > OSGi-aware applications. -- This message was sent by Atlassian Jira (v8.3.4#803005)