felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Visibility semantics
Date Tue, 28 Jul 2009 16:35:19 GMT
On 7/28/09 12:21 PM, David Savage wrote:
> On Tue, Jul 28, 2009 at 3:34 PM, Richard S. Hall<heavy@ungoverned.org>  wrote:
>    
>> On 7/28/09 9:47 AM, David Savage wrote:
>>      
>>> On Mon, Jul 27, 2009 at 4:03 PM, Richard S. Hall<heavy@ungoverned.org>
>>>   wrote:
>>>
>>>        
>>>> On 7/27/09 8:24 AM, David Savage wrote:
>>>>
>>>>          
>>>>> On Fri, Jul 24, 2009 at 11:23 PM, Richard S. Hall<heavy@ungoverned.org>
>>>>>   wrote:
>>>>>
>>>>>
>>>>>            
>>>>>> On 7/24/09 12:35 PM, David Savage wrote:
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> To lay my cards on the table, I kinda like resolve=compile as
it dove
>>>>>>> tails kinda neatly with resolution=optional, but equally it seems
>>>>>>> kinda bizarre to be adding another dimension to this whole problem
>>>>>>> when people are worried about the complexity of OSGi. If there
is a
>>>>>>> way to do this without exposing developers to it that would be
/great/
>>>>>>> but as with OSGi I don't think we should worry about doing the
right
>>>>>>> thing at the base layer IDE tools and other schemes can always
>>>>>>> simpilify this whole space down again to joe blogs. I guess it's
a
>>>>>>> question of what is "right".
>>>>>>>
>>>>>>> So I guess the end result of this email is, what are your thoughts?
>>>>>>>
>>>>>>> * Is resolve=compile a good idea?
>>>>>>> * Should it be resolution=compile?
>>>>>>> * Any other options?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> Isn't this some form of "uses" constraint? Middle exposes Top because
>>>>>> it
>>>>>> inherits from it, so if you follow transitive "uses" constraints
you
>>>>>> could
>>>>>> possibly assume that compile-time access is needed.
>>>>>>
>>>>>>
>>>>>>              
>>>>> Hmmm you're right it certainly resembles uses - should have spotted
>>>>> that myself. However I have a feeling it may get a bit hairy in
>>>>> certain edge cases, i.e. Top may not be in an exported package which
>>>>> could work at runtime I believe, as Middle would provide the class
>>>>> path to Top?
>>>>>
>>>>>
>>>>>            
>>>> I agree, it might not work in every case, but it seems like a good place
>>>> to
>>>> start. It seems in the general case, if a type is exposed, then someone
>>>> must
>>>> have a dependency on it or contain it somewhere in the transitive set of
>>>> dependencies, otherwise it couldn't be exposed...
>>>>
>>>>          
>>> I guess the only concern I have with this approach is making sure it
>>> doesn't get in the way of developers - i.e. the uses should be
>>> calculated by the tooling vs expecting the developers to manage this
>>> manually. Uses is a pretty nasty equation to calculate at runtime and
>>> in an IDE environment where devs are cutting/refactoring code I guess
>>> I'm just wary that it has the possibility to spin out of control and
>>> lock up the IDE. Also should be careful at implementation time to
>>> allow the calculation to be done in such a way as to allow caching so
>>> it doesn't grind the IDE to a halt.
>>>
>>>        
>> I worry about this during framework run time too! :-)
>>
>> That's why we need to devise a decent algorithm that doesn't do this and we
>> can share among our subprojects that require resolving.
>>      
>
> Yep that would certainly be very useful! One of the comments made
> during the sigil contribution was regarding building a resolver API
> that could be reused and implemented in different ways, either for
> research purposes or to allow for different behaviours - fast, logical
> error messages, extended semantics, etc. Maybe we could look at some
> combination of code from Felix, OBR and Sigil to form the basis of an
> API?
>
> The key parts of the sigil resolver (I think) are:
>
> * support for progress notifications (allows for UI analysis of resolutions)
> * pluggable repositories (i.e. sources of bundles - filesystem, obr, etc)
> * support for hierarchical repositories (allows developers to chose
> where they would "prefer" to resolve resources from)
>    

While all of this sounds good, I was more alluding the algorithm 
itself...the API is the easy part if we have an algorithm that is wicked 
fast. :-)

-> richard

> Regards,
>
> Dave
>
>    
>> ->  richard
>>
>>      
>>>>>>> * What to do about fragments?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>> I don't think the fragment issue should be handled, since that is
a
>>>>>> bogus
>>>>>> use case for fragments from my point of view. Fragments are intended
to
>>>>>> be
>>>>>> optional extensions to the host, but in this case the host is fibbing
>>>>>> about
>>>>>> its contents because it expects to have a fragment attached to it.
In
>>>>>> reality, the fragment should have the exports, not the host.
>>>>>>
>>>>>>
>>>>>>              
>>>>> Tend to agree it is a bogus scenario - if only it wasn't happening in
>>>>> one of the most used OSGi libraries available :( I guess Eclipse
>>>>> probably have a good reason for doing this - not sure what but I'll
>>>>> give them the benefit of the doubt.
>>>>>
>>>>>
>>>>>            
>>>> Regardless, it doesn't seem like a good idea to create whole new
>>>> mechanisms
>>>> to support improper use cases.
>>>>
>>>>          
>>> Agree in principle and I certainly want sigil to encourage best
>>> practice OSGi development. But in real world projects the edges are
>>> very rarely clean cut - so we need to provide migration paths at
>>> least. I'll push this out for the time being as I have a work around
>>> for fragments of this type - it's a bit messy but involves no new
>>> options on require bundle at least.
>>>
>>> Regards,
>>>
>>> Dave
>>>
>>>
>>>        
>>>> ->    richard
>>>>
>>>>
>>>>          
>>>>> I think I've figured out a way to work around it for the time being -
>>>>> which takes the pressure off from a sigil release point of view. I'll
>>>>> add the fragment to the ordinary classpath vs the OSGi filtered one,
>>>>> so I can at least compile against it without dragging in an external
>>>>> dependency at runtime. The danger with this approach is that unwary
>>>>> developers may link against a non exported package by mistake. Just
>>>>> wonder if there is a way to make this work without complicating the
>>>>> development model (or the sigil code) too much...
>>>>>
>>>>>
>>>>>
>>>>>            
>>>>>> ->      richard
>>>>>>
>>>>>>
>>>>>>
>>>>>>              
>>>>>>> * Is anyone still there (i.e. has this email lost you all?)?
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Dave
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>
>>>>>            

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message