[
https://issues.apache.org/jira/browse/JENA-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17581694#comment-17581694
]
Christoph Läubrich commented on JENA-2343:
------------------------------------------
> It seems to place a requirement on every java package having a
> {{{}package-info.java{}}}.
This is not strict requirement but the most easy way to maintain:
# {{package-info.java is standard java, so most developers should be aware of
it}}
# if you rename a package move it to another module it is automatically updated
# you can even simply copy such a file if you add a new package if you find it
should be exported
In contrast to this, one might maintain the list of exported packages in a
separate file, but that's easily forgotten or overlooked. Also, not every
package needs to be exported! I just exported anything here that seems "public"
that is omitting any shaded or "impl" packages. Also it will not break if one
misses to export a package, it just won't be available in OSGi and if someone
cares enough can provide a PR to add the required stuff.
> Can this be automated?
For sure one can simply put such a file everywhere, but as described above I
don't think this is required
> Can the maven enforcer plugin check that the presence of these files?
I never enforced this, but the enforcer seem to support custom rules, so if
someone finds this useful one might write a rule for that.
> I'm hoping to see trial use of this by other parties. This is something that
> has a long-term implication of support so I feel it needs validation as the
> right approach. Are there alternative approaches?
This is a bit chicken-egg problem, as long as there is no (dedicated) support
jena might be used less in OSGi applications or certain workaround are used
(e.g. embedding it in another jar, using company private rebuilds, ...) I think
[[email protected]] would be the right person to prototype this and give
feedback e.g. if this is available in a SNAPSHOT version so this could be
polished before a release.
> Other parties involvement also shows there will be some level of long-term
> sustainability; the usual software engineering concerns: tool-chains change,
> new requirements come along, security reports need addressing etc.
That's why I think it would be better to bake OSGi "into" jena artifacts than
the previous approach than maintain a separate "fat-osgi-jar", it will allow to
easier evolve the code (e.g. with the package-info instead of a separate config
file/module build). Also OSGi is quite mature, so the general concepts won't
change, the tools are very stable and it is supported by a wide range of big
companies: [https://www.osgi.org/membership/members/]
Also one goal of OSGi is to be non-intrusive, so there are many approaches
where you simply add some meta-data to the jar that makes certain things happen
_inside_ OSGi but simply gets ignored _outside_ OSGi so you always have the
choice where to run your jar. Because of this, many libraries are already OSGi
bundles even though most users don't notice this.
> Bring back OSGi support to Jena
> -------------------------------
>
> Key: JENA-2343
> URL: https://issues.apache.org/jira/browse/JENA-2343
> Project: Apache Jena
> Issue Type: Improvement
> Reporter: Christoph Läubrich
> Priority: Major
>
> With JENA-2165 and the announcement on the mailing list
> [https://lists.apache.org/thread/20h0djofj3h3dwtm728mcclv2zply9jt] OSGi
> support was dropped from the project due to missing expertise.
> I'd like to bring back OSGi support, hopefully in a way that is easier to
> maintain and offer to help if questions arise later on.
> My plan would be the following:
> # Add OSGi header to the Jena artifacts, in contrast to the previous
> approach of generating a fat-jar, this could be done immediately and will not
> harm as it only *enables* the use inside OSGi but users of Jena are
> responsible to provide the missing glues their selfes.
> # I have [proposed a new framework running
> mode|https://github.com/osgi/osgi-test/issues/541] to the osgi-test project,
> that will finally make test-setups much more easier and will allow to run
> test from the current build and inside the usual Jena test-suite, so once
> this is merged I'd like to add tests and even missing pieces to improve OSGi
> user experience so less setup is required to actually use Jena inside OSGi
> I'll also forward this issue to some other people interested in Jean OSGi
> support to get more feedback and attention for this feature.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
