felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Compatibility claims (Was: Re: http.jetty based on Jetty 6)
Date Wed, 06 Feb 2008 16:32:33 GMT
Again, I am still unclear why there is this implicit acceptance among 
some to just assume that it makes sense for others to view our 
subprojects as tainted by our framework. However, rather than argue the 
merits of that, I would rather think about how to address it.

The only idea I have is two-fold:

   1. Make sure that all of our subprojects have their own web page on
      our site (not all do yet).
   2. Create some sort of simple template for each one to indicate on
      which frameworks it should work on and which it has been tested
      on. This could include mention of execution environment and/or JDK.

Perhaps we could create some pithy table showing the different 
concerns...even use some nice icons. :-) Then it would be clear to 
anyone going to any subproject whether it might be useful to them or not.

Anyone interested in proposing a design for such a table? Or have better 
ideas altogether?

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