felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff McAffer <j...@code9.com>
Subject Re: Compatibility claims (Was: Re: http.jetty based on Jetty 6)
Date Fri, 08 Feb 2008 13:38:13 GMT
Some random thoughts in random order...

- At some level the problem is similar to the 
Bundle-RequiredExecutionEnvironment problem. There are certain core 
framework implementation features that a bundle might need (e.g., 
fragments, buddy loading, ...) and the services that are required. 

- Note that the BREE is somewhat overloaded.  It is used to talk both 
about the language level features of a EE and the base class library.  
For example, people often think they need Java 5 because they want to 
use JMX (you can get JMX addons for Foundation 1.0). So in this context 
it is the same as people saying they need Felix/Equinox because they are 
using a service bundle that comes from that team.
The Import/Export-Service headers have been deprecated but perhaps they 
can be revived and enhanced for this use.

- having markup in OBR is cool but it would be good to make this 
independent somehow.  Not all provisioning systems are going to use OBR 
metadata.  One idea was to have info to be in the manifest  and then 
systems like OBR and p2 can extract and construct their metadata however 
they like.  much of this data is relevant to resolution so having it in 
the manifest is relevant.

- Somewhat aside, we have sound it useful for producers to spec 
intentions as well as reality.  This tells the community, for example, 
that we want this bundle to work on any framework but for now it only 
works on Felix.  This kind of info may not be in the manifest but its 
likely good to keep the usecase in mind when putting together the other 
infrastructure.

Like I said, random thoughts in random order...

Jeff

Karl Pauls wrote:
> On Feb 8, 2008 6:20 AM, Jeff McAffer <jeff@code9.com> wrote:
>   
>> We've been suffering from this "framework tainting" for quite sometime
>> now. Equinox ships many bundles/services that work on other frameworks
>> (as well as ones that work without OSGi at all!).  The Equinox community
>> (well at least me) would like to participate in figuring out a way to
>> depict or communicate the state or expectations of bundles.
>>
>> In my ideal world this information would be somehow included in or
>> associated with the bundles so that website tables could be
>> autogenerated and provisioning systems could filter accordingly.  I can
>> see a lot of issues in setting this up but also feel it is worthwhile to
>> do and to do in sort of common approach so the OSGi community gets a
>> consistent picture.
>>     
>
> Thats sounds like a very interesting idea. There is some data
> available already in the manifest of a bundle but adding a pointer to
> a standard documentation extension would be nice. Maybe we could make
> it something that could point to something inside the bundle or to a
> remote location (that way a bundle could come with or without it). It
> sounds like this could be potentially something that could be combined
> with OBR as well, no?
>
> regards,
>
> Karl
>
>   
>> Jeff
>>
>>
>> Richard S. Hall wrote:
>>     
>>> Stuart McCulloch wrote:
>>>       
>>>> also the subproject documentation that is there is (imho) not visible
>>>> enough
>>>> ( have to click Documentation->...um...->Subproject
>>>> Documentation->aha... )
>>>>
>>>> perhaps we could add a direct link to the subprojects page from the main
>>>> page?
>>>>
>>>>         
>>> Yes, something like that would be a good idea too. Our menu on the
>>> side is getting a little long, though, so perhaps there is some way to
>>> shorten it to make it more useful, e.g., grouping related items into a
>>> new page so that they only have one link in the menu.
>>>
>>>       
>>>> yes - a matrix of bundles against frameworks/EE would be really cool
>>>> and we
>>>> could perhaps find a way to display it on the main page (in reduced
>>>> form, so
>>>> it doesn't takeover the whole page, but shows our bundles can be used
>>>> with
>>>> many other frameworks)
>>>>
>>>> each sub-project page could have a banner at the top with specific
>>>> results
>>>>
>>>>         
>>> Yes, exactly my thinking.
>>>
>>>       
>>>> +1 for something like a matrix, but I'm no good at web-design ;)
>>>>
>>>>         
>>> Me either and currently lack any time.
>>>
>>> -> richard
>>>
>>>       
>>>> -> richard
>>>>
>>>>         
>>>>> Guillaume Nodet wrote:
>>>>>
>>>>>           
>>>>>> On Jan 15, 2008 8:32 PM, Richard S. Hall <heavy@ungoverned.org>
wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Further, I am not really certain about what is being said here.
This
>>>>>>> thread seems to imply that if we did "rm -rf framework" in our
trunk
>>>>>>> directory, then it would be possible for our bundles to be seen
as
>>>>>>> framework independent and good OSGi citizens. However, since
one
>>>>>>> of our
>>>>>>> subprojects happens to be a framework implementation, then all
of our
>>>>>>> subprojects are tainted and seen as "Felix-only"? Is that right?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> I think the situation is a bit more complicated.  We have the same
>>>>>>
>>>>>>             
>>>>> problems
>>>>>
>>>>>           
>>>>>> in ServiceMix where we have both a JBI container and JBI components.
>>>>>> I think users are tempted to assume that there is an implicit tie
>>>>>>
>>>>>>             
>>>>> between
>>>>>
>>>>>           
>>>>>> the runtime and the services provided.  OPS4j does not provide any
>>>>>> OSGi
>>>>>> runtime, thus, it easier to look at it as independent of the runtime.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>
>>>>
>>>>         
>
>
>
>   

Mime
View raw message