Thanks Stuart. Turns out I do not need to embed all transitive dependencies, which is a relief as I was concerned about my bundle blowing up out of all proportions.
I just managed without the transitive dependencies by a slow and careful balance of <dependency> elements in the pom and <Import-Package> / <Export-Package> clauses in the plug-in instructions. I must confess I do not really understand the configuration of the maven bundle plug-in, I have just accomplished this by trial and error. I would really love to start using the plug-in like a pro, any suggestion, Stuart, on what to read etc. (apart from the user guide)? Are you perhaps going to be at either the JAX London conference in a couple of weeks? I'd love to take a little of your time and ask you a few questions about it all. Thanks, B. -----Original Message----- From: Stuart McCulloch [mailto:[email protected]] Sent: 19 October 2011 13:35 To: [email protected] Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies On 19 Oct 2011, at 09:15, Barbara Rosi-Schwartz wrote: > 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? Seems to be a packaging problem in the original jaxb-xjc-2.1.10 artifact ... the 2.1.10.1 version doesn't contain these spurious "1.0..." entries Try upgrading to: <dependency> <groupId>org.jvnet.jaxb2_commons</groupId> <artifactId>jaxb-xjc</artifactId> <version>2.1.10.1</version> </dependency> (assuming you're talking about this particular jaxb-xjc artifact) > TIA, > B. > > -----Original Message----- > From: Neil Bartlett [mailto:[email protected]] > Sent: 17 October 2011 14:26 > To: [email protected] > 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:[email protected]] >> Sent: 17 October 2011 14:11 >> To: [email protected] (mailto:[email protected]) >> 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:[email protected]] >>> Sent: 17 October 2011 12:11 >>> To: [email protected] (mailto:[email protected]) >>> 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 >>>> <[email protected] >>>> (mailto:[email protected]) >>>> (mailto:[email protected]) >>>> (mailto:[email protected])> >>>> >>>>> 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. > --------------------------------------------------------------------- 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]
