> On 19 Oct 2015, at 14:22, Pedro Domingues <pedro.doming...@ist.utl.pt> wrote: > > Guys, so far no luck... Both original quartz library bundle and amdatu bundle > import the following dependencies as mandatory: > > (Amdatu) > > *Import-Package:* com.mchange.v2.c3p0;resolution:=optional, > javax.ejb;resolution:=optional, > javax.mail;resolution:=optional, > javax.mail.internet;resolution:=optional, > javax.jms;resolution:=optional, > javax.rmi;resolution:=optional, > javax.naming;resolution:=optional, > *javax.management,** > **javax.management.openmbean,** > **javax.servlet,** > **javax.servlet.http,** > **javax.sql,** > **javax.transaction,** > **javax.xml.bind,** > **javax.xml.namespace,** > **javax.xml.parsers,** > **javax.xml.xpath,* > org.amdatu.scheduling.annotations;version="[1.0,2)", > org.amdatu.scheduling.annotations.timeinterval;version="[1.0,2)", > org.apache.felix.dm;version="[4.0,5)", > org.osgi.framework;version="[1.6,2)", > org.osgi.service.log;version="[1.3,2)", > *org.w3c.dom,** > **org.xml.sax* > > (Quartz terracotta) > > *Import-Package:* *com.mchange.v2.c3p0,* > commonj.work;resolution:=optional, > javax.ejb;resolution:=optional, > javax.jms;resolution:=optional, > javax.mail;resolution:=optional, > javax.mail.internet;resolution:=optional, > *javax.management,** > **javax.management.openmbean,** > **javax.naming,* > javax.servlet;resolution:=optional, > javax.servlet.http;resolution:=optional, > javax.sql;resolution:=optional, > javax.transaction;resolution:=optional, > *javax.xml.bind,** > **javax.xml.namespace,** > **javax.xml.parsers,** > **javax.xml.xpath,* > oracle.sql;resolution:=optional, > org.jboss.logging;resolution:=optional, > org.jboss.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.slf4j;version="[1.6,2)",* > org.terracotta.toolkit;resolution:=optional, > org.terracotta.toolkit.atomic;resolution:=optional, > org.terracotta.toolkit.builder;resolution:=optional, > org.terracotta.toolkit.cluster;resolution:=optional, > org.terracotta.toolkit.collections;resolution:=optional, > org.terracotta.toolkit.concurrent.locks;resolution:=optional, > org.terracotta.toolkit.config;resolution:=optional, > org.terracotta.toolkit.internal;resolution:=optional, > org.terracotta.toolkit.internal.concurrent.locks;resolution:=optional, > org.terracotta.toolkit.rejoin;resolution:=optional, > org.terracotta.toolkit.search;resolution:=optional, > org.terracotta.toolkit.search.attribute;resolution:=optional, > org.terracotta.toolkit.store;resolution:=optional, > *org.w3c.dom,** > **org.xml.sax,* > weblogic.jdbc.jts;resolution:=optional, > weblogic.jdbc.vendor.oracle;resolution:=optional > > Why would I need javax.sql, javax.servlet, w3c, etc... to make cron jobs?
I don’t understand why you are asking this question on the Felix mailing list. Ask the authors of Quartz why they chose to depend on those things. > > This bundles is coarse-grained, this is against the desired design of > bundles, which should be fine-grained, having very concise responsibilities > and as a consequence, only the required imports for those responsibilities > (these books cover this very well http://www.kirkk.com/modularity/chapters/ > and http://shop.oreilly.com/product/0636920033158.do). So arguments like > "this is the OSGi way, get used to it" are invalid since every OSGi and > modular programming book states that *this is a very bad practice*. I agree. But how else is one to proceed when taking a legacy, third-party library that was clearly NOT designed with any kind of modularity in mind, and turn it into a module? Modularity is not some magic fairy dust that you can sprinkle on the top. Have the people who packed up Quartz as a bundle done a bad job? I don’t think so. Remember there are penalties for declaring imports optional: every optional import is an opportunity for a class loading error such as NoClassDefFoundError, i.e. the kinds of errors that OSGi is meant to protect you from! Furthermore, who aside from the user of Quartz (that is, you!) can decide that an import should be optional? Only you know whether you are going to use Quartz with servlets, or Quartz with EJB, or whatever else. > > 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!). > > 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 >> <renatoathay...@hotmail.com> 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" <njbartl...@gmail.com> 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 >>> <renatoathay...@hotmail.com> 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, 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 RESOLVED slf4j.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 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 >>>>>>> >>>>>> >>>>> >>>> --------------------------------------------------------------------- >>>>> 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 >>>> >>> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
