> Or perhaps they were necessary to satisfy the javac compiler but they were not necessary or even sufficient to actually run the code.
Not necessary: true because you may specify more than needed if you're not careful. Not sufficient? Wrong. That's what compilers are for. You need to have all your classes available to the compiler or it will not compile at all, saving you from a runtime Exception (unlike you play with dynamic features like reflection, of course, then there's no salvation). >I think your mistake is confusing build-time dependencies for runtime >dependencies.There's no silver bullet. If your code uses reflection or >something (so many libraries do it's not funny) then bnd will not make >miracles and magically do it for you. There's a need for maintaining dependencies by hand in any case. If you haven't been burned by that, I suppose you've been extremely lucky. Just don't tell me it's ok to assume bnd will do everything for you because it's not. > Java developers REALLY need to break this habit of thinking that compile time and runtime dependencies are the same! They are not. You compile against APIs and run with implementations. Go use Python then if you think so little of compiling. I want to know that if my code compiles, it will just run, despite all its little logical bugs, but at least have no ClassNotFound or other CrapTypeSystemWiringException. OSGi developers REALLY need to break this habit of thinking that compiling time doesn't matter, just wait for runtime to tell you that you just breached modularity once again... gotta love BundleWiringExceptions. Deployment files like Karaf features should have been a feature since the start of OSGi so that this kind of error could be caught at compiling time. It's a huge mistake to wait for runtime to see what happens. Regards, Renato > Date: Fri, 24 Oct 2014 23:53:44 +0100 > From: njbartl...@gmail.com > To: users@felix.apache.org; renatoathay...@hotmail.com > Subject: RE: managing OSGi Dependencies > > No, I’m not. > > Bnd performs a full inspection of the dependencies of the classes included in > the bundle, and generated imports for the referenced packages (or, in the > case of Conditional-Package, adds those packages to the bundle). Whereas the > libraries specified in the POM are just the ones that some human thought > might be necessary. Or perhaps they were necessary to satisfy the javac > compiler but they were not necessary or even sufficient to actually run the > code. > > Humans are lazy, bnd is smart and thorough. I trust bnd to do what it does > more than any human, including myself. > > Java developers REALLY need to break this habit of thinking that compile time > and runtime dependencies are the same! They are not. You compile against APIs > and run with implementations. > > > Neil > > > From: Paulo Renato de Athaydes <renatoathay...@hotmail.com> > Reply: users@felix.apache.org <users@felix.apache.org>> > Date: 24 October 2014 at 23:39:05 > To: users@felix.apache.org <users@felix.apache.org>> > Subject: RE: managing OSGi Dependencies > > You're playing with fire. > > Not providing all the dependencies at runtime that a library requires at > compiling time is recipe for ClassDefNotFoundException which has plagued OSGi > devs since the beginning of time. > > > Subject: Re: managing OSGi Dependencies > > From: pedro.doming...@ist.utl.pt > > Date: Fri, 24 Oct 2014 23:14:41 +0100 > > To: users@felix.apache.org; njbartl...@gmail.com > > > > Could you share your example project so that I could get a closer look? > > > > Thanks! > > > > On October 24, 2014 5:25:36 PM WEST, Neil Bartlett <njbartl...@gmail.com> > > wrote: > > >Further to this… I just created a Bndtools project to build a bundle > > >containing your sample “SuchInterface” interface, plus the entire > > >contents of the jscience.jar version 4.3.1 pulled from Maven Central. > > >The only imported package was org.xml.sax, which as I said is provided > > >by JavaSE. So there is no problem at all with this library. This job > > >took about 2 minutes and it resolves just fine in Felix. > > > > > >I think your mistake is confusing build-time dependencies for runtime > > >dependencies. This is why I recommend never to use Embed-Dependency: > > >Maven only knows about build-time dependencies are they are MUCH more > > >extensive than the runtime dependencies. > > > > > >Regards, > > >Neil > > > > > > > > >From: Neil Bartlett <njbartl...@gmail.com> > > >Reply: Neil Bartlett <njbartl...@gmail.com>> > > >Date: 24 October 2014 at 17:04:41 > > >To: users@felix.apache.org <users@felix.apache.org>>, PedroD > > ><pedro.doming...@ist.utl.pt>> > > >Subject: Re: managing OSGi Dependencies > > > > > >The Conditional-Package instruction is documented > > >here: http://bnd.bndtools.org/chapters/800-headers.html. There is no > > >need to restrict yourself to reading only the maven-bundle-plugin > > >documentation. All instruction and headers supported by bnd are > > >supported by the Maven plugin, because the plugin passes them through. > > > > > >Also see my blog post about Conditional Package > > >use: http://njbartlett.name/2014/05/26/static-linking.html > > > > > >I strongly recommend against using Embed-Dependency, and even more so > > >Embed-Transitive! This is rather like using a nuclear ICBM to take > > >potshots at a paper target. > > > > > >Regarding the Joda and SAX imports, Bndtools can tell you where these > > >come from. Though if you use Conditional-Package, hopefully they won’t > > >arise, unless you actually use them of course. The SAX import is not a > > >problem because org.xml.sax is provided by JavaSE. Joda Convert is > > >available as an OSGi bundle > > >already: > > >http://jpm4j.org/#!/p/sha/57C2432E54DC40F871F55295C676B22672713602//0.0.0 > > > > > >Regards > > >Neil > > > > > > > > >From: PedroD <pedro.doming...@ist.utl.pt> > > >Reply: users@felix.apache.org <users@felix.apache.org>> > > >Date: 24 October 2014 at 16:36:43 > > >To: users@felix.apache.org <users@felix.apache.org>> > > >Subject: Re: managing OSGi Dependencies > > > > > > > > >Thanks > > > > > > > > >On 24 Oct 2014, at 15:52, Neil Bartlett <njbartl...@gmail.com> wrote: > > > > > >Hello Pedro, > > > > > >To help you I’d first like to understand your current approach a bit > > >better. You say you download these non-bundle dependencies and put them > > >in the “bundle” directory until you get no more dependency errors. What > > >effect does that have? Since they are not bundles, how does adding them > > >to a directory help? > > > > > >As Christian points out, the problem is really with these libraries. > > >Remember that Maven is also famous for downloading when you ask for the > > >slightest thing. The reason for this is poor internal coherency which > > >results in _fan out_. To explain: > > > > > >1. You depend on package org.foo which is part of the JAR file foolib. > > >2. foolib contains 20 other packages *that you are not using* > > >3. those 20 useless packages depend on five more JARs > > >4. GOTO 1. > > > > > >Turning these JARs into bundles doesn’t help because they still have > > >all those dependencies which all have to be resolved in order for OSGi > > >to be happy. > > > > > >A better solution is to pull in only the packages that you really need. > > >For example if you use the Conditional-Package instruction in bnd (also > > >available as Conditional_Package in the maven-bundle-plugin) then you > > >can create a bundle that includes only the packages that are referenced > > >by your core code. This doesn’t always help because sometimes people > > >have poor coherency even within their packages — general util packages > > >are a common problem, just look at the dependencies from java.util for > > >example — but it still easier to deal with than big messy JAR files. > > > > > >I hope that helps. > > > > > >Regards, > > >Neil > > > > > > > > >From: PedroD <pedro.doming...@ist.utl.pt> > > >Reply: users@felix.apache.org <users@felix.apache.org>> > > >Date: 24 October 2014 at 15:03:41 > > >To: users@felix.apache.org <users@felix.apache.org>> > > >Subject: managing OSGi Dependencies > > > > > >Greetings, > > > > > >I’m using Felix Framework for my OSGi project, but I’ve came across a > > >severe problem concerning third party dependencies. > > > > > >I’m using eclipse and maven-bundle-plugin to generate my bundles from > > >the sources and the MANIFEST.MF from the POM.XML file. So far so good. > > >however when I have some third party dependency in my bundle, I find > > >myself looking for an infinite list of JARs, which usually are not > > >bundles, and putting them in my /bundle Felix directory until no more > > >dependencies are missing. > > > > > >I call this process “Downloading the Internet for my OSGi application > > >to work”. > > > > > >What am I doing wrong? Sure I must be doing something very wrong, > > >because I can’t imagine anyone having a bundle A that depends on B, > > >which then depends on C and D, and then those two will depend on > > >several others and so on… > > > > > >What is the correct way to automate this? I would love to have one of > > >the two solutions: > > > > > >1) Be able to create a massive JAR file with all of its dependencies > > >embedded, but exporting only the packages I want, and, of corse, not > > >importing any package. > > > > > >2) (My preferred solution) Having a way to get all my dependencies into > > >individual JAR files that I can simply paste into the /bundle > > >directory. > > > > > >I have found tools that do me this, but they only do it for direct (1st > > >degree) dependencies, leaving transitive dependencies for me to solve > > >manually. > > > > > >This problem is critical. The lack of such a tool hampers the usage of > > >OSGi. I’ve searched and searched and searched, I’ve came across all the > > >101 solutions such as PAX, bndtools, and friends, but they do not solve > > >this issue… > > > > > >Please help me. > > > > > >Thanks! > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > >For additional commands, e-mail: users-h...@felix.apache.org > > > > -- > > Sent from my Android device with K-9 Mail. Please excuse my brevity.
