On 6 Jun 2012, at 17:46, Christian Edward Gruber wrote:

> 
> On Jun 6, 2012, at 12:08 PM, Stuart McCulloch wrote:
> 
>> On 6 Jun 2012, at 16:51, Christian Edward Gruber wrote:
>> 
>>> Hey all,
>>> 
>>>     So… this sucks rocks, but sadly, the OSGI metadata included in 3.0 is 
>>> broken - not in a way that  inhibits guice core, but for using any of the 
>>> extensions in an OSGI environment.
>> 
>> This statement is not quite correct - the Eclipse-ExtensibleAPI is not an 
>> OSGi header, it is only used by Eclipse/PDE tooling (not runtime) and 
>> therefore the metadata is not broken for general OSGi users.
>> 
>> From the Eclipse docs at 
>> http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fbundle_manifest.html
>> 
>>    "The Eclipse-ExtensibleAPI is used to specify whether a host bundle 
>> allows fragment bundles to add additional API to the host. This header 
>> should be used if a host bundle wants to allow fragments to add additional 
>> packages to the API of the host. If this header is not specified then a 
>> default value of 'false' is used. Note that this header is only used by 
>> tooling (PDE) to construct proper class paths for building. The runtime does 
>> not use this header at all. At runtime a fragment is always allowed to add 
>> additional packages, classes and resources to the API of the host."
>> 
>> So anyone deploying Guice or its extensions at runtime in OSGi should be 
>> fine - this particular issue is limited to when you're developing inside 
>> Eclipse/PDE and have the extension imported as a project.
> 
> Fair comment, though it seems to also affect Tycho, so perhaps it's more fair 
> to say it's a build-time (IDE or otherwise) issue.  Tycho seems to honor the 
> setting. 

Note that Tycho re-uses some of the same underlying Eclipse tooling as 
Eclipse/PDE - this is definitely Eclipse specific (indicated by the header 
name) and doesn't affect other OSGi capable IDEs/tools

>>>     The bottom line is this - 
>>> http://code.google.com/p/google-guice/issues/detail?id=494.  The missing 
>>> Eclipse-ExtensibleAPI: true property from the OSGI metadata means that 
>>> anyone using guice's extensions in a variety of osgi contexts is broken 
>>> unless they repackage guice and the extension into their own osgi bundle.  
>>> In order to make my own such project work, I need to build a local version 
>>> of guice including that fix (or depend on other people's repackaging of 
>>> guice).  
>>> 
>>>     I propose a 3.0.1 bug-fix release that simply updates the metadata.  
>>> Basically a branch from 3.0 as-released with mcculls' patch pulled in. I 
>>> wish I could just update the metadata on maven central repo, but released 
>>> artifacts are, as we all probably know, write-once. 
>>> 
>>>     So… any objections to rolling 3.0.1 as-described.  And if not… are 
>>> there any critical bug-fixes that have made their way in that are worth 
>>> cherry picking?  This is not a release from head, so I'd rather keep it to 
>>> a minimum, but just in case people have urgent things they feel are worth 
>>> the trouble.
>> 
>> No objections - alternatively has trunk reached a stable enough state for a 
>> 3.1 release?  There's plenty of good stuff since the last release, such as 
>> the new ProvisionListener API.
> 
> I haven't been tracking the progress long enough to get a good feel for that. 
>  I'm ok with either, if the HEAD is sane enough.  Sam? Jesse?  Anyone else?
> 
> The only reason I'd recommend doing a quick 3.0.1 and THEN looking at a 3.1 
> is that this is quite trivial to whip up and release without (much) fanfare, 
> where I'd rather take a bit of time to roll release notes more thoroughly, 
> and make sure I'm acquainted with what goes out the door, and I'm kind of 
> full up for a bit trying to close down other projects so I can focus on Guice 
> full-time. 
> 
> Christian.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"google-guice-dev" group.
To post to this group, send email to google-guice-dev@googlegroups.com.
To unsubscribe from this group, send email to 
google-guice-dev+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-guice-dev?hl=en.

Reply via email to