Hi Barbara, Sorry I forgot about our earlier discussion.
I hate to recommend a big-bang solution. The problem can be tackled incrementally, but perhaps the better approach is to come from the bottom of the tree rather than from the top. In other words, first identify those libraries in your "big blob" that do not have any dependencies, and remove them into their own bundles. Find equivalents for those libraries in the SpringSource bundle repository if necessary. Once that first pass is done, identify the libraries that depend only on libraries that you have already bundle-ized, and remove them into their own bundles. Rinse and repeat.... Regards Neil On Wed, Nov 30, 2011 at 11:43 AM, Barbara Rosi-Schwartz <[email protected]> wrote: > Hi Neil, thanks for the detailed message. > > I have already gone the route of the large single bundle containing all the > dependencies, as you recommended a while back. Since I have a little time > available, I was trying to retrace my steps and see if I could more sensibly > OSGi-ify the third party bundles separately, to end up with a more > OSGi-kosher setup. I was trying to walk a fine line between proper OSGi > dependencies and embedded libraries, but this appears to land me in more > trouble than it is worth. I guess the only real solution is to bite the > bullet and completely dispense with ALL embedding. Is that what you are > ultimately suggesting? > > Thanks, > B. > > -----Original Message----- > From: Neil Bartlett [mailto:[email protected]] > Sent: 30 November 2011 11:34 > To: [email protected] > Subject: Re: Embed-Dependency problem with Maven Bundle plugin > > Hi Barbara, > > I believe what you're seeing is correct behaviour.... you're unfortunately > now paying the price of embedding. > > Embedding a dependency doesn't get you out of jail for free. When you embed a > library, you now inherit all of its dependencies. If you embed all those > libraries as well, then you inherit an even bigger set of dependencies! > Unless you can find a way to cut through this, you end up building a huge > bundle with a Bundle-Classpath that looks very much like the classpath you > had before you started using OSGi... > > Ultimately the only real solution is to depend on fewer third party > libraries, especially ones that drag in a huge tree of transitive > dependencies. Sadly this is the point where many people get pissed off with > OSGi, but they're only shooting the messenger. > > Sorry for the pessimistic tone. An acceptable interim position for many > people is to create a single large bundle containing all of their third-party > library dependencies; at least they can then apply OSGi modularity to their > own application code. > > Regards, > Neil > > On Wed, Nov 30, 2011 at 11:19 AM, Barbara Rosi-Schwartz > <[email protected]> wrote: >> Thanks Stuart, very clear explanation. >> >> The problem I am facing now is that, in the generated manifest, the >> Import-Package clause contains packages that are not immediately required by >> the classes in the bundle to be. Why is that? The main issue is that these >> Import-Package elements end up dragging in all sorts of transitive >> dependencies and I am finding myself pulling on a very long string... >> >> Do I need to configure the Import-Package clause as well? >> >> TIA, >> B. >> >> -----Original Message----- >> From: Stuart McCulloch [mailto:[email protected]] >> Sent: 29 November 2011 12:35 >> To: [email protected] >> Subject: Re: Embed-Dependency problem with Maven Bundle plugin >> >> On 29 Nov 2011, at 12:09, Barbara Rosi-Schwartz wrote: >> >>> Hello. >>> >>> I am using Maven Bundle plugin version 2.3.5 and I am having a >>> problem with it. If I use the >>> >>> <Embed-Dependency>*;scope=compile|runtime;inline=false</Embed-Depende >>> n >>> cy> >>> >>> clause, all dependencies are embedded, as expected. If I instead specify >>> the ones I want embedded as: >>> >>> <Embed-Dependency>uk.co.igindex.singlesignon.client,uk.co.igindex.spr >>> i >>> ngrest.client,uk.co.igindex.springrest.domain;scope=compile|runtime;i >>> n >>> line=false</Embed-Dependency> >> >> The Embed-Dependency grammar is defined here: >> >> >> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html >> #ApacheFelixMavenBundlePlugin%28BND%29-Embeddingdependencies >> >> Clauses are separated by commas and if you don't specify an attribute >> (ie. attr=value) then it defaults to the artifactId >> >> Therefore: >> >> >> <Embed-Dependency>uk.co.igindex.singlesignon.client,uk.co.igindex.spri >> ngrest.client,uk.co.igindex.springrest.domain;scope=compile|runtime;in >> line=false</Embed-Dependency> >> >> is parsed as: >> >> ( artifactId=uk.co.igindex.singlesignon.client ) >> OR ( artifactId=uk.co.igindex.springrest.client ) >> OR ( artifactId=uk.co.igindex.springrest.domain AND ( scope=compile >> OR scope=runtime ) AND don't inline ) >> >> If you want to list alternative values for a given attribute use the >> pipe symbol | as follows >> >> >> <Embed-Dependency>uk.co.igindex.singlesignon.client|uk.co.igindex.spri >> ngrest.client|uk.co.igindex.springrest.domain;scope=compile|runtime;in >> line=false</Embed-Dependency> >> >> Finally is "uk.co.igindex.singlesignon.client" the concatenated groupId + >> artifact? If so then you could use something like: >> >> >> <Embed-Dependency>artifactId=client|domain;groupId=uk.co.igindex.*;sco >> pe=compile|runtime;inline=false</Embed-Dependency> >> >> to select dependencies with groupIds that start with >> "uk.co.igindex..." and that have "client" or "domain" artifactIds >> >> HTH >> >>> I get the following warning: >>> >>> [WARNING] Embed-Dependency: clause "uk.co.igindex.singlesignon.client" >>> did not match any dependencies [WARNING] Embed-Dependency: clause >>> "uk.co.igindex.springrest.client" did not match any dependencies >>> [WARNING] Embed-Dependency: clause >>> "uk.co.igindex.springrest.domain;scope=compile|runtime;inline=false" >>> did not match any dependencies >>> >>> and no dependencies are actually embedded. What am I doing wrong? >>> >>> TIA, >>> B. >>> >>> BARBARA ROSI-SCHWARTZ >>> Senior Developer >>> >>> IG Group|Cannon Bridge House >>> 25 Dowgate Hill|London|EC4R ZYA >>> >>> t: +44(0)20 7573 0208 (Direct) >>> t: +44(0)20 7896 0011 (Switchboard) >>> w: www.iggroup.com >>> >>> >>> ________________________________ >>> The information contained in this email is strictly confidential and for >>> the use of the addressee only, unless otherwise indicated. If you are not >>> the intended recipient, please do not read, copy, use or disclose to others >>> this message or any attachment. Please also notify the sender by replying >>> to this email or by telephone (+44 (0)20 7896 0011) and then delete the >>> email and any copies of it. Opinions, conclusions (etc) that do not relate >>> to the official business of this company shall be understood as neither >>> given nor endorsed by it. IG Group Holdings plc is a company registered in >>> England and Wales under number 01190902. VAT registration number 761 2978 >>> 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, London EC4R >>> 2YA. Authorised and regulated by the Financial Services Authority. FSA >>> Register number 114059. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
