Re: Help in using your Quartz OSGi bundle

[Pedro Domingues]

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-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: Help in using your Quartz OSGi bundle

[Chetan Mehrotra]

On Mon, Oct 19, 2015 at 6:52 PM, Pedro Domingues
 wrote:
> These are not a bundles, these are entire projects wrapped into a jar with a
> MANIFEST.MF file. I see my only option, as of now, to import manually each
> quartz dependency, one by one, until no unresolved imports are left or class
> not found exceptions are thrown (yeah, because most of those transitive
> dependencies are not bundles!).

Have a look at Sling Common Scheduler bundle [1] which *embeds*
Quartz. Might be of some help

Chetan Mehrotra
[1] https://github.com/apache/sling/blob/trunk/bundles/commons/scheduler/pom.xml

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

Re: Help in using your Quartz OSGi bundle

[Neil Bartlett]

yeah, because most of those transitive 
> dependencies are not bundles!).
> 
> I have been in several projects these last 2 years which tried to make use of 
> OSGi. These three issues were prevalent:
> * *Lack of up-to-date documentation *about the tools we should use to build, 
> manage and deploy OSGi projects (maven-bundle-plugin, tycho, bndtools, 
> gradle, bnd, ant, karaf, etc.), most examples are just "hello-world" 
> examples, none of them cares with dependency management;
> * *Lack of a dependency management system *to automatically resolve 
> transitive dependencies;
> * *The OSGi community size is very small*, and the few people who try to 
> contribute do not always follow the good practices (specially with 
> bundelization of third-party libraries, were many imports are left unresolved 
> in the final bundle, or the third-party library isn't divided into 
> fine-grained bundles---which I am aware it is a very hard achievement for 
> most libraries, since most of them depend on the whole Internet).
> 
> In the end these are the reasons why everyone I know quits from OSGi, and I, 
> as an OSGi user have to face on a daily basis.
> Compare the effort of, in a basic Eclipse project you import the quartz jar 
> to the build path, you use it, build the project and everything goes fine. In 
> contrast, with OSGi you import quartz to your OSGi container (usually Felix, 
> unless you want to mess with equinox in an Eclipse environment, which is an 
> undocumented mess), and when you try to launch your container you witness the 
> gates of hell opening before you.


"Everything goes fine”? Pull the other one. You still have to make sure all the 
dependencies are there, or you will get a ClassNotFoundException or 
NoClassDefFoundError at runtime. OSGi doesn’t change the FACT that Quartz has 
all these dependencies. It just moves forward the error checking.

> 
> I have searched, made blog posts, made stackoverflow posts asking about the 
> transitive dependencies issue in OSGi, it seems that there is no solution so 
> far, of there is, there is no documentation of it. It doesn't help just 
> saying "ah use this or that tool", no... there must be documentation, not 
> just for hello-world scenarios where you have little or no dependencies, not 
> just to this specific transitive dependency, but for all transitive 
> dependencies. Undocumented tools do not exist, only for their creators.

I would document the “transitive dependencies issue in OSGi” if I understood 
it. Software has dependencies, and sometimes those dependencies have other 
dependencies. They all have to be satisfied or the software will not run. What 
is the issue exactly?

> 
> I am sure I am beating some people out of their comfort zone with this e-mail 
> but I can't take it anymore. No matter How I try to defend the OSGi project 
> because I truly believe in the philosophy behind true modular programming 
> (like the books explain), I cannot keep pushing forward alone. Most of the 
> times I feel I am alone in this community, and in the end I dont even 
> understand how can the authors of those books put in practice their teachings 
> in a mess like this…!


Maybe they just didn’t use Quartz. I mean, is it really the only alternative 
here? How hard can scheduling be??

I understand your frustration with tooling and documentation, I really do. I 
started the Bndtools project because I needed it for myself, which means the 
documentation is never where I would like it to be. But also, I (and other 
developers working on OSGi tools) cannot test with every damn library out there.

Also, I don’t have the patience to make somebody else’s crappy software work. 
The Java ecosystem is massive, and if a library doesn’t work then I won’t keep 
trying for weeks to make it work… I look for an alternative. If there is no 
alternative, I write my own. This position isn’t unique to OSGi and/or Java, I 
have had the same experience with crappy libraries in C/C++ and Haskell.

And to your colleagues who prefer to quit OSGi because of these problems: just 
wait till the Java 9 Module System comes along.

Neil

> 
> Sorry...
> 
> On 13/10/2015 23:24, Pedro Domingues wrote:
>> Thank you guys for your suggestions. I am gonna try them to see what fits 
>> best!
>> 
>> Best regards
>> 
>> On October 12, 2015 10:28:09 PM WEST, Paulo Renato de Athaydes 
>>  wrote:
>>> Yeah, I had already suggested that was probably the best solution
>>> My previous message had a huge blank space in the middle which I have
>>> no idea where it came from!!
>>> But it became a personal challenge to get that old c3p0 jar and quartz
>>> working in a OSGi environment.
>>> :)
>>> Renato
>>> 
>>&g

Re: Help in using your Quartz OSGi bundle

[Pedro Domingues]

documented mess), and when you try to launch 
your container you witness the gates of hell opening before you.


I have searched, made blog posts, made stackoverflow posts asking about 
the transitive dependencies issue in OSGi, it seems that there is no 
solution so far, of there is, there is no documentation of it. It 
doesn't help just saying "ah use this or that tool", no... there must be 
documentation, not just for hello-world scenarios where you have little 
or no dependencies, not just to this specific transitive dependency, but 
for all transitive dependencies. Undocumented tools do not exist, only 
for their creators.


I am sure I am beating some people out of their comfort zone with this 
e-mail but I can't take it anymore. No matter How I try to defend the 
OSGi project because I truly believe in the philosophy behind true 
modular programming (like the books explain), I cannot keep pushing 
forward alone. Most of the times I feel I am alone in this community, 
and in the end I dont even understand how can the authors of those books 
put in practice their teachings in a mess like this...!


Sorry...

On 13/10/2015 23:24, Pedro Domingues wrote:

Thank you guys for your suggestions. I am gonna try them to see what fits best!

Best regards

On October 12, 2015 10:28:09 PM WEST, Paulo Renato de Athaydes 
 wrote:

Yeah, I had already suggested that was probably the best solution
My previous message had a huge blank space in the middle which I have
no idea where it came from!!
But it became a personal challenge to get that old c3p0 jar and quartz
working in a OSGi environment.
:)
Renato


Date: Mon, 12 Oct 2015 23:23:27 +0200
Subject: Re: Help in using your Quartz OSGi bundle
From: fr...@frankjlangel.com
To: users@felix.apache.org

Have you considered using amdatu-scheduling, a fully wrapped Quartz

OSGI bundle?



On 10/12/15, 11:16 PM, "Neil Bartlett"  wrote:


The import of the c3p0 package is problematic because c3p0 is not an

OSGi bundle. However there is a bundle wrapping availabe:
http://jpm4j.org/#!/p/sha/376EA3C3654A3E0593D1C135A7109ECE77D0BE70//0.0.0

Incidentally, c3p0 apparently hasn’t been updated or maintained for

over 8 years, so it’s a bit dubious to be using something like that in
a production application.

Neil




On 12 Oct 2015, at 22:07, Paulo Renato de Athaydes

 wrote:





The quartz bundle has the following imports:
Import-Package:

com.mchange.v2.c3p0,commonj.work;resolution:=optional,
javax.ejb;resolution:=optional,javax.jms;resolution:=optional,javax.m
ail;resolution:=optional,javax.mail.internet;resolution:=optional,jav
ax.management,javax.management.openmbean,javax.naming,javax.servlet;r
esolution:=optional,javax.servlet.http;resolution:=optional,javax.sql
;resolution:=optional,javax.transaction;resolution:=optional,javax.xm
l.bind,javax.xml.namespace,javax.xml.parsers,javax.xml.xpath,oracle.s
ql;resolution:=optional,org.jboss.logging;resolution:=optional,org.jb
oss.naming;resolution:=optional,org.jboss.system;resolution:=optional
,org.quartz,org.quartz.core,org.quartz.impl.matchers,org.quartz.impl.
triggers,org.quartz.jobs;resolution:=optional,org.quartz.spi,org.slf4
j;version="[1.6,2)",org.terracotta.toolkit;resolution:=optional,org.t
erracotta.toolkit.atomic;resolution:=optional,org.terracotta.toolkit.
builder;resolution:=optional,org.terracotta.toolkit.cluster;resolutio
n:=optional,org.terracotta.toolkit.collections;resolution:=optional,o
rg.terracotta.toolkit.concurrent.locks;resolution:=optional,org.terra
cotta.toolkit.config;resolution:=optional,org.terracotta.toolkit.inte
rnal;resolution:=optional,org.terracotta.toolkit.internal.concurrent.
locks;resolution:=optional,org.terracotta.toolkit.rejoin;resolution:=
optional,org.terracotta.toolkit.search;resolution:=optional,org.terra
cotta.toolkit.search.attribute;resolution:=optional,org.terracotta.to
olkit.store;resolution:=optional,org.w3c.dom,org.xml.sax,weblogic.jdb
c.jts;resolution:=optional,weblogic.jdbc.vendor.oracle;resolution:=op
tional

The required dependencies (not optional) are the following:
com.mchange.v2.c3p0


















































































































































































javax.managementjavax.management.openmbean
javax.naming
javax.xml.bind
javax.xml.namespace
javax.xml.parsers
javax.xml.xpath
org.quartz
org.quartz.core
org.quartz.impl.matchers
org.quartz.impl. triggers
org.quartz.spi
org.slf4 j;version="[1.6,2)"
org.w3c.dom
org.xml.sax


The first one, c3p0, comes from this artifact:
"c3p0:c3p0:0.9.1.1"

Which is not a OSGi bundle. (the others, except quartz which comes

>from the jar itself, don't seem to be a problem as the framework seems

happy to provide those).


I wrapped it in a bundle anyway using osgi-run and then, after

installing them in Felix, I found out we need some logging libraries,
org.sfl4j.api, 

RE: Help in using your Quartz OSGi bundle

[Pedro Domingues]

Thank you guys for your suggestions. I am gonna try them to see what fits best! 

Best regards 

On October 12, 2015 10:28:09 PM WEST, Paulo Renato de Athaydes 
 wrote:
>Yeah, I had already suggested that was probably the best solution
>My previous message had a huge blank space in the middle which I have
>no idea where it came from!!
>But it became a personal challenge to get that old c3p0 jar and quartz
>working in a OSGi environment.
>:)
>Renato
>
>> Date: Mon, 12 Oct 2015 23:23:27 +0200
>> Subject: Re: Help in using your Quartz OSGi bundle
>> From: fr...@frankjlangel.com
>> To: users@felix.apache.org
>> 
>> Have you considered using amdatu-scheduling, a fully wrapped Quartz
>OSGI bundle?
>> 
>> 
>> 
>> On 10/12/15, 11:16 PM, "Neil Bartlett"  wrote:
>> 
>> >The import of the c3p0 package is problematic because c3p0 is not an
>OSGi bundle. However there is a bundle wrapping availabe:
>http://jpm4j.org/#!/p/sha/376EA3C3654A3E0593D1C135A7109ECE77D0BE70//0.0.0
>> >
>> >Incidentally, c3p0 apparently hasn’t been updated or maintained for
>over 8 years, so it’s a bit dubious to be using something like that in
>a production application.
>> >
>> >Neil
>> >
>> >
>> >
>> >> On 12 Oct 2015, at 22:07, Paulo Renato de Athaydes
> wrote:
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> The quartz bundle has the following imports:
>> >> Import-Package:
>com.mchange.v2.c3p0,commonj.work;resolution:=optional,
>javax.ejb;resolution:=optional,javax.jms;resolution:=optional,javax.m
>ail;resolution:=optional,javax.mail.internet;resolution:=optional,jav
>ax.management,javax.management.openmbean,javax.naming,javax.servlet;r
>esolution:=optional,javax.servlet.http;resolution:=optional,javax.sql
>;resolution:=optional,javax.transaction;resolution:=optional,javax.xm
>l.bind,javax.xml.namespace,javax.xml.parsers,javax.xml.xpath,oracle.s
>ql;resolution:=optional,org.jboss.logging;resolution:=optional,org.jb
>oss.naming;resolution:=optional,org.jboss.system;resolution:=optional
>,org.quartz,org.quartz.core,org.quartz.impl.matchers,org.quartz.impl.
>triggers,org.quartz.jobs;resolution:=optional,org.quartz.spi,org.slf4
>j;version="[1.6,2)",org.terracotta.toolkit;resolution:=optional,org.t
>erracotta.toolkit.atomic;resolution:=optional,org.terracotta.toolkit.
>builder;resolution:=optional,org.terracotta.toolkit.cluster;resolutio
>n:=optional,org.terracotta.toolkit.collections;resolution:=optional,o
>rg.terracotta.toolkit.concurrent.locks;resolution:=optional,org.terra
>cotta.toolkit.config;resolution:=optional,org.terracotta.toolkit.inte
>rnal;resolution:=optional,org.terracotta.toolkit.internal.concurrent.
>locks;resolution:=optional,org.terracotta.toolkit.rejoin;resolution:=
>optional,org.terracotta.toolkit.search;resolution:=optional,org.terra
>cotta.toolkit.search.attribute;resolution:=optional,org.terracotta.to
>olkit.store;resolution:=optional,org.w3c.dom,org.xml.sax,weblogic.jdb
>c.jts;resolution:=optional,weblogic.jdbc.vendor.oracle;resolution:=op
>tional
>> >> 
>> >> The required dependencies (not optional) are the following:
>> >> com.mchange.v2.c3p0
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> &g

RE: Help in using your Quartz OSGi bundle

[Paulo Renato de Athaydes]

Yeah, I had already suggested that was probably the best solution My 
previous message had a huge blank space in the middle which I have no idea 
where it came from!!
But it became a personal challenge to get that old c3p0 jar and quartz working 
in a OSGi environment.
:)
Renato

> Date: Mon, 12 Oct 2015 23:23:27 +0200
> Subject: Re: Help in using your Quartz OSGi bundle
> From: fr...@frankjlangel.com
> To: users@felix.apache.org
> 
> Have you considered using amdatu-scheduling, a fully wrapped Quartz OSGI 
> bundle?
> 
> 
> 
> On 10/12/15, 11:16 PM, "Neil Bartlett"  wrote:
> 
> >The import of the c3p0 package is problematic because c3p0 is not an OSGi 
> >bundle. However there is a bundle wrapping availabe: 
> >http://jpm4j.org/#!/p/sha/376EA3C3654A3E0593D1C135A7109ECE77D0BE70//0.0.0
> >
> >Incidentally, c3p0 apparently hasn’t been updated or maintained for over 8 
> >years, so it’s a bit dubious to be using something like that in a production 
> >application.
> >
> >Neil
> >
> >
> >
> >> On 12 Oct 2015, at 22:07, Paulo Renato de Athaydes 
> >>  wrote:
> >> 
> >> 
> >> 
> >> 
> >> 
> >> The quartz bundle has the following imports:
> >> Import-Package: com.mchange.v2.c3p0,commonj.work;resolution:=optional, 
> >> javax.ejb;resolution:=optional,javax.jms;resolution:=optional,javax.m 
> >> ail;resolution:=optional,javax.mail.internet;resolution:=optional,jav 
> >> ax.management,javax.management.openmbean,javax.naming,javax.servlet;r 
> >> esolution:=optional,javax.servlet.http;resolution:=optional,javax.sql 
> >> ;resolution:=optional,javax.transaction;resolution:=optional,javax.xm 
> >> l.bind,javax.xml.namespace,javax.xml.parsers,javax.xml.xpath,oracle.s 
> >> ql;resolution:=optional,org.jboss.logging;resolution:=optional,org.jb 
> >> oss.naming;resolution:=optional,org.jboss.system;resolution:=optional 
> >> ,org.quartz,org.quartz.core,org.quartz.impl.matchers,org.quartz.impl. 
> >> triggers,org.quartz.jobs;resolution:=optional,org.quartz.spi,org.slf4 
> >> j;version="[1.6,2)",org.terracotta.toolkit;resolution:=optional,org.t 
> >> erracotta.toolkit.atomic;resolution:=optional,org.terracotta.toolkit. 
> >> builder;resolution:=optional,org.terracotta.toolkit.cluster;resolutio 
> >> n:=optional,org.terracotta.toolkit.collections;resolution:=optional,o 
> >> rg.terracotta.toolkit.concurrent.locks;resolution:=optional,org.terra 
> >> cotta.toolkit.config;resolution:=optional,org.terracotta.toolkit.inte 
> >> rnal;resolution:=optional,org.terracotta.toolkit.internal.concurrent. 
> >> locks;resolution:=optional,org.terracotta.toolkit.rejoin;resolution:= 
> >> optional,org.terracotta.toolkit.search;resolution:=optional,org.terra 
> >> cotta.toolkit.search.attribute;resolution:=optional,org.terracotta.to 
> >> olkit.store;resolution:=optional,org.w3c.dom,org.xml.sax,weblogic.jdb 
> >> c.jts;resolution:=optional,weblogic.jdbc.vendor.oracle;resolution:=op 
> >> tional
> >> 
> >> The required dependencies (not optional) are the following:
> >> com.mchange.v2.c3p0
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >>

Re: Help in using your Quartz OSGi bundle

[Frank Langel]

c3p0, comes from this artifact:
>> "c3p0:c3p0:0.9.1.1"
>> 
>> Which is not a OSGi bundle. (the others, except quartz which comes from the 
>> jar itself, don't seem to be a problem as the framework seems happy to 
>> provide those).
>> 
>> 
>> I wrapped it in a bundle anyway using osgi-run and then, after installing 
>> them in Felix, I found out we need some logging libraries, org.sfl4j.api, 
>> org.apache.log4j, osg.slf4j.impl (ouch!)
>> 
>> 
>> A little bit painful to get this working.
>> 
>> 
>> After a little guesswork, I found these 2 bundles meet the logging demands:
>> 
>> 
>> osgiRuntime 'org.slf4j:slf4j-simple:1.7.5'
>> osgiRuntime "org.slf4j:log4j-over-slf4j:1.7.5"
>> 
>> 
>> But Felix threw horrible errors when I did this:
>> 
>> 
>> ERROR: Bundle slf4j.api [8] Error starting 
>> file:/Users/renato/programming/projects/osgi-run/osgi-run-test/quartz-sample/build/osgi/bundle/slf4j-api-1.6.6.jar
>>  (java.lang.ArrayIndexOutOfBoundsException: -1)
>> java.lang.ArrayIndexOutOfBoundsException: -1
>>at java.util.ArrayList.elementData(ArrayList.java:418)
>>at java.util.ArrayList.remove(ArrayList.java:495)
>>at 
>> org.apache.felix.framework.resolver.Candidates.prepare(Candidates.java:763)
>>at 
>> org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:122)
>>at 
>> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:405)
>>at 
>> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3973)
>>at org.apache.felix.framework.Felix.startBundle(Felix.java:2043)
>>at 
>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
>>at 
>> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
>>at java.lang.Thread.run(Thread.java:745)
>> ERROR: Bundle slf4j.api [9] Error starting 
>> file:/Users/renato/programming/projects/osgi-run/osgi-run-test/quartz-sample/build/osgi/bundle/slf4j-api-1.7.5.jar
>>  (java.lang.ArrayIndexOutOfBoundsException: -1)
>> java.lang.ArrayIndexOutOfBoundsException: -1
>>at java.util.ArrayList.elementData(ArrayList.java:418)
>>at java.util.ArrayList.remove(ArrayList.java:495)
>>at 
>> org.apache.felix.framework.resolver.Candidates.prepare(Candidates.java:763)
>>at 
>> org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:122)
>>at 
>> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:405)
>>at 
>> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3973)
>>at org.apache.felix.framework.Felix.startBundle(Felix.java:2043)
>>at 
>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
>>at 
>> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
>>at java.lang.Thread.run(Thread.java:745)
>> 
>> Welcome to Apache Felix Gogo
>> 
>> 
>> 
>> Looks like a bug to me (probably fixed now, this is an older Felix 
>> version)...
>> 
>> But I seem to have put two versions of slf4j in the classpath 
>> inadvertently.. anyway, why wouldn't it work? I don't know...
>> So, after some more research, I found that in the docs of c3p0, they say 
>> this:
>> 
>> 
>> Just put the files lib/c3p0-0.9.5.1.jar and 
>> lib/mchange-commons-java-0.2.10.jar in your application's effective CLASSPATH
>> 
>> So I put this mchange-commons-java jar wrapped into an OSGi bundle in the 
>> framework still, didn't work.
>> 
>> 
>> With Equinox I get this now:
>> 
>> 
>> Framework is launched.
>> 
>> 
>> id  State   Bundle
>> 0   ACTIVE  org.eclipse.osgi_3.7.1.R37x_v20110808-1106
>> 1   ACTIVE  c3p0_0.9.1.1
>> 2   ACTIVE  log4j.over.slf4j_1.7.5
>> 3   INSTALLED   mchange-commons-java_0.2.10
>> 4   ACTIVE  slf4j.api_1.7.5
>>Fragments=5
>> 5   RESOLVEDslf4j.simple_1.7.5
>>Master=4
>> 
>> 
>> 
>> But still didn't work. Didn't even tell me what's wrong.
>> 
>> 
>> In Felix, at least I got this error:
>> 
>> 
>> org.osgi.framework.BundleException: Unresolved constraint in bundle 
>> mchange-commons-java [3]: Unable to resolve 3.0: missing requirement [3.0]

RE: Help in using your Quartz OSGi bundle

[Paulo Renato de Athaydes]

Oh... just found out I was actually very close!!
Got Quartz working with this set of bundles (Gogo and quartz-sample, my bundle, 
are not required, of course):
   ID|State  |Level|Name0|Active |0|System Bundle (4.4.0)
1|Active |1|c3p0 (0.9.1.1)2|Active |1|log4j-over-slf4j 
(1.7.5)3|Active |1|Apache Felix Gogo Command (0.14.0)4|Active   
  |1|Apache Felix Gogo Runtime (0.12.1)5|Active |1|Apache Felix 
Gogo Shell (0.10.0)6|Active |1|osgi.core (4.3.1.201210102023)
7|Active |1|quartz (2.2.1)8|Active |1|quartz-sample (1.0.0) 
   9|Active |1|slf4j-api (1.7.5)   10|Resolved   |1|slf4j-simple 
(1.7.5)

Removing mchange-commons-java does not seem to affect anything... the jobs I 
scheduled with Quartz actually ran!
Hope this helps.
Will clean up and publish this on GitHub...
Renato

> From: renatoathay...@hotmail.com
> To: users@felix.apache.org
> Subject: RE: Help in using your Quartz OSGi bundle
> Date: Tue, 13 Oct 2015 08:07:07 +1100
> 
> 
> 
> 
> 
> The quartz bundle has the following imports:
> Import-Package: com.mchange.v2.c3p0,commonj.work;resolution:=optional, 
> javax.ejb;resolution:=optional,javax.jms;resolution:=optional,javax.m 
> ail;resolution:=optional,javax.mail.internet;resolution:=optional,jav 
> ax.management,javax.management.openmbean,javax.naming,javax.servlet;r 
> esolution:=optional,javax.servlet.http;resolution:=optional,javax.sql 
> ;resolution:=optional,javax.transaction;resolution:=optional,javax.xm 
> l.bind,javax.xml.namespace,javax.xml.parsers,javax.xml.xpath,oracle.s 
> ql;resolution:=optional,org.jboss.logging;resolution:=optional,org.jb 
> oss.naming;resolution:=optional,org.jboss.system;resolution:=optional 
> ,org.quartz,org.quartz.core,org.quartz.impl.matchers,org.quartz.impl. 
> triggers,org.quartz.jobs;resolution:=optional,org.quartz.spi,org.slf4 
> j;version="[1.6,2)",org.terracotta.toolkit;resolution:=optional,org.t 
> erracotta.toolkit.atomic;resolution:=optional,org.terracotta.toolkit. 
> builder;resolution:=optional,org.terracotta.toolkit.cluster;resolutio 
> n:=optional,org.terracotta.toolkit.collections;resolution:=optional,o 
> rg.terracotta.toolkit.concurrent.locks;resolution:=optional,org.terra 
> cotta.toolkit.config;resolution:=optional,org.terracotta.toolkit.inte 
> rnal;resolution:=optional,org.terracotta.toolkit.internal.concurrent. 
> locks;resolution:=optional,org.terracotta.toolkit.rejoin;resolution:= 
> optional,org.terracotta.toolkit.search;resolution:=optional,org.terra 
> cotta.toolkit.search.attribute;resolution:=optional,org.terracotta.to 
> olkit.store;resolution:=optional,org.w3c.dom,org.xml.sax,weblogic.jdb 
> c.jts;resolution:=optional,weblogic.jdbc.vendor.oracle;resolution:=op tional
> 
> The required dependencies (not optional) are the following:
> com.mchange.v2.c3p0
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> 
> 
>   
> 
> javax.managementjavax.management.openmbean
> javax.naming
> javax.xml.bind
> javax.xml.namespace
> javax.xml.parsers
> javax.xml.xpath
> org.quartz
> org.quartz.core
> org.quartz.impl.matchers
> org.quartz.impl. triggers
> org.quartz.spi
> org.sl

Re: Help in using your Quartz OSGi bundle

[Neil Bartlett]

ntData(ArrayList.java:418)
>at java.util.ArrayList.remove(ArrayList.java:495)
>at 
> org.apache.felix.framework.resolver.Candidates.prepare(Candidates.java:763)
>at 
> org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:122)
>at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:405)
>at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3973)
>at org.apache.felix.framework.Felix.startBundle(Felix.java:2043)
>at 
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
>at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
>at java.lang.Thread.run(Thread.java:745)
> ERROR: Bundle slf4j.api [9] Error starting 
> file:/Users/renato/programming/projects/osgi-run/osgi-run-test/quartz-sample/build/osgi/bundle/slf4j-api-1.7.5.jar
>  (java.lang.ArrayIndexOutOfBoundsException: -1)
> java.lang.ArrayIndexOutOfBoundsException: -1
>at java.util.ArrayList.elementData(ArrayList.java:418)
>at java.util.ArrayList.remove(ArrayList.java:495)
>at 
> org.apache.felix.framework.resolver.Candidates.prepare(Candidates.java:763)
>at 
> org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:122)
>at 
> org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:405)
>at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3973)
>at org.apache.felix.framework.Felix.startBundle(Felix.java:2043)
>at 
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
>at 
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
>at java.lang.Thread.run(Thread.java:745)
> 
> Welcome to Apache Felix Gogo
> 
> 
> 
> Looks like a bug to me (probably fixed now, this is an older Felix version)...
> 
> But I seem to have put two versions of slf4j in the classpath inadvertently.. 
> anyway, why wouldn't it work? I don't know...
> So, after some more research, I found that in the docs of c3p0, they say this:
> 
> 
> Just put the files lib/c3p0-0.9.5.1.jar and 
> lib/mchange-commons-java-0.2.10.jar in your application's effective CLASSPATH
> 
> So I put this mchange-commons-java jar wrapped into an OSGi bundle in the 
> framework still, didn't work.
> 
> 
> With Equinox I get this now:
> 
> 
> Framework is launched.
> 
> 
> id  State   Bundle
> 0   ACTIVE  org.eclipse.osgi_3.7.1.R37x_v20110808-1106
> 1   ACTIVE  c3p0_0.9.1.1
> 2   ACTIVE  log4j.over.slf4j_1.7.5
> 3   INSTALLED   mchange-commons-java_0.2.10
> 4   ACTIVE  slf4j.api_1.7.5
>Fragments=5
> 5   RESOLVEDslf4j.simple_1.7.5
>Master=4
> 
> 
> 
> But still didn't work. Didn't even tell me what's wrong.
> 
> 
> In Felix, at least I got this error:
> 
> 
> org.osgi.framework.BundleException: Unresolved constraint in bundle 
> mchange-commons-java [3]: Unable to resolve 3.0: missing requirement [3.0] 
> osgi.wiring.package; (osgi.wiring.package=com.typesafe.config)
> 
> So, apparently, we also need some TypeSafe stuff in the classpath :(
> 
> 
> With this, I just give up.
> 
> 
> I recommend you have a look at Atmandu Scheduler instead... It's made for 
> OSGi and apparently uses Quartz:
> 
> 
> http://www.amdatu.org/components/scheduling.html
> 
> 
> Good luck!
> 
> 
> And I can totally understand how you might feel frustrated about this... 
> I thought I would manage to get this working in a few minutes... took me 
> hours trying, and nothing :(
> 
> 
> What can we do?!
> 
> 
> Regards,
> 
> 
> Renato
> 
> 
> 
> 
> 
>> Subject: Re: Help in using your Quartz OSGi bundle
>> To: users@felix.apache.org
>> From: j...@nanthrax.net
>> Date: Mon, 12 Oct 2015 14:32:04 +0200
>> 
>> Hi Pedro,
>> 
>> such dependencies should be optional. Let me check the SMX quartz bundle 
>> around this.
>> 
>> Regards
>> JB
>> 
>> On 10/11/2015 01:20 PM, Pedro Domingues wrote:
>>> Greetings,
>>> 
>>> Sorry for bothering you, but I would like to ask for your help with your
>>> Quartz bundle.
>>> 
>>> I am trying to install your Quartz OSGi bundle into my project:
>>> 
>>> http://i.imgur.com/PKHnWIj.png
>>> 
>>> However when I insert the bundle in my *Apache Felix* I keep g

RE: Help in using your Quartz OSGi bundle

[Paulo Renato de Athaydes]

va.util.ArrayList.remove(ArrayList.java:495)
at 
org.apache.felix.framework.resolver.Candidates.prepare(Candidates.java:763)
at 
org.apache.felix.framework.resolver.ResolverImpl.resolve(ResolverImpl.java:122)
at 
org.apache.felix.framework.StatefulResolver.resolve(StatefulResolver.java:405)
at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3973)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2043)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
at 
org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
at java.lang.Thread.run(Thread.java:745)

Welcome to Apache Felix Gogo



Looks like a bug to me (probably fixed now, this is an older Felix version)...

But I seem to have put two versions of slf4j in the classpath inadvertently.. 
anyway, why wouldn't it work? I don't know...
So, after some more research, I found that in the docs of c3p0, they say this:


Just put the files lib/c3p0-0.9.5.1.jar and lib/mchange-commons-java-0.2.10.jar 
in your application's effective CLASSPATH

So I put this mchange-commons-java jar wrapped into an OSGi bundle in the 
framework still, didn't work.


With Equinox I get this now:


Framework is launched.


id  State   Bundle
0   ACTIVE  org.eclipse.osgi_3.7.1.R37x_v20110808-1106
1   ACTIVE  c3p0_0.9.1.1
2   ACTIVE  log4j.over.slf4j_1.7.5
3   INSTALLED   mchange-commons-java_0.2.10
4   ACTIVE  slf4j.api_1.7.5
Fragments=5
5   RESOLVEDslf4j.simple_1.7.5
Master=4



But still didn't work. Didn't even tell me what's wrong.


In Felix, at least I got this error:


org.osgi.framework.BundleException: Unresolved constraint in bundle 
mchange-commons-java [3]: Unable to resolve 3.0: missing requirement [3.0] 
osgi.wiring.package; (osgi.wiring.package=com.typesafe.config)

So, apparently, we also need some TypeSafe stuff in the classpath :(


With this, I just give up.


I recommend you have a look at Atmandu Scheduler instead... It's made for OSGi 
and apparently uses Quartz:


http://www.amdatu.org/components/scheduling.html


Good luck!


And I can totally understand how you might feel frustrated about this... I 
thought I would manage to get this working in a few minutes... took me hours 
trying, and nothing :(


What can we do?!


Regards,


Renato





> Subject: Re: Help in using your Quartz OSGi bundle
> To: users@felix.apache.org
> From: j...@nanthrax.net
> Date: Mon, 12 Oct 2015 14:32:04 +0200
> 
> Hi Pedro,
> 
> such dependencies should be optional. Let me check the SMX quartz bundle 
> around this.
> 
> Regards
> JB
> 
> On 10/11/2015 01:20 PM, Pedro Domingues wrote:
> > Greetings,
> >
> > Sorry for bothering you, but I would like to ask for your help with your
> > Quartz bundle.
> >
> > I am trying to install your Quartz OSGi bundle into my project:
> >
> > http://i.imgur.com/PKHnWIj.png
> >
> > However when I insert the bundle in my *Apache Felix* I keep getting the
> > unresolved dependencies error message like you can see here:
> >
> >  >java -jar bin/felix.jar
> > ERROR: Bundle hydra.launcher [1] Error starting
> > file:/C:/code/hydra/felix/bundle/hydra.launcher-1.0.0-SNAPSHOT.jar
> > (org.osgi.fram
> > ework.BundleException: Unable to resolve
> > org.apache.servicemix.bundles.quartz [8](R 8.0): missing requirement
> > [org.apache.servicemix.bundles.quartz [8
> > ](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.jboss.logging)
> > Unresolved requirements: [[org.apache.servicemix.bundles.quartz [8](R
> > 8.0)] osg
> > i.wiring.package; (osgi.wiring.package=org.jboss.logging)])
> > org.osgi.framework.BundleException:*Unable to resolve
> > org.apache.servicemix.bundles.quartz [8](R 8.0): missing requirement*
> > [org.apache.servicemix.bund
> > les.quartz [8](R 8.0)] osgi.wiring.package;
> > (osgi.wiring.package=org.jboss.logging) Unresolved requirements:
> > [[*org.apache.servicemix.bundles.quartz* [8
> > ](R 8.0)] osgi.wiring.package; (*osgi.wiring.package=org.jboss.logging*)]
> >  at
> > org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4090)
> >  at org.apache.felix.framework.Felix.startBundle(Felix.java:2111)
> >  at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)
> >  at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964)
> >  at hydra.launcher.Launcher.installStart(Launcher.java:78)
> >
> > If I try to discard this dependency manually in your bundle's manifest I
> > keep getting other dependencies such as oracle.sql and s

Re: Help in using your Quartz OSGi bundle

[Jean-Baptiste Onofré]

Hi Pedro,

such dependencies should be optional. Let me check the SMX quartz bundle 
around this.


Regards
JB

On 10/11/2015 01:20 PM, Pedro Domingues wrote:

Greetings,

Sorry for bothering you, but I would like to ask for your help with your
Quartz bundle.

I am trying to install your Quartz OSGi bundle into my project:

http://i.imgur.com/PKHnWIj.png

However when I insert the bundle in my *Apache Felix* I keep getting the
unresolved dependencies error message like you can see here:

 >java -jar bin/felix.jar
ERROR: Bundle hydra.launcher [1] Error starting
file:/C:/code/hydra/felix/bundle/hydra.launcher-1.0.0-SNAPSHOT.jar
(org.osgi.fram
ework.BundleException: Unable to resolve
org.apache.servicemix.bundles.quartz [8](R 8.0): missing requirement
[org.apache.servicemix.bundles.quartz [8
](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.jboss.logging)
Unresolved requirements: [[org.apache.servicemix.bundles.quartz [8](R
8.0)] osg
i.wiring.package; (osgi.wiring.package=org.jboss.logging)])
org.osgi.framework.BundleException:*Unable to resolve
org.apache.servicemix.bundles.quartz [8](R 8.0): missing requirement*
[org.apache.servicemix.bund
les.quartz [8](R 8.0)] osgi.wiring.package;
(osgi.wiring.package=org.jboss.logging) Unresolved requirements:
[[*org.apache.servicemix.bundles.quartz* [8
](R 8.0)] osgi.wiring.package; (*osgi.wiring.package=org.jboss.logging*)]
 at
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4090)
 at org.apache.felix.framework.Felix.startBundle(Felix.java:2111)
 at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)
 at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964)
 at hydra.launcher.Launcher.installStart(Launcher.java:78)

If I try to discard this dependency manually in your bundle's manifest I
keep getting other dependencies such as oracle.sql and so on... It is a
true dependency hell.

However I do not need to use SQL nor JBOSS, I just want to use Quartz.
Is there any way I can solve this? Do I really need to include the
thousand transitive dependencies manually, which I will probably never
use but since these manifests are automatically generated they include
them anyways?

This is the one thing that makes OSGi hard to use...

Thanks!


--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

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

Re: Help in using your Quartz OSGi bundle

[Pedro Domingues]

On 11/10/2015 18:59, Neil Bartlett wrote:

Such a tool does exist… for example the Embed-Dependency and Embed-Transitive 
instructions in the maven-bundle-plugin. Of course, the price is that every 
bundle will contain its own copy of every library. So if you think this solves 
the problem then I recommend not bothering with OSGi or any other module system.
According to every OSGi book, bundles containing too many unused 
dependencies are probably coarse-grained and should be divided into 
smaller, more concise modules. The thing is that these bundles contain 
the whole library and have tons of different responsibilities, which 
goes against the fine-grained modules principle in modular architecture 
design.






Ultimately there can be no automated substitute for developers paying attention 
to the two principles of modular composition: high cohesion and low coupling. 
When developers fail to do this (as the Quartz developers apparently did), 
users suffer.

Neil


On 11 Oct 2015, at 16:17, Pedro Domingues  wrote:

I understand that everything has dependencies, however I wish this embedding 
could be automated, for example having maven downloading and embedding 
transitive dependencies into the quartz bundle.

Thanks

On 11/10/2015 16:08, e...@zusammenkunft.net  
wrote:

Hello,

Have to agree with Neil, hower I want to add, that the bundling of Quartz here 
is the problem, it could make some dependencies optional and it could even add 
some of the dependencies inside the bundle. This is what I did with Quartz, I 
embedded Quartz and some of its dependencies inside a bundle to greatly remove 
its external dependencies. You can even overwrite/remove some imports for 
unused artifacts. Quartz needs this special treatment since its a big ugly blob 
of goo.

Greetings
Bernd





-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 

For additional commands, e-mail: users-h...@felix.apache.org 




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

Re: Help in using your Quartz OSGi bundle

[Neil Bartlett]

Such a tool does exist… for example the Embed-Dependency and Embed-Transitive 
instructions in the maven-bundle-plugin. Of course, the price is that every 
bundle will contain its own copy of every library. So if you think this solves 
the problem then I recommend not bothering with OSGi or any other module system.

Ultimately there can be no automated substitute for developers paying attention 
to the two principles of modular composition: high cohesion and low coupling. 
When developers fail to do this (as the Quartz developers apparently did), 
users suffer.

Neil

> On 11 Oct 2015, at 16:17, Pedro Domingues  wrote:
> 
> I understand that everything has dependencies, however I wish this embedding 
> could be automated, for example having maven downloading and embedding 
> transitive dependencies into the quartz bundle.
> 
> Thanks
> 
> On 11/10/2015 16:08, e...@zusammenkunft.net  
> wrote:
>> Hello,
>> 
>> Have to agree with Neil, hower I want to add, that the bundling of Quartz 
>> here is the problem, it could make some dependencies optional and it could 
>> even add some of the dependencies inside the bundle. This is what I did with 
>> Quartz, I embedded Quartz and some of its dependencies inside a bundle to 
>> greatly remove its external dependencies. You can even overwrite/remove some 
>> imports for unused artifacts. Quartz needs this special treatment since its 
>> a big ugly blob of goo.
>> 
>> Greetings
>> Bernd
>> 
>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org 
> 
> For additional commands, e-mail: users-h...@felix.apache.org 
> 

Re: Help in using your Quartz OSGi bundle

[ecki]

The bundle-plugin of felix can do that to some extend, I use it to embed the 
dependencies. They are automatically downloaded via maven. However especually 
when your artifact has so many uneeded dependencies it is better to decide case 
by case how you want to resolve them.

Gruss
Bernd

-- 
http://bernd.eckenfels.net

-Original Message-
From: Pedro Domingues 
To: users@felix.apache.org
Sent: So., 11 Okt. 2015 17:17
Subject: Re: Help in using your Quartz OSGi bundle

I understand that everything has dependencies, however I wish this 
embedding could be automated, for example having maven downloading and 
embedding transitive dependencies into the quartz bundle.

Thanks

On 11/10/2015 16:08, e...@zusammenkunft.net wrote:
> Hello,
>
> Have to agree with Neil, hower I want to add, that the bundling of Quartz 
> here is the problem, it could make some dependencies optional and it could 
> even add some of the dependencies inside the bundle. This is what I did with 
> Quartz, I embedded Quartz and some of its dependencies inside a bundle to 
> greatly remove its external dependencies. You can even overwrite/remove some 
> imports for unused artifacts. Quartz needs this special treatment since its a 
> big ugly blob of goo.
>
> Greetings
> Bernd
>
>
>


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


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

Re: Help in using your Quartz OSGi bundle

[Achim Nierbeck]

Hi,

as you're using a servicemix rebundled version of Quarz, either check if
there is already a never version available
which already does address your issue. Or file an issue at the servicemix
project which addresses your issue to have
certain bundle marked as optional import.

regards, Achim



2015-10-11 17:08 GMT+02:00 :

> Hello,
>
> Have to agree with Neil, hower I want to add, that the bundling of Quartz
> here is the problem, it could make some dependencies optional and it could
> even add some of the dependencies inside the bundle. This is what I did
> with Quartz, I embedded Quartz and some of its dependencies inside a bundle
> to greatly remove its external dependencies. You can even overwrite/remove
> some imports for unused artifacts. Quartz needs this special treatment
> since its a big ugly blob of goo.
>
> Greetings
> Bernd
>
>
>
> --
> http://bernd.eckenfels.net
>
> -Original Message-
> From: Neil Bartlett 
> To: users@felix.apache.org
> Cc: jbono...@apache.org, "d...@felix.apache.org" ,
> users-h...@felix.apache.org
> Sent: So., 11 Okt. 2015 16:46
> Subject: Re: Help in using your Quartz OSGi bundle
>
>
>
> > On 11 Oct 2015, at 12:20, Pedro Domingues 
> wrote:
> >
> > Greetings,
> >
> > Sorry for bothering you, but I would like to ask for your help with your
> Quartz bundle.
> >
> > I am trying to install your Quartz OSGi bundle into my project:
> >
> >
> >
> > However when I insert the bundle in my Apache Felix I keep getting the
> unresolved dependencies error message like you can see here:
> >
> > >java -jar bin/felix.jar
> > ERROR: Bundle hydra.launcher [1] Error starting
> file:/C:/code/hydra/felix/bundle/hydra.launcher-1.0.0-SNAPSHOT.jar
> (org.osgi.fram
> > ework.BundleException: Unable to resolve
> org.apache.servicemix.bundles.quartz [8](R 8.0): missing requirement
> [org.apache.servicemix.bundles.quartz [8
> > ](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.jboss.logging)
> Unresolved requirements: [[org.apache.servicemix.bundles.quartz [8](R 8.0)]
> osg
> > i.wiring.package; (osgi.wiring.package=org.jboss.logging)])
> > org.osgi.framework.BundleException: Unable to resolve
> org.apache.servicemix.bundles.quartz [8](R 8.0): missing requirement
> [org.apache.servicemix.bund
> > les.quartz [8](R 8.0)] osgi.wiring.package;
> (osgi.wiring.package=org.jboss.logging) Unresolved requirements:
> [[org.apache.servicemix.bundles.quartz [8
> > ](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.jboss.logging)]
> > at
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4090)
> > at org.apache.felix.framework.Felix.startBundle(Felix.java:2111)
> > at
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)
> > at
> org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964)
> > at hydra.launcher.Launcher.installStart(Launcher.java:78)
> >
> > If I try to discard this dependency manually in your bundle's manifest I
> keep getting other dependencies such as oracle.sql and so on... It is a
> true dependency hell.
> >
> > However I do not need to use SQL nor JBOSS, I just want to use Quartz.
> Is there any way I can solve this? Do I really need to include the thousand
> transitive dependencies manually, which I will probably never use but since
> these manifests are automatically generated they include them anyways?
> >
> > This is the one thing that makes OSGi hard to use...
>
> Thats not exactly fair. OSGi didn't create those dependencies -- they
> exist in the code.
>
> Unfortunately, if a bundle has a large tree of dependencies then you have
> only two choices. Either use it and suck up the dependencies. Or just don't
> use it.
>
> OSGi is not unique here. In all software development, you have to decide
> whether to import a module and pay the price of its dependencies, find a
> better module, or write your own.
>
> Neil
>
> >
> > Thanks!
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: Help in using your Quartz OSGi bundle

[Pedro Domingues]

I understand that everything has dependencies, however I wish this 
embedding could be automated, for example having maven downloading and 
embedding transitive dependencies into the quartz bundle.


Thanks

On 11/10/2015 16:08, e...@zusammenkunft.net wrote:

Hello,

Have to agree with Neil, hower I want to add, that the bundling of Quartz here 
is the problem, it could make some dependencies optional and it could even add 
some of the dependencies inside the bundle. This is what I did with Quartz, I 
embedded Quartz and some of its dependencies inside a bundle to greatly remove 
its external dependencies. You can even overwrite/remove some imports for 
unused artifacts. Quartz needs this special treatment since its a big ugly blob 
of goo.

Greetings
Bernd






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

Re: Help in using your Quartz OSGi bundle

[ecki]

Hello,

Have to agree with Neil, hower I want to add, that the bundling of Quartz here 
is the problem, it could make some dependencies optional and it could even add 
some of the dependencies inside the bundle. This is what I did with Quartz, I 
embedded Quartz and some of its dependencies inside a bundle to greatly remove 
its external dependencies. You can even overwrite/remove some imports for 
unused artifacts. Quartz needs this special treatment since its a big ugly blob 
of goo. 

Greetings
Bernd



-- 
http://bernd.eckenfels.net

-Original Message-
From: Neil Bartlett 
To: users@felix.apache.org
Cc: jbono...@apache.org, "d...@felix.apache.org" , 
users-h...@felix.apache.org
Sent: So., 11 Okt. 2015 16:46
Subject: Re: Help in using your Quartz OSGi bundle



> On 11 Oct 2015, at 12:20, Pedro Domingues  wrote:
> 
> Greetings,
> 
> Sorry for bothering you, but I would like to ask for your help with your 
> Quartz bundle.
> 
> I am trying to install your Quartz OSGi bundle into my project:
> 
> 
> 
> However when I insert the bundle in my Apache Felix I keep getting the 
> unresolved dependencies error message like you can see here:
> 
> >java -jar bin/felix.jar
> ERROR: Bundle hydra.launcher [1] Error starting 
> file:/C:/code/hydra/felix/bundle/hydra.launcher-1.0.0-SNAPSHOT.jar 
> (org.osgi.fram
> ework.BundleException: Unable to resolve org.apache.servicemix.bundles.quartz 
> [8](R 8.0): missing requirement [org.apache.servicemix.bundles.quartz [8
> ](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.jboss.logging) 
> Unresolved requirements: [[org.apache.servicemix.bundles.quartz [8](R 8.0)] 
> osg
> i.wiring.package; (osgi.wiring.package=org.jboss.logging)])
> org.osgi.framework.BundleException: Unable to resolve 
> org.apache.servicemix.bundles.quartz [8](R 8.0): missing requirement 
> [org.apache.servicemix.bund
> les.quartz [8](R 8.0)] osgi.wiring.package; 
> (osgi.wiring.package=org.jboss.logging) Unresolved requirements: 
> [[org.apache.servicemix.bundles.quartz [8
> ](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.jboss.logging)]
> at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4090)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2111)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964)
> at hydra.launcher.Launcher.installStart(Launcher.java:78)
> 
> If I try to discard this dependency manually in your bundle's manifest I keep 
> getting other dependencies such as oracle.sql and so on... It is a true 
> dependency hell. 
> 
> However I do not need to use SQL nor JBOSS, I just want to use Quartz. Is 
> there any way I can solve this? Do I really need to include the thousand 
> transitive dependencies manually, which I will probably never use but since 
> these manifests are automatically generated they include them anyways?
> 
> This is the one thing that makes OSGi hard to use...

Thats not exactly fair. OSGi didn't create those dependencies -- they exist in 
the code.

Unfortunately, if a bundle has a large tree of dependencies then you have only 
two choices. Either use it and suck up the dependencies. Or just don't use it.

OSGi is not unique here. In all software development, you have to decide 
whether to import a module and pay the price of its dependencies, find a better 
module, or write your own.

Neil

> 
> Thanks!

Re: Help in using your Quartz OSGi bundle

[Neil Bartlett]

> On 11 Oct 2015, at 12:20, Pedro Domingues  wrote:
> 
> Greetings,
> 
> Sorry for bothering you, but I would like to ask for your help with your 
> Quartz bundle.
> 
> I am trying to install your Quartz OSGi bundle into my project:
> 
> 
> 
> However when I insert the bundle in my Apache Felix I keep getting the 
> unresolved dependencies error message like you can see here:
> 
> >java -jar bin/felix.jar
> ERROR: Bundle hydra.launcher [1] Error starting 
> file:/C:/code/hydra/felix/bundle/hydra.launcher-1.0.0-SNAPSHOT.jar 
> (org.osgi.fram
> ework.BundleException: Unable to resolve org.apache.servicemix.bundles.quartz 
> [8](R 8.0): missing requirement [org.apache.servicemix.bundles.quartz [8
> ](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.jboss.logging) 
> Unresolved requirements: [[org.apache.servicemix.bundles.quartz [8](R 8.0)] 
> osg
> i.wiring.package; (osgi.wiring.package=org.jboss.logging)])
> org.osgi.framework.BundleException: Unable to resolve 
> org.apache.servicemix.bundles.quartz [8](R 8.0): missing requirement 
> [org.apache.servicemix.bund
> les.quartz [8](R 8.0)] osgi.wiring.package; 
> (osgi.wiring.package=org.jboss.logging) Unresolved requirements: 
> [[org.apache.servicemix.bundles.quartz [8
> ](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.jboss.logging)]
> at 
> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4090)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2111)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964)
> at hydra.launcher.Launcher.installStart(Launcher.java:78)
> 
> If I try to discard this dependency manually in your bundle's manifest I keep 
> getting other dependencies such as oracle.sql and so on... It is a true 
> dependency hell. 
> 
> However I do not need to use SQL nor JBOSS, I just want to use Quartz. Is 
> there any way I can solve this? Do I really need to include the thousand 
> transitive dependencies manually, which I will probably never use but since 
> these manifests are automatically generated they include them anyways?
> 
> This is the one thing that makes OSGi hard to use...

Thats not exactly fair. OSGi didn't create those dependencies -- they exist in 
the code.

Unfortunately, if a bundle has a large tree of dependencies then you have only 
two choices. Either use it and suck up the dependencies. Or just don't use it.

OSGi is not unique here. In all software development, you have to decide 
whether to import a module and pay the price of its dependencies, find a better 
module, or write your own.

Neil

> 
> Thanks!

Help in using your Quartz OSGi bundle

[Pedro Domingues]

Greetings,

Sorry for bothering you, but I would like to ask for your help with your 
Quartz bundle.


I am trying to install your Quartz OSGi bundle into my project:

http://i.imgur.com/PKHnWIj.png

However when I insert the bundle in my *Apache Felix* I keep getting the 
unresolved dependencies error message like you can see here:


>java -jar bin/felix.jar
ERROR: Bundle hydra.launcher [1] Error starting 
file:/C:/code/hydra/felix/bundle/hydra.launcher-1.0.0-SNAPSHOT.jar 
(org.osgi.fram
ework.BundleException: Unable to resolve 
org.apache.servicemix.bundles.quartz [8](R 8.0): missing requirement 
[org.apache.servicemix.bundles.quartz [8
](R 8.0)] osgi.wiring.package; (osgi.wiring.package=org.jboss.logging) 
Unresolved requirements: [[org.apache.servicemix.bundles.quartz [8](R 
8.0)] osg

i.wiring.package; (osgi.wiring.package=org.jboss.logging)])
org.osgi.framework.BundleException:*Unable to resolve 
org.apache.servicemix.bundles.quartz [8](R 8.0): missing requirement* 
[org.apache.servicemix.bund
les.quartz [8](R 8.0)] osgi.wiring.package; 
(osgi.wiring.package=org.jboss.logging) Unresolved requirements: 
[[*org.apache.servicemix.bundles.quartz* [8

](R 8.0)] osgi.wiring.package; (*osgi.wiring.package=org.jboss.logging*)]
at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4090)

at org.apache.felix.framework.Felix.startBundle(Felix.java:2111)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:977)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:964)
at hydra.launcher.Launcher.installStart(Launcher.java:78)

If I try to discard this dependency manually in your bundle's manifest I 
keep getting other dependencies such as oracle.sql and so on... It is a 
true dependency hell.


However I do not need to use SQL nor JBOSS, I just want to use Quartz. 
Is there any way I can solve this? Do I really need to include the 
thousand transitive dependencies manually, which I will probably never 
use but since these manifests are automatically generated they include 
them anyways?


This is the one thing that makes OSGi hard to use...

Thanks!