[
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)
