felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Domingues <pedro.doming...@ist.utl.pt>
Subject Re: Help in using your Quartz OSGi bundle
Date Mon, 19 Oct 2015 15:56:07 GMT
Thank you for your help so far guys. And I'm sorry for sending this huge 
wall of text twice to this mailing list, it was a mistake.

Neil, yes I can't wait for the JigSaw project promised for Java 9! 
However I think developers will still be creating coarse-grained bundles 
depending on half of the internet. Maybe the only difference will be 
that jigsaw will be able to resolve all dependencies automatically using 
a central repository, without even bother us developers. Also decreasing 
the price of each external dependency, further promoting developers to 
depend on half the internet yet again.

As you said, it is the library's developers who need to take the 
responsibility of modularizing their library the best way possible. 
Unfortunately OSGi is rarely used compared to other frameworks, so the 
price to pay to have a vary bad port to OSGi is actually quite low.

On the other hand, for the people who bundelize these third-party 
libraries, for example in the Quartz example, why do they released a 
bundle having dependencies? For me a perfect bundelization would be a 
single bundle with no Import-Packages at all, and with every dependency 
embed inside of it. Even if the jar file ends up with 50mb in size, 
because the point here is to have the developer freed from the task of 
manual dependency resolution. In contrast I could just use a very 
complete OBR repo and resolve all Quartz's Imports with it. However only 
the first line of imports have manifest files, most of Quartz 
dependencies are not bundles so the OBR would render useless because, 
like you said, no one will guess what are the dependencies of c3p0 or 
oracle.sql if they do not state them in the manifest.

Note that I am using quartz as an example of every other third-party one 
tries to import to its OSGi project.

In practice, using OSGi equates to not being able to use several 
libraries available in Java which would reduce our development 
time/effort/cost, in exchange of being able to create a properly modular 
architecture in order to reduce development time/effort/cost. Ironic 
isn't it? So in the end does OSGi provide us with any advantage in its 
current state of affairs?

How could we solve this issue?

On 19/10/2015 15:16, Neil Bartlett wrote:
> And to your colleagues who prefer to quit OSGi because of these problems: just wait till
the Java 9 Module System comes along.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message