You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@jena.apache.org by "Andy Seaborne (Jira)" <ji...@apache.org> on 2022/08/24 12:26:00 UTC
[jira] [Comment Edited] (JENA-2343) Bring back OSGi support to Jena
[ https://issues.apache.org/jira/browse/JENA-2343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17584227#comment-17584227 ]
Andy Seaborne edited comment on JENA-2343 at 8/24/22 12:25 PM:
---------------------------------------------------------------
{quote}most easy way to maintain:
{quote}
The burden is now on contributors who add a java package, and who don't use OSGI, and also on the PR reviewers.
{quote}> 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, ...)
{quote}
"Trial" here is use of snapshot artifacts or local build. The old OSGi support got dropped because we heard of no actual use when it broke.
Downstream builds are not a bad thing for open source.
Can it be done in the POM?
I tried in jena-arq:
[https://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#_adding_osgi_metadata_to_existing_projects_without_changing_the_packaging_type]
{noformat}
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>5.1.8</version>
<executions>
<execution>
<id>bundle-manifest</id>
<phase>process-classes</phase>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
<manifestEntries>
<Automatic-Module-Name>${automatic.module.name}</Automatic-Module-Name>
</manifestEntries>
</archive>
</configuration>
</plugin>
{noformat}
and got OSGi metadata in the jar with, importantly, {{{}Automatic-Module-Name{}}}.
That needs tidying - it is only illustration of concept - it needs some work to put the OSGi info in the jar but not in the test jar.
There are other ways - such as exporting by pattern - which I haven't tried.
was (Author: andy.seaborne):
{quote}most easy way to maintain:
{quote}
The burden is now on contributors who add a java package, and who don't use OSGI, and also on the PR reviewers.
{quote}> 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, ...)
{quote}
"Trial" here is use of snapshot artifacts or local build. The old OSGi support got dropped because we heard of no actual use when it broke.
Downstream builds are not a bad thing for open source.
Can it be done in the POM?
I tried in jena-arq:
[https://felix.apache.org/documentation/subprojects/apache-felix-maven-bundle-plugin-bnd.html#_adding_osgi_metadata_to_existing_projects_without_changing_the_packaging_type]
{noformat}
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>5.1.8</version>
<executions>
<execution>
<id>bundle-manifest</id>
<phase>process-classes</phase>
<goals>
<goal>manifest</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
<manifestEntries>
<Automatic-Module-Name>${automatic.module.name}</Automatic-Module-Name>
</manifestEntries>
</archive>
</configuration>
</plugin>
{noformat}
and got OSGi metadata in the jar with, importantly, {{{}Automatic-Module-Name{}}}.
(that needs tidying - it is only illustration of concept - it needs some work to put the OSGi info in the jar but not in the test jar).
> 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: jira-unsubscribe@jena.apache.org
For additional commands, e-mail: jira-help@jena.apache.org