[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] plans for the bundlor toolset

Thanks! (But I am subscribed too)

 

From: virgo-dev-bounces@xxxxxxxxxxx [mailto:virgo-dev-bounces@xxxxxxxxxxx] On Behalf Of Joel Rosi-Schwartz
Sent: 09 January 2012 10:19
To: Virgo Project
Subject: Re: [virgo-dev] plans for the bundlor toolset

 

FYI...

 

On 9 Jan 2012, at 10:15, Glyn Normington wrote:



Hi Timothy

 

Responses inline.

 

Regards,
Glyn

 

On 6 Jan 2012, at 18:43, Timothy Redmond wrote:



 

Hello - I hope that I am posting this to the right place.

 

You are.



 

I am interested in the bundlor tool; I don't yet know much about the Virgo project as a whole.  My first question is the extent to which the eclipse team plans to support this tool in the future.  It seems a bit hidden in the Virgo project web page (though I did get a downloaded copy somewhere).

 

We want to maintain bundlor as part of Virgo, but given that the SpringSource bundlor is pretty stable and bug free, we haven't paid much attention to Virgo bundlor. For instance, we haven't gone through the Eclipse release process for Virgo bundlor.



 

My second question is about importing exported packages.  This appears to be good OSGi practice (http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html for example) and it has helped me on occasion from getting separate versions of the same class in an OSGi framework instance.  However I didn't figure out how to make this happen.  In addition there is place in the bundlor-1.1.0.M03 documentation that suggests that bundlor regards importing exports as an error:

 

Bundlor checks that the manifest does not import any package that it exports. This behavior is usually indicative of a package split between two bundles.

 

The recommendation to import exported packages is not as clear cut as you might think:

 

1. The above blog was tweaked in January 2010 to add some caveats.

 

2. I believe the only generally valid usecase is where a bundle exports a package containing one or more interfaces but *no* implementation classes. In that case, it might make sense to import the package too so that the bundle could share the package with another bundle which exports the package.

 

3. The practice derives from OSGi R3 behaviour which didn't have version ranges on imports and made the generally false assumption that higher versions of packages are always backward compatible with lower versions.

 

4. There are still situations being discussed in the OSGi Expert Groups where so called "substitutable exports" don't make sense. E.g. when the imported version range excludes the exported version (!).

 

However, Bundlor was designed with enterprise use cases in mind. In this case, we didn't want to encourage people to have multiple bundles in a system exporting an interface package as that would probably cause confusion.

 

But I accept that there may be rare situations in which Bundlor should allow this practice and we could perhaps change Bundlor's behaviour, e.g. via a switch or by some indication in the manifest template. Alternatively, users with this requirement are free to use bnd instead.



 

 

My final question is whether you would consider adding some newlines to the generated manifest to make it a bit easier to read.  In particular,  I believe that you don't need to wait for character 72 to use a newline and a space in a manifest.  If this is correct then I think it would be useful if the manifest was just a bit easier to read (it isn't worth working too hard on this).  I admit that the manifest is a generated file but sometimes when debugging the manifest it would be nice to read it a bit more easily.

 

That seems like a reasonable enhancement. Perhaps you would care to raise an enhancement bugzilla. I can't commit any resources to it at the moment, but it's the sort of thing that even a newcomer could take a crack at. (Feel free to have a go yourself - if you hit problems, we can help you.)



 

-Timothy

 

 

 

 

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev

 

_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev

 



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 04677092. VAT registration number 761 2978 07. Registered Office: Cannon Bridge House, 25 Dowgate Hill, London EC4R 2YA. Listed on the London Stock Exchange. Its subsidiaries IG Markets Limited and IG Index Limited are authorised and regulated by the Financial Services Authority (IG Markets Limited FSA registration number 195355 and IG Index Limited FSA registration number 114059).