I had a close look and it is a fat bundle containing jena libs (core,
iri, arq, tdb and sdb) including dependencies.

However there is an important remark inside:

"Embedding all Jena modules in a single OSGi bundle.
      This works around classloader issues such as Jena's use of
      Class.forName(), but does not yet support other OSGi bundles
      to easily plug in 3rd party Jena implementations of say readers
      and writers."


This probably applies to my bundles as well. Since Jena uses
Class.forName() only classes on the Jena bundle classpath can be used.
So any extensions like readers or writer can only be found if there is a
OSGI fragment adding those classes to the Jena bundle's classpath.

Regards,

Minto


Op 21-9-2013 13:06, Andy Seaborne schreef:
> I came across (but have not used)
>
> https://github.com/stain/jena/tree/jena-bundle/jena-bundle
>
>     Andy
>
> On 21/09/13 11:18, Minto van der Sluis wrote:
>> Hi Reto,
>>
>> See my remarks below.
>>
>> Regards,
>>
>> Minto
>>
>> Op 20-9-2013 20:51, Reto Bachmann-Gmür schreef:
>>> Hi Minto
>>>
>>> I will test the wrappers as soon as I can with the launchers
>> Thanks
>>> Regarding the location/svn layout: I agree with having a less flat
>>> project
>>> structure so I'm in favour if the ext folder. Howrver the license and
>>> notice files do not belong to there. They are added to the individual
>>> projects by a maven plugin. I don't see any advantage in moving it to
>>> servicemix. Changes of location tend to generate confusion and
>>> having it at
>>> clerezza might draw some interest for our project. In the long run
>>> it would
>>> of course be better if Jena would natively come as OSGi bundles.
>> License and Notice can be removed. They were copied from ServiceMix and
>> I wrongly assumed they were needed by the src-assembly dependency. But
>> src-assembly probably uses the license and notice from the wrapped jar
>> file. I will remove them
>>
>> Also I will get rid of the version numbers in the foldernames.
>>> What is the file: src/main/resources/OSGI_INFO/bundle.info?
>> See
>> http://karaf.apache.org/manual/latest-2.2.x/developers-guide/creating-bundles.html
>>
>>
>>> Why is the maven-shade plugin needed, and why isn't this is the
>>> bundles-pom?
>> Things where taken from ServiceMix as is. I only replaced ServiceMix
>> with Clerezza as much as possible. There is however still a ServiceMix
>> dependency in bundles-pom.
>>
>>                      <dependency>
>>                         
>> <groupId>org.apache.servicemix.bundles</groupId>
>>                          <artifactId>src-assembly</artifactId>
>>                          <version>1.0</version>
>>                      </dependency>
>>
>> I guess we want to get rid of this dependency as well, by creating our
>> own. I will copy the src-assembly from service mix.
>>
>>> Cheers,
>>> Reto
>>>
>>>
>>> On Fri, Sep 20, 2013 at 10:27 AM, Minto van der Sluis <[email protected]>
>>> wrote:
>>>
>>>> Hi folks,
>>>>
>>>> I just committed my work on the lean Apache jena ext wrappers. Please
>>>> have a close look. The ext bundles can be found in the newly
>>>> created ext
>>>> folder.
>>>>
>>>> Now I wonder how to continue with these new/ServiceMix style
>>>> wrappers. I
>>>> have the following questions:
>>>>
>>>> 1. Wrapper hosting.
>>>> Do we want to host/own these wrappers our selves or donate it to
>>>> ServiceMix. From what I read ServiceMix bundles are open for others to
>>>> donate wrappers. See
>>>> http://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk/
>>>>
>>>> 2. Wrapper versioning
>>>> When we decide to host ext wrappers ourselves then we should decide on
>>>> versioning these wrappers as well. Do we need separate wrappers for
>>>> separate version like ServiceMix has. For instance jena-core-2.10.0,
>>>> jena-core-2.10.1, jena-core-2.11.0, ... Personally I think we do not
>>>> need this. Once a version is release it could be tagged or branched in
>>>> svn (requires a change to what's currently committed). Also I think
>>>> that
>>>> within Clerezza we should stick to using a single version as much as
>>>> possible.
>>>>
>>>> 3. How to test within Clerezza
>>>> Since I only use part of Clerezza (rdf abstraction layer + jena
>>>> storage). I don't know how to test if these new wrappers work inside
>>>> clerezza as well. I could start with running all unittests. But I am
>>>> more concerned about the various launchers. How do I test if these
>>>> still
>>>> work.
>>>>
>>>> What remains to be done:
>>>> - remove the old ext jena wrappers (jena and jena.tdb)
>>>> - preferably use the ServiceMix style for all other ext bundles as
>>>> well.
>>>> - modify launchers/bundlelists to use the new ext wrappers (also add
>>>> required dependencies)
>>>>
>>>> Please let me know what you guys think.
>>>>
>>>> Regards,
>>>>
>>>> Minto
>>>>
>>
>>
>
>
>


-- 
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV

Mobiel: +31 (0) 626 014541

Reply via email to