Was the jscience-4.3.1.jar file compiled by you? Regards, Pedro Domingues
On 26 Oct 2014, at 17:01, Neil Bartlett <[email protected]> wrote: > Sorry I don't know anything about this error. > > The example I gave you didn't really have anything to do with gradle; that is > just the default for bndtools projects. If you really want to use the maven > plugin then I recommend taking the instructions from the bnd.bnd and using > them in your pom.xml. > > Regards > Neil > > -- > Neil Bartlett > Sent from a phone > > > On Sunday, 26 October 2014 at 08:43, Pedro Domingues wrote: > >> Hello again Neil! >> >> I was trying to learn from your example in gradle, which I've never used >> before, to try to map your configurations in maven (maven-bundle-plugin). >> However when I import the project to eclipse as a gradle project and hit >> the Build Model button, eclipse crashes without any mercy. >> >> screenshot: http://i.imgur.com/XwZXFeY.png >> >> Is this a simple (noob) error because I'm missing something very basic >> and probably should go read more about gradle, or is something wierd >> going on here? >> >> Thanks! >> >> Regards, >> Pedro >> >> On 24/10/2014 23:46, Neil Bartlett wrote: >>> Sure, here you go: https://github.com/njbartlett/jscience.example >>> >>> The only change to your code was to move it out of the default package. >>> >>> Regards, >>> Neil >>> >>> >>> From: Pedro Domingues <[email protected]> >>> <mailto:[email protected]> >>> Reply: Pedro Domingues <[email protected]>> >>> <mailto:[email protected]> >>> Date: 24 October 2014 at 23:14:48 >>> To: [email protected] <[email protected]>> >>> <mailto:[email protected]>, Neil Bartlett <[email protected]>> >>> <mailto:[email protected]> >>> Subject: Re: managing OSGi Dependencies >>> >>>> 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 >>>> <[email protected]> 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 <[email protected]> >>>> Reply: Neil Bartlett <[email protected]>> >>>> Date: 24 October 2014 at 17:04:41 >>>> To: [email protected] <[email protected]>>, PedroD >>>> <[email protected]>> >>>> 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 th >>>> ey >>>> 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<http://jpm4j.org/#%21/p/sha/57C2432E54DC40F871F55295C676B22672713602//0.0.0> >>>> >>>> Regards >>>> Neil >>>> >>>> >>>> From: PedroD <[email protected]> >>>> Reply: [email protected] <[email protected]>> >>>> Date: 24 October 2014 at 16:36:43 >>>> To: [email protected] <[email protected]>> >>>> Subject: Re: managing OSGi Dependencies >>>> >>>> >>>> Thanks >>>> >>>> >>>> On 24 Oct 2014, at 15:52, Neil Bartlett <[email protected]> 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” director >>>> y 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-plu >>>> gin) >>>> 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 <[email protected]> >>>> Reply: [email protected] <[email protected]>> >>>> Date: 24 October 2014 at 15:03:41 >>>> To: [email protected] <[email protected]>> >>>> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >>>> >>>> -- >>>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
