Have not read everything but from the OP it looks like your're missing a couple of exports in your OSGi runtime. Embedding these dependencies (with Embed-Transitive) in your bundle does not affect the Import-Package/Export-Package (as far as I know) so you need to change your pom to no longer Import these packages. You're stating in the pom that you want maven-bundle-plugin to import everything (*). This means you will have a manifest file that has import statements for your embedded packages too most likely. (Just check your built manifest.mf)
To resolve this, make your import-package tag like this: <Import-Package>!com.caucho.burlap.client, !com.caucho.burlap.io, !com.caucho.burlap.server, com.test.taxonomy.message.*;version=1.0.0, *</Import-Package> and of course new "!embedded.package.that.fail.to.resolve" for each failing package until your bundle starts. This says that you want to import everything except the packages listed with a ! in front. (And as I remember, the order is important. You can't remove an imported package with ! so make sure to list the non-wanted packages before listing the wanted packages. That is, * should be appearing last in the tag.) Hope this helps and that I understood your problem correctly. :) Per-Erik Svensson On Wed, Jun 15, 2011 at 12:56 AM, Justin Edelson <[email protected]>wrote: > I don't understand why you're dealing with embedded at all in this > case. com.projectB is being imported from another bundle, so what are > you embedding? > > Maybe post your whole pom on gist or pastebin. > > If your bundle is importing packages from commons-lang, then those > packages must be exported by some other bundle. Not clear that's the > case here. > > Justin > > On Sat, Jun 11, 2011 at 2:41 PM, Shamik Bandopadhyay <[email protected]> > wrote: > > Justin, again thanks for your inputs. > > > > Extending your example of Project A, B and C, but I'm not keen on > > knowing the transitive dependencies of B, which might be using 2.0 > > version of C. A also has a dependency on commons-lang 2.5. I've > > constructed the following plugin bundle entry. > > > > <configuration> > > <instructions> > > <Export-Package>com.projectA.*;version=1.0.0, > > </Export-Package> > > <Import-Package>com.projectB.*;version=1.0.0, > > * > > </Import-Package> > > <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName> > > <Bundle-Version>${pom.version}</Bundle-Version> > > > > <Embed-Dependency>*;scope=compile|runtime;artifactId=!commons-lang|projectC</Embed-Dependency> > > </instructions> > > </configuration> > > > > I'm deliberately skipping the gathering of transitive dependency > > information by using * in import package. I'm expecting plugin will > > include projectC as part of the import package. Also,I'm instructing > > maven to embed all dependencies it can observe during compile and > > runtime, but exclude commons-lang and projectC since I'll be relying > > on OSGi version in Felix. > > > > Once I create the bundle and install in felix, it throws an error > > complaining about commons-lang 2.5 version. My understanding is felix > > might be running a different version of commons-lang than 2.5. Same > > can be applicable for projectC as well. So what are my options in this > > case? Should I make embed-transitive true and let projectC 2.0 and > > commons-lang 2.5be embedded inside the bundle or install the versions > > in felix and then install the bundle ? > > > > On Fri, Jun 10, 2011 at 8:24 PM, Justin Edelson > > <[email protected]> wrote: > >> On Fri, Jun 10, 2011 at 6:34 PM, Shamik Bandopadhyay <[email protected]> > wrote: > >>> Justin, > >>> > >>> Thanks for your insight. It is indeed helpful to get the concept and > >>> suggestion from people who have dealt with it on their own. It > >>> apparently makes sense to use OSGI bundles in a framework meant for > >>> that, but in an open-source java world, it'll never be easy to have a > >>> corresponding OSGi bundles for a standard jar. So,I guess, there'll be > >>> a need for embedding libraries at times. > >> > >> I'll quibble with one thing here if you're using Open Source Java > >> libraries which aren't available with proper OSGi headers in their > >> standard distribution, it's *very easy* to fix this - just submit a > >> patch to the project. Although there are some which won't be > >> interested, I think you'll find that most would be receptive. And for > >> those that aren't interested in applying your patch, just deploy a > >> locally patched version to your local Maven repository manager. > >> Compare this with commercial dependencies where you have little to no > >> agency. > >> > >>> > >>> The issue I see with maven-bundle-plugin is the ease to adopt. Though > >>> it looks fairly simple at the first glance, it does require some kind > >>> of guessing. Atleast, that's what I feel based on my experience, as > >>> well from Sam's feedback so far. > >>> > >>> <<2) don't use transitive embeds - list all dependencies to be > >>> embedded with a scope of compile and use the scope selector to pick > >>> all compile scope dependencies>> > >>> I've couple of questions based on your inputs. You've suggested not to > >>> use Embed-Transitive, rather, list all dependencies with a scope > >>> compile. When you say all dependencies, I guess, you meant it by the > >>> depenedencies defined in the pom. How about the transitive > >>> dependencies ? How they'll be resolved ? > >> > >> Not sure I understand the question, but I'll take a stab at it and say > >> that this is part of the magic of bnd :) > >> > >> Let's say you have ProjectA which depends upon ProjectB which depends > >> upon ProjectC. ProjectC is already available as an OSGi bundle. > >> Project B is not and you decide to embed ProjectB into ProjectA. When > >> bnd does its analysis, it reads bytecode from ProjectA and ProjectB > >> and determines that one of ProjectC's packages is used. As such, > >> com.myco.projectc (or whatever) is added to the import list. > >> > >>> > >>> <<4) finally, iteratively tweak the auto-generated imports>> > >>> You mean altering the imports in generated manifest file ? > >> > >> No. I mean in the configuration of the maven-bundle-plugin. My point > >> here is that bnd's default behavior against the full class space > >> (including embedded JARs) should be the baseline. Once you see what > >> bnd does by default, *then* start modifying the pom.xml to deviate > >> from the default. > >> > >> HTH, > >> > >> Justin > >> > >>> > >>> On Fri, Jun 10, 2011 at 2:22 PM, Justin Edelson > >>> <[email protected]> wrote: > >>>> I would highly recommend not using resolution=optional with * > >>>> > >>>> It would be very atypical for *all* imports to truly be optional. When > you use optional imports blindly like this you will inevitably end up with > the wrong class space at some point. > >>>> > >>>> What I generally advise people is this: > >>>> 1) deal with embedding first. > >>>> 2) don't use transitive embeds - list all dependencies to be embedded > with a scope of compile and use the scope selector to pick all compile scope > dependencies > >>>> 3) once embedding is configured, configure the exports (if any) by > explicitly listing the packages and versions > >>>> 4) finally, iteratively tweak the auto-generated imports > >>>> > >>>> Shamik - I'd suggest you file bug report with a reproduceable test > case. > >>>> > >>>> Justin > >>>> > >>>> On Jun 10, 2011, at 5:08 PM, sam lee <[email protected]> wrote: > >>>> > >>>>> freemarker and gwt are just examples.. > >>>>> > >>>>> > >>>>> Let's say I have a maven module that depends on: > >>>>> > >>>>> <dependency> > >>>>> <groupId>mysql</groupId> > >>>>> <artifactId>mysql-connector-java</artifactId> > >>>>> <version>5.1.9</version> > >>>>> </dependency> > >>>>> > >>>>> > >>>>> To make the dependency work in the osgi bundle, I had to: > >>>>> <Import-Package> > >>>>> *;resolution:=optional > >>>>> </Import-Package> > >>>>> <Embed-Dependency> > >>>>> mysql-connector-java;scope=compile|runtime > >>>>> </Embed-Dependency> > >>>>> > >>>>> > >>>>> I tried various combinations of maven-bundle-plugin.. but I only > found the > >>>>> above working. > >>>>> > >>>>> > >>>>> My intuition is: > >>>>> > >>>>> 1. List <dependency>s that are not provided (<scope> isn't provided). > >>>>> 2. List them under Embed-Dependency. > >>>>> 3. Import-Package *;resolution:=optional > >>>>> 4. If things don't work, add > <Embed-Transitive>true</Embed-Transitive> > >>>>> > >>>>> > >>>>> Or, like you mentioned, you can decipher > >>>>> > http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html > >>>>> and look at the source code for maven-bundle-plugin. > >>>>> > >>>>> It's pretty simple. It's Java. (sarcasm). > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Jun 10, 2011 at 3:47 PM, Shamik Bandopadhyay < > [email protected]>wrote: > >>>>> > >>>>>> Sam, I just tried and it worked great. Just for my understanding, > can > >>>>>> you please explain how do decide to include freemarker and gwt and > not > >>>>>> the remaining package reference? > >>>>>> > >>>>>> On Fri, Jun 10, 2011 at 12:25 PM, sam lee <[email protected]> > wrote: > >>>>>>> Try it and see. Does it work? > >>>>>>> > >>>>>>> I wouldn't try to reason Java complexity, OSGi. > >>>>>>> > >>>>>>> On Fri, Jun 10, 2011 at 3:20 PM, <[email protected]> wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Shamik, > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I completely understand how you feel about making bundles out of > >>>>>>>> non-bundled .jar files. The standard answer is to contact the > vendor and > >>>>>>>> have them make bundles for you. However, this can take a while to > >>>>>> accomplish > >>>>>>>> and sometimes, especially for open-source .jar's, it may be > difficult to > >>>>>>>> get in touch with the folks who made the original .jar file. In > >>>>>> addition to > >>>>>>>> that method, there are a couple of quick and easy ways to make a > osgi > >>>>>> bundle > >>>>>>>> out of a non-osgi .jar file. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> First, you may want to consider using Karaf. This product can > ride of > >>>>>> top > >>>>>>>> of felix (or equinox), and it has a number of helper functions > that will > >>>>>>>> make your job easier. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Second, when you install a non-bundled .jar file into Felix, try > using > >>>>>> the > >>>>>>>> following syntax: > >>>>>>>> > >>>>>>>> osgi:install wrap:mvn:<artifactId>/<groupId>/version > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> I haven't tried this in Felix, but in Karaf over the top of Felix, > this > >>>>>>>> will automagically wrap your non-osgi bundle. "Wrapping" in the > process > >>>>>> of > >>>>>>>> using a tool to add osgi-stuff into a non-osgi .jar file's > MANIFEST.MF > >>>>>>>> file. While this may not be the best approach for an operational > >>>>>>>> environment, this will definately help you get your test stuff > working. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> To make a more operational-ready bundle, you can use the bnd tool > to > >>>>>> wrap > >>>>>>>> your existing bundle. Bnd is a very powerful tool and is pretty > well > >>>>>>>> documented. Google it for more information. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Please let me know if this helps! > >>>>>>>> > >>>>>>>> > >>>>>>>> ----- Original Message ----- > >>>>>>>> From: "Shamik Bandopadhyay" <[email protected]> > >>>>>>>> To: [email protected] > >>>>>>>> Sent: Friday, June 10, 2011 2:52:09 PM > >>>>>>>> Subject: Re: Felix maven-bundle-plugin transitive dependency issue > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> Thanks for your reply. Being a newbie, I'm finding a li'l hard to > >>>>>>>> grasp the concept maybe. I agree, that embedding transitive > dependency > >>>>>>>> might not be the greatest idea since it contradicts OSGI > fundamental. > >>>>>>>> But at the sametime what bothers me is how do we address the > non-osgi > >>>>>>>> jars ? I can "n" number of jars in my project which maybe have > other > >>>>>>>> transitive dependencies. I don't see how efficient is the process > of > >>>>>>>> manually identifing them and make them OSGi enabled. I found the > >>>>>>>> transitive dependency support comes handy in these cases. > >>>>>>>> > >>>>>>>> Unfortunately, I'm still not able to figure out how the > >>>>>>>> <Embed-Transitive> property works for the maven-plugin-bundle. > >>>>>>>> After,trying all possible combinations(so far), I haven't seen a > >>>>>>>> single instance where a transitive jar got embedded in the bundle. > >>>>>>>> > >>>>>>>> I perhaps, need to do more reading to understand this. > >>>>>>>> > >>>>>>>> Can you pls share any pointers for best practises in this regard? > >>>>>>>> > >>>>>>>> Appreciate your help... > >>>>>>>> > >>>>>>>> -Thanks > >>>>>>>> > >>>>>>>> On Fri, Jun 10, 2011 at 11:41 AM, <[email protected]> > wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Shamik, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Embedding the transitive dependencies is one of those things that > you > >>>>>> can > >>>>>>>> do in OSGi, but usually you shouldn't. The problem is that your > bundle > >>>>>> is > >>>>>>>> likely not going to use most of the transitive dependencies. So, > >>>>>> embedding > >>>>>>>> them into your bundle can leave you with a much larger bundle than > you > >>>>>>>> really need with a bunch of "stuff" you don't need. Another > problem > >>>>>> that > >>>>>>>> you'll see when embedding transitive dependencies is that you may > run > >>>>>> into a > >>>>>>>> circumstance where a transitive dependency (especially for older > stuff) > >>>>>>>> isn't available any more. In this case, your build will break. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> A better approach is to identify those bundles that you are > actually > >>>>>>>> going to use (which you've already done), and deploy those into > OSGi > >>>>>> before > >>>>>>>> you deploy your taxonomy dao bundle. A rule of thumb that I use > is, if > >>>>>> a > >>>>>>>> bundle is listed in the dependencies section of the pom, that > bundle > >>>>>> should > >>>>>>>> be available within OSGi. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> So, in short, try not embedding any dependencies in your bundle; > >>>>>> instead, > >>>>>>>> deploying all of the necessary bundles into OSGi first. If that > doesn't > >>>>>>>> work, only then should you try to embed. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Please let me know if that helps! > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ----- Original Message ----- > >>>>>>>>> From: "Shamik Bandopadhyay" <[email protected]> > >>>>>>>>> To: [email protected] > >>>>>>>>> Sent: Friday, June 10, 2011 1:56:54 PM > >>>>>>>>> Subject: Felix maven-bundle-plugin transitive dependency issue > >>>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I'm new to OSGI and trying to deploy my first application. I've a > >>>>>>>>> spring dependency in my pom. While deploying I realized that > Felix > >>>>>>>>> runtime requires all transitive dependencies to install the > bundle > >>>>>>>>> properly. Since then, I'm sort of struggling to resolve this > issue. > >>>>>>>>> I've tried embedded-dependency and embedded-transitive options, > but of > >>>>>>>>> no luck. Here's my pom. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> <project xmlns="http://maven.apache.org/POM/4.0.0"; > >>>>>>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > >>>>>>>>> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > >>>>>>>>> http://maven.apache.org/xsd/maven-4.0.0.xsd";> > >>>>>>>>> <modelVersion>4.0.0</modelVersion> > >>>>>>>>> <groupId>com.test</groupId> > >>>>>>>>> <artifactId>taxonomydaobundle</artifactId> > >>>>>>>>> <version>1.0.0</version> > >>>>>>>>> <packaging>bundle</packaging> > >>>>>>>>> <name>Taxonomy Dao Bundle</name> > >>>>>>>>> <url>http://maven.apache.org</url> > >>>>>>>>> <repositories> > >>>>>>>>> <repository> > >>>>>>>>> <id>fusesource</id> > >>>>>>>>> <url>http://repo.fusesource.com/maven2</url> > >>>>>>>>> <snapshots> > >>>>>>>>> <enabled>false</enabled> > >>>>>>>>> </snapshots> > >>>>>>>>> <releases> > >>>>>>>>> <enabled>true</enabled> > >>>>>>>>> </releases> > >>>>>>>>> </repository> > >>>>>>>>> <repository> > >>>>>>>>> <id>apache-public</id> > >>>>>>>>> <url> > https://repository.apache.org/content/groups/public/ > >>>>>>>> </url> > >>>>>>>>> <snapshots> > >>>>>>>>> <enabled>true</enabled> > >>>>>>>>> </snapshots> > >>>>>>>>> <releases> > >>>>>>>>> <enabled>true</enabled> > >>>>>>>>> </releases> > >>>>>>>>> </repository> > >>>>>>>>> </repositories> > >>>>>>>>> > >>>>>>>>> <properties> > >>>>>>>>> > >>>>>>>> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> > >>>>>>>>> </properties> > >>>>>>>>> > >>>>>>>>> <dependencies> > >>>>>>>>> <dependency> > >>>>>>>>> <groupId>com.test</groupId> > >>>>>>>>> <artifactId>taxonomymodelbundle</artifactId> > >>>>>>>>> <version>1.0.0</version> > >>>>>>>>> <scope>compile</scope> > >>>>>>>>> </dependency> > >>>>>>>>> <dependency> > >>>>>>>>> <groupId>org.springframework</groupId> > >>>>>>>>> <artifactId>spring</artifactId> > >>>>>>>>> <version>2.5.5</version> > >>>>>>>>> </dependency> > >>>>>>>>> <dependency> > >>>>>>>>> <groupId>junit</groupId> > >>>>>>>>> <artifactId>junit</artifactId> > >>>>>>>>> <version>3.8.1</version> > >>>>>>>>> <scope>test</scope> > >>>>>>>>> </dependency> > >>>>>>>>> </dependencies> > >>>>>>>>> > >>>>>>>>> <build> > >>>>>>>>> <plugins> > >>>>>>>>> <plugin> > >>>>>>>>> <groupId>org.apache.felix</groupId> > >>>>>>>>> <artifactId>maven-bundle-plugin</artifactId> > >>>>>>>>> <version>2.0.1</version> > >>>>>>>>> <extensions>true</extensions> > >>>>>>>>> <configuration> > >>>>>>>>> <instructions> > >>>>>>>>> > >>>>>>>> <Export-Package>com.test.taxonomy.api.*;version=1.0.0 > >>>>>>>>> </Export-Package> > >>>>>>>>> > >>>>>>>>> <Import-Package>com.test.taxonomy.message.*;version=1.0.0, > >>>>>>>>> * > >>>>>>>>> </Import-Package> > >>>>>>>>> > >>>>>>>>> <Embed-Dependency>*;scope=compile|runtime</Embed-Dependency> > >>>>>>>>> <Embed-Transitive>true</Embed-Transitive> > >>>>>>>>> </instructions> > >>>>>>>>> </configuration> > >>>>>>>>> </plugin> > >>>>>>>>> <plugin> > >>>>>>>>> <groupId>org.apache.maven.plugins</groupId> > >>>>>>>>> <artifactId>maven-compiler-plugin</artifactId> > >>>>>>>>> <version>2.1</version> > >>>>>>>>> <configuration> > >>>>>>>>> <source>1.6</source> > >>>>>>>>> <target>1.6</target> > >>>>>>>>> </configuration> > >>>>>>>>> </plugin> > >>>>>>>>> </plugins> > >>>>>>>>> </build> > >>>>>>>>> </project> > >>>>>>>>> > >>>>>>>>> mvn install only embeds the direct dependency jars in the bundle. > >>>>>>>>> When I try to install the bundle in Felix, its throwing import > errors > >>>>>>>>> as it's failing to resolve the dependencies. Here's a snippet : > >>>>>>>>> > >>>>>>>>> Imported Packages ERROR: bsh -- Cannot be resolved > >>>>>>>>> ERROR: com.caucho.burlap.client -- Cannot be resolved > >>>>>>>>> ERROR: com.caucho.burlap.io -- Cannot be resolved > >>>>>>>>> ERROR: com.caucho.burlap.server -- Cannot be resolved > >>>>>>>>> ERROR: com.caucho.hessian.client -- Cannot be resolved > >>>>>>>>> ERROR: com.caucho.hessian.io -- Cannot be resolved > >>>>>>>>> ERROR: com.caucho.hessian.server -- Cannot be resolved > >>>>>>>>> ERROR: com.ibatis.common.util -- Cannot be resolved > >>>>>>>>> ERROR: com.ibatis.common.xml -- Cannot be resolved > >>>>>>>>> ERROR: com.ibatis.sqlmap.client -- Cannot be resolved > >>>>>>>>> ERROR: com.ibatis.sqlmap.client.event -- Cannot be resolved > >>>>>>>>> ERROR: com.ibatis.sqlmap.engine.builder.xml -- Cannot be resolved > >>>>>>>>> ERROR: com.ibatis.sqlmap.engine.impl -- Cannot be resolved > >>>>>>>>> ERROR: com.ibatis.sqlmap.engine.transaction -- Cannot be resolved > >>>>>>>>> ERROR: com.ibatis.sqlmap.engine.transaction.external -- Cannot be > >>>>>>>> resolved > >>>>>>>>> ERROR: com.ibatis.sqlmap.engine.type -- Cannot be resolved > >>>>>>>>> ERROR: com.ibm.wsspi.uow -- Cannot be resolved > >>>>>>>>> ERROR: com.jamonapi -- Cannot be resolved > >>>>>>>>> ERROR: com.mchange.v2.c3p0 -- Cannot be resolved > >>>>>>>>> ERROR: com.sun.enterprise.loader -- Cannot be resolved and > overwritten > >>>>>>>>> by Boot Delegation > >>>>>>>>> ERROR: com.sun.net.httpserver -- Cannot be resolved and > overwritten by > >>>>>>>>> Boot Delegation > >>>>>>>>> ERROR: com.sun.rowset -- Cannot be resolved and overwritten by > Boot > >>>>>>>> Delegation > >>>>>>>>> ERROR: commonj.timers -- Cannot be resolved > >>>>>>>>> ERROR: commonj.work -- Cannot be resolved > >>>>>>>>> ERROR: edu.emory.mathcs.backport.java.util.concurrent -- Cannot > be > >>>>>>>> resolved > >>>>>>>>> ERROR: freemarker.cache -- Cannot be resolved > >>>>>>>>> ERROR: freemarker.template -- Cannot be resolved > >>>>>>>>> > >>>>>>>>> My understanding was using > <Embed-Transitive>true</Embed-Transitive> > >>>>>>>>> will embed all transitive dependency jars in the bundle,but > apparently > >>>>>>>>> that's not been the case so far. > >>>>>>>>> > >>>>>>>>> I'll appreciate if someone can tell what's the right approach to > >>>>>>>>> resolve this issue. > >>>>>>>>> > >>>>>>>>> -Thanks > >>>>>>>>> > >>>>>>>>> > --------------------------------------------------------------------- > >>>>>>>>> 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] > >>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> 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] > >
