You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@felix.apache.org by Barbara Rosi-Schwartz <Ba...@iggroup.com> on 2011/10/17 11:03:16 UTC

Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

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-Dependency>
  </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


________________________________
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.

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

Wow, I never thought I would ever hear strong opinioned you being ambivalent about something!... ;-)

Thank you very much, I will mull it over and decide which one of the "evils" to implement.

Cheerio,
B.

-----Original Message-----
From: Neil Bartlett [mailto:njbartlett@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:njbartlett@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:njbartlett@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-Schwartz@iggroup.com 
> > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > (mailto:Barbara.Rosi-Schwartz@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.

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

Thanks for the advice, Stuart. I am indeed seeing some weird effects, but I will experiment further and then collect my results and report.

Looking forward to seeing you at the next OSGi Users' Forum UK!
B.

-----Original Message-----
From: Stuart McCulloch [mailto:mcculls@gmail.com] 
Sent: 26 October 2011 13:17
To: users@felix.apache.org
Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

On 19 Oct 2011, at 15:09, Barbara Rosi-Schwartz wrote:

> 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)?

The best advice (imho) is to trust the default settings*, especially for the latest snapshot of the bundleplugin. Focus on getting the content of the bundle correct, and decide if you need to embed/inline any dependencies. (Inlining dependencies instead of embedding them can make it easier to test the bundle outside of OSGi.) I'm always surprised how few people ever look inside the final jar.

Once the content is correct you can start checking the exports, adding versions as necessary. Then check the imports - the plugin now marks packages from optional Maven dependencies as optional in OSGi, which takes a lot of the previous burden away - but you should still consider adding version ranges.

Finally look into using something like Pax-Exam to confirm that your bundle(s) will install into an OSGi framework.

This is the basic approach I usually take - the OSGi in Action book goes into this process in more detail and has online examples: http://code.google.com/p/osgi-in-action/ - however note that it mainly uses bnd+ant, with maven configuration discussed in a short appendix. The general process is basically the same though, as both tools are configured with bnd instructions.

[*]  if you need to configure the bundleplugin with something already captured by Maven, please raise it as an issue - we want to minimise config where possible

> 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.

I can't make it to JAX, but I hope to be at the next meeting of the OSGi Users' Forum UK: http://uk.osgiusers.org/Main/MeetingsandEventsCalendar#nextmeet

> Thanks,
> B.
> 
> -----Original Message-----
> From: Stuart McCulloch [mailto:mcculls@gmail.com]
> Sent: 19 October 2011 13:35
> To: users@felix.apache.org
> 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:njbartlett@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:njbartlett@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:njbartlett@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-Schwartz@iggroup.com
>>>>> (mailto:Barbara.Rosi-Schwartz@iggroup.com)
>>>>> (mailto:Barbara.Rosi-Schwartz@iggroup.com)
>>>>> (mailto:Barbara.Rosi-Schwartz@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.
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Stuart McCulloch <mc...@gmail.com>.

On 19 Oct 2011, at 15:09, Barbara Rosi-Schwartz wrote:

> 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)?

The best advice (imho) is to trust the default settings*, especially for the latest snapshot of the bundleplugin. Focus on getting the content of the bundle correct, and decide if you need to embed/inline any dependencies. (Inlining dependencies instead of embedding them can make it easier to test the bundle outside of OSGi.) I'm always surprised how few people ever look inside the final jar.

Once the content is correct you can start checking the exports, adding versions as necessary. Then check the imports - the plugin now marks packages from optional Maven dependencies as optional in OSGi, which takes a lot of the previous burden away - but you should still consider adding version ranges.

Finally look into using something like Pax-Exam to confirm that your bundle(s) will install into an OSGi framework.

This is the basic approach I usually take - the OSGi in Action book goes into this process in more detail and has online examples: http://code.google.com/p/osgi-in-action/ - however note that it mainly uses bnd+ant, with maven configuration discussed in a short appendix. The general process is basically the same though, as both tools are configured with bnd instructions.

[*]  if you need to configure the bundleplugin with something already captured by Maven, please raise it as an issue - we want to minimise config where possible

> 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.

I can't make it to JAX, but I hope to be at the next meeting of the OSGi Users' Forum UK: http://uk.osgiusers.org/Main/MeetingsandEventsCalendar#nextmeet

> Thanks,
> B.
> 
> -----Original Message-----
> From: Stuart McCulloch [mailto:mcculls@gmail.com] 
> Sent: 19 October 2011 13:35
> To: users@felix.apache.org
> 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:njbartlett@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:njbartlett@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:njbartlett@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-Schwartz@iggroup.com
>>>>> (mailto:Barbara.Rosi-Schwartz@iggroup.com)
>>>>> (mailto:Barbara.Rosi-Schwartz@iggroup.com)
>>>>> (mailto:Barbara.Rosi-Schwartz@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.
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

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:mcculls@gmail.com] 
Sent: 19 October 2011 13:35
To: users@felix.apache.org
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:njbartlett@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:njbartlett@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:njbartlett@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-Schwartz@iggroup.com
>>>> (mailto:Barbara.Rosi-Schwartz@iggroup.com)
>>>> (mailto:Barbara.Rosi-Schwartz@iggroup.com)
>>>> (mailto:Barbara.Rosi-Schwartz@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.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Stuart McCulloch <mc...@gmail.com>.

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:njbartlett@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:njbartlett@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:njbartlett@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-Schwartz@iggroup.com 
>>>> (mailto:Barbara.Rosi-Schwartz@iggroup.com)
>>>> (mailto:Barbara.Rosi-Schwartz@iggroup.com)
>>>> (mailto:Barbara.Rosi-Schwartz@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.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

Thanks Pierre.

I am already using an OBR!... :-(

-----Original Message-----
From: Pierre Henry Perret [mailto:phperret@gmail.com]
Sent: 19 October 2011 09:33
To: users@felix.apache.org
Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Goord morning all,
Barbara, I would suggest using a common bundle repo, OBR is its name for as OSGi bundles arre concerned, and use that OBR repo to mutualize all your software maven related bundles which should then split in two categories,
knowing: COMMONS libs - apache, eclipse... - and  LEGACY ( enterprise bundles ) or BUSINESS.

Then , all these maven technical annoyings will vanished...!

The tip and tricks of maven , augmented with the peculiarity of specific OSGi functionning, make it a challenge to cut her way through it .

--
Pierre-Henry Perret
mob2: +33 (0)6 69 52 18 48




2011/10/19 Barbara Rosi-Schwartz <Ba...@iggroup.com>

> 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:njbartlett@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:njbartlett@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:njbartlett@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-Schwartz@iggroup.com
> > > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > > (mailto:Barbara.Rosi-Schwartz@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-Depe
> > > > > nd
> > > > > 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.
>
>

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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Pierre Henry Perret <ph...@gmail.com>.

Goord morning all,
Barbara, I would suggest using a common bundle repo, OBR is its name for as
OSGi bundles arre concerned, and use that OBR repo to mutualize all your
software maven related bundles which should then split in two categories,
knowing: COMMONS libs - apache, eclipse... - and  LEGACY ( enterprise
bundles ) or BUSINESS.

Then , all these maven technical annoyings will vanished...!

The tip and tricks of maven , augmented with the peculiarity of specific
OSGi functionning, make it a challenge to cut her way through it .

--
Pierre-Henry Perret
mob2: +33 (0)6 69 52 18 48




2011/10/19 Barbara Rosi-Schwartz <Ba...@iggroup.com>

> 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:njbartlett@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:njbartlett@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:njbartlett@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-Schwartz@iggroup.com
> > > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > > (mailto:Barbara.Rosi-Schwartz@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.
>
>

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Dileepa Jayakody <di...@wso2.com>.

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 <Embed-Dependency> 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

Thanks,
Dileepa

On Wed, Oct 19, 2011 at 1:45 PM, Barbara Rosi-Schwartz <
Barbara.Rosi-Schwartz@iggroup.com> 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?
>
> TIA,
> B.
>
> -----Original Message-----
> From: Neil Bartlett [mailto:njbartlett@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:njbartlett@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:njbartlett@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-Schwartz@iggroup.com
> > > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > > (mailto:Barbara.Rosi-Schwartz@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.
>
>

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

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:njbartlett@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:njbartlett@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:njbartlett@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-Schwartz@iggroup.com 
> > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > (mailto:Barbara.Rosi-Schwartz@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.

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Neil Bartlett <nj...@gmail.com>.

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:njbartlett@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:njbartlett@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-Schwartz@iggroup.com (mailto:Barbara.Rosi-Schwartz@iggroup.com)  
> > > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > > (mailto:Barbara.Rosi-Schwartz@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-Dependen
> > > > 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.

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

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:njbartlett@gmail.com] 
Sent: 17 October 2011 14:11
To: 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:njbartlett@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-Schwartz@iggroup.com 
> > (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > (mailto:Barbara.Rosi-Schwartz@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-Dependen
> > > 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.

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Neil Bartlett <nj...@gmail.com>.

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:njbartlett@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-Schwartz@iggroup.com (mailto:Barbara.Rosi-Schwartz@iggroup.com)
> > (mailto:Barbara.Rosi-Schwartz@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-Dependency
> > > </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.

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

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:njbartlett@gmail.com]
Sent: 17 October 2011 12:11
To: 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-Schwartz@iggroup.com
> (mailto:Barbara.Rosi-Schwartz@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-Dependency
> > >
> > </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.

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Neil Bartlett <nj...@gmail.com>.

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-Schwartz@iggroup.com (mailto:Barbara.Rosi-Schwartz@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-Dependency>
> > </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.

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

Hi Pierre, thanks for your answer.

I am not really sure I understand how your suggestion helps with my problem. Would you care to expand a little?

-----Original Message-----
From: Pierre Henry Perret [mailto:phperret@gmail.com]
Sent: 17 October 2011 11:52
To: users@felix.apache.org
Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

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 <Ba...@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-Dependency>
>  </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
>
>
> ________________________________
> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Pierre Henry Perret <ph...@gmail.com>.

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 <Ba...@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-Dependency>
>  </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
>
>
> ________________________________
> 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.
>

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

Hi Stuart, fantastic!

Does this mean I no longer need to raise an issue, as you previously suggested?

Thanks,
B.

-----Original Message-----
From: Stuart McCulloch [mailto:mcculls@gmail.com] 
Sent: 27 October 2011 00:24
To: users@felix.apache.org
Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

On 17 Oct 2011, at 10:03, Barbara Rosi-Schwartz wrote:

> 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-Dependency>
>  </instructions>
> </configuration>

FYI, I've made some improvements to how we parse and process the Embed-Dependency instruction:

   https://issues.apache.org/jira/browse/FELIX-3185

Could you try the latest snapshot (2.4.0-20111026.231345-12) and see if it behaves as you expect?

> 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
> 
> 
> ________________________________
> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Stuart McCulloch <mc...@gmail.com>.

On 17 Oct 2011, at 10:03, Barbara Rosi-Schwartz wrote:

> 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-Dependency>
>  </instructions>
> </configuration>

FYI, I've made some improvements to how we parse and process the Embed-Dependency instruction:

   https://issues.apache.org/jira/browse/FELIX-3185

Could you try the latest snapshot (2.4.0-20111026.231345-12) and see if it behaves as you expect?

> 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
> 
> 
> ________________________________
> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Stuart McCulloch <mc...@gmail.com>.

On 17 Oct 2011, at 13:59, Barbara Rosi-Schwartz wrote:

> BTW, I looked into the various items of documentation on the web and could not find any explanation for the Embed-Dependency instruction that explains what you, Stuart, have explained below. Examples also do not show cases like that.

the current embedding examples are shown below, but they don't cover the negative clause case:

   http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html#ApacheFelixMavenBundlePlugin%28BND%29-Embeddingdependencies

the issue wrt. negative clauses is a flaw in the current implementation, which is why it wasn't documented ;)

> It would probably be worth augmenting the docs with that information.
> 
> Thanks!
> B.
> 
> -----Original Message-----
> From: Stuart McCulloch [mailto:mcculls@gmail.com] 
> Sent: 17 October 2011 12:55
> To: users@felix.apache.org
> Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies
> 
> On 17 Oct 2011, at 10:03, Barbara Rosi-Schwartz wrote:
> 
>> 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-Dependency>
>> </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?
> 
> Hi B,
> 
> At the moment the Embed-Dependency clauses are processed independently when they're mapped to bnd instructions (Include-Resource and Bundle-ClassPath).
> 
> So "!foo-baz, *;scope=compile|runtime" is actually processed as:
> 
>   !foo-baz                                  -->        embed any dependency whose artifactId is not foo-bar
> 
>   *;scope=compile|runtime        -->        embed any compile/runtime scope dependency
> 
> Unfortunately this is different to how bnd processes negative Import-Package clauses, which I agree is confusing - if you raise an issue for this at https://issues.apache.org/jira/browse/FELIX/component/12311143 I'll look into fixing this. Note that if you just use positive clauses then you won't encounter this problem.
> 
> Meanwhile, as a workaround you can use:
> 
>   <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency>
> 
> which because it's one clause will achieve the desired result.
> 
> You can't easily extend this to exclude more than one artifactId, but in that case you could perhaps deploy your OSGi and non-OSGi artifacts under different groups and use the groupId to selectively embed only non-OSGi artifacts:
> 
>   <Embed-Dependency>groupId=!foo-osgi;scope=compile|runtime</Embed-Dependency>
> 
> Or as Neil suggested, you could look into converting those dependencies into individual OSGi bundles.
> 
> --
> Cheers, Stuart
> 
>> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

BTW, I looked into the various items of documentation on the web and could not find any explanation for the Embed-Dependency instruction that explains what you, Stuart, have explained below. Examples also do not show cases like that.

It would probably be worth augmenting the docs with that information.

Thanks!
B.

-----Original Message-----
From: Stuart McCulloch [mailto:mcculls@gmail.com] 
Sent: 17 October 2011 12:55
To: users@felix.apache.org
Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

On 17 Oct 2011, at 10:03, Barbara Rosi-Schwartz wrote:

> 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-Dependency>
>  </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?

Hi B,

At the moment the Embed-Dependency clauses are processed independently when they're mapped to bnd instructions (Include-Resource and Bundle-ClassPath).

So "!foo-baz, *;scope=compile|runtime" is actually processed as:

   !foo-baz                                  -->        embed any dependency whose artifactId is not foo-bar

   *;scope=compile|runtime        -->        embed any compile/runtime scope dependency

Unfortunately this is different to how bnd processes negative Import-Package clauses, which I agree is confusing - if you raise an issue for this at https://issues.apache.org/jira/browse/FELIX/component/12311143 I'll look into fixing this. Note that if you just use positive clauses then you won't encounter this problem.

Meanwhile, as a workaround you can use:

   <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency>

which because it's one clause will achieve the desired result.

You can't easily extend this to exclude more than one artifactId, but in that case you could perhaps deploy your OSGi and non-OSGi artifacts under different groups and use the groupId to selectively embed only non-OSGi artifacts:

   <Embed-Dependency>groupId=!foo-osgi;scope=compile|runtime</Embed-Dependency>

Or as Neil suggested, you could look into converting those dependencies into individual OSGi bundles.

--
Cheers, Stuart

> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

Hi Stuart,

Found my (ridiculous) problem, sorry I have bothered you. Simply forgot to set the <packaging> element as "bundle".

Thanks,
B.

-----Original Message-----
From: Stuart McCulloch [mailto:mcculls@gmail.com] 
Sent: 17 October 2011 17:19
To: users@felix.apache.org
Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

On 17 Oct 2011, at 17:01, Barbara Rosi-Schwartz wrote:

> I mean that I don't see the actual "third party" dependencies being embedded in the foo-bar.jar file. The manifest appears to be correct.

If you want to see the instructions sent to bnd and the results passed back you can use "mvn -X install" ... pipe the output to a file and search for BND. That should show whether the processed Include-Resource instruction sent to bnd has those "third party" dependencies (feel free to paste the bnd log into a reply if you want this checked). BTW, are you just excluding a single artifact from being embedded or several? Could you paste your bnd instructions into an email?

Otherwise consider attaching a test project to an issue on JIRA... if I use the "!foo-baz;scope=compile|runtime" form I see the expected results in the manifest and jar file.

> -----Original Message-----
> From: Stuart McCulloch [mailto:mcculls@gmail.com] 
> Sent: 17 October 2011 16:51
> To: users@felix.apache.org
> Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies
> 
> On 17 Oct 2011, at 16:46, Barbara Rosi-Schwartz wrote:
> 
>> Hi Stuart, when I run the Maven Bundle plug-in with your suggested modification, I do not see the embedded dependencies in the generated jar. Is there another trick to it? ;-)
> 
> Do you mean you don't see any embedded dependency, or that it correctly excludes the foo-baz dependency?
> 
> I got the expected results locally using <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency> and bundleplugin 2.3.5
> 
>> Thanks!
>> B.
>> 
>> -----Original Message-----
>> From: Stuart McCulloch [mailto:mcculls@gmail.com] 
>> Sent: 17 October 2011 12:55
>> To: users@felix.apache.org
>> Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies
>> 
>> On 17 Oct 2011, at 10:03, Barbara Rosi-Schwartz wrote:
>> 
>>> 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-Dependency>
>>> </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?
>> 
>> Hi B,
>> 
>> At the moment the Embed-Dependency clauses are processed independently when they're mapped to bnd instructions (Include-Resource and Bundle-ClassPath).
>> 
>> So "!foo-baz, *;scope=compile|runtime" is actually processed as:
>> 
>>  !foo-baz                                  -->        embed any dependency whose artifactId is not foo-bar
>> 
>>  *;scope=compile|runtime        -->        embed any compile/runtime scope dependency
>> 
>> Unfortunately this is different to how bnd processes negative Import-Package clauses, which I agree is confusing - if you raise an issue for this at https://issues.apache.org/jira/browse/FELIX/component/12311143 I'll look into fixing this. Note that if you just use positive clauses then you won't encounter this problem.
>> 
>> Meanwhile, as a workaround you can use:
>> 
>>  <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency>
>> 
>> which because it's one clause will achieve the desired result.
>> 
>> You can't easily extend this to exclude more than one artifactId, but in that case you could perhaps deploy your OSGi and non-OSGi artifacts under different groups and use the groupId to selectively embed only non-OSGi artifacts:
>> 
>>  <Embed-Dependency>groupId=!foo-osgi;scope=compile|runtime</Embed-Dependency>
>> 
>> Or as Neil suggested, you could look into converting those dependencies into individual OSGi bundles.
>> 
>> --
>> Cheers, Stuart
>> 
>>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Stuart McCulloch <mc...@gmail.com>.

On 17 Oct 2011, at 17:01, Barbara Rosi-Schwartz wrote:

> I mean that I don't see the actual "third party" dependencies being embedded in the foo-bar.jar file. The manifest appears to be correct.

If you want to see the instructions sent to bnd and the results passed back you can use "mvn -X install" ... pipe the output to a file and search for BND. That should show whether the processed Include-Resource instruction sent to bnd has those "third party" dependencies (feel free to paste the bnd log into a reply if you want this checked). BTW, are you just excluding a single artifact from being embedded or several? Could you paste your bnd instructions into an email?

Otherwise consider attaching a test project to an issue on JIRA... if I use the "!foo-baz;scope=compile|runtime" form I see the expected results in the manifest and jar file.

> -----Original Message-----
> From: Stuart McCulloch [mailto:mcculls@gmail.com] 
> Sent: 17 October 2011 16:51
> To: users@felix.apache.org
> Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies
> 
> On 17 Oct 2011, at 16:46, Barbara Rosi-Schwartz wrote:
> 
>> Hi Stuart, when I run the Maven Bundle plug-in with your suggested modification, I do not see the embedded dependencies in the generated jar. Is there another trick to it? ;-)
> 
> Do you mean you don't see any embedded dependency, or that it correctly excludes the foo-baz dependency?
> 
> I got the expected results locally using <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency> and bundleplugin 2.3.5
> 
>> Thanks!
>> B.
>> 
>> -----Original Message-----
>> From: Stuart McCulloch [mailto:mcculls@gmail.com] 
>> Sent: 17 October 2011 12:55
>> To: users@felix.apache.org
>> Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies
>> 
>> On 17 Oct 2011, at 10:03, Barbara Rosi-Schwartz wrote:
>> 
>>> 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-Dependency>
>>> </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?
>> 
>> Hi B,
>> 
>> At the moment the Embed-Dependency clauses are processed independently when they're mapped to bnd instructions (Include-Resource and Bundle-ClassPath).
>> 
>> So "!foo-baz, *;scope=compile|runtime" is actually processed as:
>> 
>>  !foo-baz                                  -->        embed any dependency whose artifactId is not foo-bar
>> 
>>  *;scope=compile|runtime        -->        embed any compile/runtime scope dependency
>> 
>> Unfortunately this is different to how bnd processes negative Import-Package clauses, which I agree is confusing - if you raise an issue for this at https://issues.apache.org/jira/browse/FELIX/component/12311143 I'll look into fixing this. Note that if you just use positive clauses then you won't encounter this problem.
>> 
>> Meanwhile, as a workaround you can use:
>> 
>>  <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency>
>> 
>> which because it's one clause will achieve the desired result.
>> 
>> You can't easily extend this to exclude more than one artifactId, but in that case you could perhaps deploy your OSGi and non-OSGi artifacts under different groups and use the groupId to selectively embed only non-OSGi artifacts:
>> 
>>  <Embed-Dependency>groupId=!foo-osgi;scope=compile|runtime</Embed-Dependency>
>> 
>> Or as Neil suggested, you could look into converting those dependencies into individual OSGi bundles.
>> 
>> --
>> Cheers, Stuart
>> 
>>> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

I mean that I don't see the actual "third party" dependencies being embedded in the foo-bar.jar file. The manifest appears to be correct.

-----Original Message-----
From: Stuart McCulloch [mailto:mcculls@gmail.com] 
Sent: 17 October 2011 16:51
To: users@felix.apache.org
Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

On 17 Oct 2011, at 16:46, Barbara Rosi-Schwartz wrote:

> Hi Stuart, when I run the Maven Bundle plug-in with your suggested modification, I do not see the embedded dependencies in the generated jar. Is there another trick to it? ;-)

Do you mean you don't see any embedded dependency, or that it correctly excludes the foo-baz dependency?

I got the expected results locally using <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency> and bundleplugin 2.3.5

> Thanks!
> B.
> 
> -----Original Message-----
> From: Stuart McCulloch [mailto:mcculls@gmail.com] 
> Sent: 17 October 2011 12:55
> To: users@felix.apache.org
> Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies
> 
> On 17 Oct 2011, at 10:03, Barbara Rosi-Schwartz wrote:
> 
>> 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-Dependency>
>> </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?
> 
> Hi B,
> 
> At the moment the Embed-Dependency clauses are processed independently when they're mapped to bnd instructions (Include-Resource and Bundle-ClassPath).
> 
> So "!foo-baz, *;scope=compile|runtime" is actually processed as:
> 
>   !foo-baz                                  -->        embed any dependency whose artifactId is not foo-bar
> 
>   *;scope=compile|runtime        -->        embed any compile/runtime scope dependency
> 
> Unfortunately this is different to how bnd processes negative Import-Package clauses, which I agree is confusing - if you raise an issue for this at https://issues.apache.org/jira/browse/FELIX/component/12311143 I'll look into fixing this. Note that if you just use positive clauses then you won't encounter this problem.
> 
> Meanwhile, as a workaround you can use:
> 
>   <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency>
> 
> which because it's one clause will achieve the desired result.
> 
> You can't easily extend this to exclude more than one artifactId, but in that case you could perhaps deploy your OSGi and non-OSGi artifacts under different groups and use the groupId to selectively embed only non-OSGi artifacts:
> 
>   <Embed-Dependency>groupId=!foo-osgi;scope=compile|runtime</Embed-Dependency>
> 
> Or as Neil suggested, you could look into converting those dependencies into individual OSGi bundles.
> 
> --
> Cheers, Stuart
> 
>> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Stuart McCulloch <mc...@gmail.com>.

On 17 Oct 2011, at 16:46, Barbara Rosi-Schwartz wrote:

> Hi Stuart, when I run the Maven Bundle plug-in with your suggested modification, I do not see the embedded dependencies in the generated jar. Is there another trick to it? ;-)

Do you mean you don't see any embedded dependency, or that it correctly excludes the foo-baz dependency?

I got the expected results locally using <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency> and bundleplugin 2.3.5

> Thanks!
> B.
> 
> -----Original Message-----
> From: Stuart McCulloch [mailto:mcculls@gmail.com] 
> Sent: 17 October 2011 12:55
> To: users@felix.apache.org
> Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies
> 
> On 17 Oct 2011, at 10:03, Barbara Rosi-Schwartz wrote:
> 
>> 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-Dependency>
>> </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?
> 
> Hi B,
> 
> At the moment the Embed-Dependency clauses are processed independently when they're mapped to bnd instructions (Include-Resource and Bundle-ClassPath).
> 
> So "!foo-baz, *;scope=compile|runtime" is actually processed as:
> 
>   !foo-baz                                  -->        embed any dependency whose artifactId is not foo-bar
> 
>   *;scope=compile|runtime        -->        embed any compile/runtime scope dependency
> 
> Unfortunately this is different to how bnd processes negative Import-Package clauses, which I agree is confusing - if you raise an issue for this at https://issues.apache.org/jira/browse/FELIX/component/12311143 I'll look into fixing this. Note that if you just use positive clauses then you won't encounter this problem.
> 
> Meanwhile, as a workaround you can use:
> 
>   <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency>
> 
> which because it's one clause will achieve the desired result.
> 
> You can't easily extend this to exclude more than one artifactId, but in that case you could perhaps deploy your OSGi and non-OSGi artifacts under different groups and use the groupId to selectively embed only non-OSGi artifacts:
> 
>   <Embed-Dependency>groupId=!foo-osgi;scope=compile|runtime</Embed-Dependency>
> 
> Or as Neil suggested, you could look into converting those dependencies into individual OSGi bundles.
> 
> --
> Cheers, Stuart
> 
>> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

Hi Stuart, when I run the Maven Bundle plug-in with your suggested modification, I do not see the embedded dependencies in the generated jar. Is there another trick to it? ;-)

Thanks!
B.

-----Original Message-----
From: Stuart McCulloch [mailto:mcculls@gmail.com] 
Sent: 17 October 2011 12:55
To: users@felix.apache.org
Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

On 17 Oct 2011, at 10:03, Barbara Rosi-Schwartz wrote:

> 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-Dependency>
>  </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?

Hi B,

At the moment the Embed-Dependency clauses are processed independently when they're mapped to bnd instructions (Include-Resource and Bundle-ClassPath).

So "!foo-baz, *;scope=compile|runtime" is actually processed as:

   !foo-baz                                  -->        embed any dependency whose artifactId is not foo-bar

   *;scope=compile|runtime        -->        embed any compile/runtime scope dependency

Unfortunately this is different to how bnd processes negative Import-Package clauses, which I agree is confusing - if you raise an issue for this at https://issues.apache.org/jira/browse/FELIX/component/12311143 I'll look into fixing this. Note that if you just use positive clauses then you won't encounter this problem.

Meanwhile, as a workaround you can use:

   <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency>

which because it's one clause will achieve the desired result.

You can't easily extend this to exclude more than one artifactId, but in that case you could perhaps deploy your OSGi and non-OSGi artifacts under different groups and use the groupId to selectively embed only non-OSGi artifacts:

   <Embed-Dependency>groupId=!foo-osgi;scope=compile|runtime</Embed-Dependency>

Or as Neil suggested, you could look into converting those dependencies into individual OSGi bundles.

--
Cheers, Stuart

> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

RE: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Barbara Rosi-Schwartz <Ba...@iggroup.com>.

Hello Stuart.

Thank you very much for the explanation and the solution, I will try that out; I will also raise an issue so that you can hopefully fix things as you mention.

B.

-----Original Message-----
From: Stuart McCulloch [mailto:mcculls@gmail.com] 
Sent: 17 October 2011 12:55
To: users@felix.apache.org
Subject: Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

On 17 Oct 2011, at 10:03, Barbara Rosi-Schwartz wrote:

> 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-Dependency>
>  </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?

Hi B,

At the moment the Embed-Dependency clauses are processed independently when they're mapped to bnd instructions (Include-Resource and Bundle-ClassPath).

So "!foo-baz, *;scope=compile|runtime" is actually processed as:

   !foo-baz                                  -->        embed any dependency whose artifactId is not foo-bar

   *;scope=compile|runtime        -->        embed any compile/runtime scope dependency

Unfortunately this is different to how bnd processes negative Import-Package clauses, which I agree is confusing - if you raise an issue for this at https://issues.apache.org/jira/browse/FELIX/component/12311143 I'll look into fixing this. Note that if you just use positive clauses then you won't encounter this problem.

Meanwhile, as a workaround you can use:

   <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency>

which because it's one clause will achieve the desired result.

You can't easily extend this to exclude more than one artifactId, but in that case you could perhaps deploy your OSGi and non-OSGi artifacts under different groups and use the groupId to selectively embed only non-OSGi artifacts:

   <Embed-Dependency>groupId=!foo-osgi;scope=compile|runtime</Embed-Dependency>

Or as Neil suggested, you could look into converting those dependencies into individual OSGi bundles.

--
Cheers, Stuart

> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Hot to configure Maven Bundle plug-in for a mixture of OSGi and non OSGi dependencies

Posted by Stuart McCulloch <mc...@gmail.com>.

On 17 Oct 2011, at 10:03, Barbara Rosi-Schwartz wrote:

> 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-Dependency>
>  </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?

Hi B,

At the moment the Embed-Dependency clauses are processed independently when they're mapped to bnd instructions (Include-Resource and Bundle-ClassPath).

So "!foo-baz, *;scope=compile|runtime" is actually processed as:

   !foo-baz                                  -->        embed any dependency whose artifactId is not foo-bar

   *;scope=compile|runtime        -->        embed any compile/runtime scope dependency

Unfortunately this is different to how bnd processes negative Import-Package clauses, which I agree is confusing - if you raise an issue for this at https://issues.apache.org/jira/browse/FELIX/component/12311143 I'll look into fixing this. Note that if you just use positive clauses then you won't encounter this problem.

Meanwhile, as a workaround you can use:

   <Embed-Dependency>!foo-baz;scope=compile|runtime</Embed-Dependency>

which because it's one clause will achieve the desired result.

You can't easily extend this to exclude more than one artifactId, but in that case you could perhaps deploy your OSGi and non-OSGi artifacts under different groups and use the groupId to selectively embed only non-OSGi artifacts:

   <Embed-Dependency>groupId=!foo-osgi;scope=compile|runtime</Embed-Dependency>

Or as Neil suggested, you could look into converting those dependencies into individual OSGi bundles.

--
Cheers, Stuart

> 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: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org