Thanks Ben. I will sure give a look :-) On Wed, Oct 19, 2011 at 4:19 PM, <[email protected]> wrote:
> Hi Dileepa, > > I am a little off-topic regarding your question about removing unsued jars, > but about converting third party jars to OSGi, the eclipse orbit project > already provides a number of OSGified jar files here: > http://download.eclipse.org/tools/orbit/downloads/ > and the latest release: > http://download.eclipse.org/tools/orbit/downloads/drops/R20110523182458/ > > Maybe it is worth having a look there. > > Kind regards, > Ben > > Le mer 19/10/11 12:28, Dileepa Jayakody [email protected] a écrit: > > Hi, > > > > I'm also working on something in-line to what's discussed here, so I > > would > > like to share my experience thinking it might be relevant to the > > topic > > discussed here. > > > > My project uses 3rd party jars wrapped as osgi bundles since the > > project is > > on top of an OSGI runtime. I'm trying to reduce the size of some of > > the > > bundles which wrap 3rd party dependency jars as osgi bundles. (eg: > > apacheds, > > axis2 etc) > > The project uses maven bundle-plugin to make the bundles. > > > > The general issue I'm facing is: how to remove unused jars(3rd party) > > from > > the section of the bulky bundles. > > As a work-around, I use to a tool called JBoss Tattletale [1] (A cool > > tool > > to understand the project's classpath details as it gives > > comprehensive > > reports on certain topics.) to get an overview of the project > > class-path > > with regard to unused jars, duplicated jars, same jar with different > > versions, missing classes etc, and then with that information I'm > > able to > > identify unused jars (with no transitive dependency) in the bundle > > and > > remove them from the bundle classpath. > > Here I assume that these unused jars which were previously embedded > > as > > dependencies are no longer required when installing the bundle and > > running > > the system in the OSGI run-time. > > I was able to successfully install the bundles without any OSGI START > > time > > exceptions. > > > > However I have a doubt if there could be any run-time exceptional > > cases. Can > > anyone give me some advice or point-out cases where it could throw > > errors? > > > > Such case I can think of is Java reflection where it tries to load a > > particular class dynamically from a jar removed from embedded > > dependencies. > > (I'm not 100% sure if tattletale tracks reflection dependencies when > > reporting on unused jars) > > > > [1] http://www.jboss.org/tattletale [1] > > > > Thanks, > > Dileepa > > > > On Wed, Oct 19, 2011 at 1:45 PM, Barbara Rosi-Schwartz > [email protected]> wrote: > > > > > Good morning, I am back!... ;-) > > > > > > I am trying out Neil's large bundle option as an interim solution. > > I am > > > using the > > > > > > *;scope=compile|runtime > > > > > > 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 > > > > > > true > > > > > > 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 [[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 [[email protected]] > > > > Sent: 17 October 2011 14:11 > > > > To: [email protected] ([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 [[email protected]] > > > > > Sent: 17 October 2011 12:11 > > > > > To: [email protected] ([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 > > > > > > > > > > (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: > > > > > > > > > > > > > > > > > > > > > > > > > > > > com.foo.bar.* > > > > > > > ${parent.version} > > > > > > > com.foo.baz.client > > > > > > > > > !foo-baz,*;scope=compile|runtime > > > > > en > > > > > > > cy > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > 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. > > > > > > > > > > > > > > Links: > > ------ > > [1] > > > http://mail.gandi.net/parse.php?redirect=http%3A%2F%2Fwww.jboss.org%2Ftattl > > etale[2] > > > http://mail.gandi.net/parse.php?redirect=http%3A%2F%2Fwww.iggroup.com%29%0D > > %3C%2Ffont > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Dileepa Jayakody, Software Engineer, WSO2 Inc. Lean . Enterprise . Middleware
