Good morning, I am back!... ;-) I am trying out Neil's large bundle option as an interim solution. I am using the
<Embed-Dependency>*;scope=compile|runtime</Embed-Dependency> Instruction. When I deploy my fat bundle, it falls over with a transitive dependency used in one of the embedded jars not being found (log4j, of all classes). To fix that, I decided to try and add the instruction <Embed-Transitive>true</Embed-Transitive> However maven does not seem to like this as it fails to complete its job with error: Class in different directory than declared. Path from class name is com/sun/codemodel/CodeWriter.class but the path in the jar is 1.0/com/sun/codemodel/CodeWriter.class from Jar:jaxb-xjc-2.1.10.jar Which I thought was fixed a while back. Any idea anyone? TIA, B. -----Original Message----- From: Neil Bartlett [mailto:njbartl...@gmail.com] Sent: 17 October 2011 14:26 To: users@felix.apache.org Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies Hi Barbara, I feel ambivalent about it ;-) It's clearly not ideal, but as part of a migration it's acceptable. Same with embedding dependencies… both result in a fatter system than required. Rgds, Neil On Monday, 17 October 2011 at 14:21, Barbara Rosi-Schwartz wrote: > Neil, > > what I was trying to do, was not to treat the company jars as "third party" > ones. Since I have access to the projects and their pom files, I was trying > to get at least the jars my project depends on to be more or less proper OSGi > bundles, at the same time hiding all of their internal dependencies my > project does not care about. > > Having said that, I can see that this implies potentially several copies of > the same libraries, which is not ideal. How do you feel about using a large > "3rd party" bundle when what one wants to achieve is modularity and > download/use of only those bundles and libs that are needed for a given user > invoked task? Still better than having several copies of the same libs? > > Thanks, > B. > > -----Original Message----- > From: Neil Bartlett [mailto:njbartl...@gmail.com] > Sent: 17 October 2011 14:11 > To: users@felix.apache.org (mailto:users@felix.apache.org) > Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of > OSGi and non OSGi dependencies > > I appreciate that OSGifying a large set of legacy JARs is a significant task. > > One approach you can use as a stepping stone is to create a single, large > "3rd party" bundle. This would contain basically all of the libraries you > require, referenced via Bundle-Classpath, and export the packages that you > need from your own bundles. > > The advantage of this versus embedding is that you only have one copy of each > library, and also that your main bundles are in pretty much the state you > want them to be in, using Import-Package etc. You can then gradually dissolve > the 3rd party bundle by removing a single library from its Bundle-Classpath > and OSGifying it in isolation, without needing to refactor your own bundles. > > Regards > Neil > > > > On Monday, 17 October 2011 at 13:44, Barbara Rosi-Schwartz wrote: > > > Thanks Neil. > > > > I did try what you suggest, but I got so many bees in my bonnet... :-( I > > was on the path of OSGi-fying the whole organisation here, a lot more than > > I had anticipated... eventually I gave that up in frustration. > > > > -----Original Message----- > > From: Neil Bartlett [mailto:njbartl...@gmail.com] > > Sent: 17 October 2011 12:11 > > To: users@felix.apache.org (mailto:users@felix.apache.org) > > Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of > > OSGi and non OSGi dependencies > > > > Barbara, > > > > Why not OSGi-fy those third party dependencies and save the results in a > > repository? You only have to do this once (per dependency) and it avoids > > all the issues with embedding libraries. > > > > Rgds > > Neil > > > > > > > > On Monday, 17 October 2011 at 11:51, Pierre Henry Perret wrote: > > > > > Hi Rosi, > > > > > > It recalls me some similar case I had in a project... > > > > > > I would had the *baz *dependance in the *parent *management > > > section so that it is inherited from all *modules.* > > > * > > > * > > > *WDYT ? > > > * > > > -- > > > Pierre-Henry Perret > > > mob2: +33 (0)6 69 52 18 48 > > > > > > > > > > > > > > > 2011/10/17 Barbara Rosi-Schwartz > > > <barbara.rosi-schwa...@iggroup.com > > > (mailto:barbara.rosi-schwa...@iggroup.com) > > > (mailto:barbara.rosi-schwa...@iggroup.com) > > > (mailto:barbara.rosi-schwa...@iggroup.com)> > > > > > > > Hello. > > > > > > > > I am using the Maven Bundle plug-in to OSGi-ify dependencies > > > > that we have on another team's jars. These jars in turn have > > > > their own dependencies, some of which I have already OSGi-ified, > > > > whereas others are third parties ones which I would just like to embed > > > > in the generated bundles. > > > > > > > > Let's assume that the jar I want to OSGi-ify is artefact foo-bar > > > > and that it contains a bunch of third party dependencies + a > > > > dependency on artefact foo-baz, which I have already OSGi-ified. > > > > > > > > To this aim I configure my Maven Bundle plug-in as follows: > > > > > > > > <configuration> > > > > <instructions> > > > > <Export-Package>com.foo.bar.*</Export-Package> > > > > <Bundle-Version>${parent.version}</Bundle-Version> > > > > <Import-Package>com.foo.baz.client</Import-Package> > > > > <Embed-Dependency>!foo-baz,*;scope=compile|runtime</Embed-Depend > > > > en > > > > cy > > > > </instructions> > > > > </configuration> > > > > > > > > The generated com.foo.bar's MANIFEST.MF does contain the > > > > expected Import-Package clause, but it also contains foo-baz.jar > > > > in the Bundle-ClassPath clause, which is not what I want. I have > > > > tried several permutation of the <Embed-Dependency> specification, but > > > > to no avail. > > > > > > > > How do I correctly specify the instructions to achieve my goal? > > > > > > > > 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 (http://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. > > > > > > 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.
