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. > > > > > > > > > >
