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 <[EMAIL PROTECTED]> 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.
