Mike Milinkovich wrote:
If Eclipse would be willing to contribute to the
development of a unified OSGi platform within the ASF, that
could be one immediately viable approach.
Can you provide some more details regarding the creation of a unified OSGi
platform? What other projects (Knoplerfish?) are participating here? AFAIK,
there has been no attempt to interact with or invite Eclipse participation.
As I am sure you're aware, Eclipse's OSGi project already has a sizeable
product quality code base, community, and user group. Would it not make just
as much sense to bring your contributions to Eclipse as the other way
around? Or alternatively re-use the work that has already been done at
Eclipse?
Apache and Eclipse (and ObjectWeb for that matter) have a pretty good track
record at co-operating at many different levels. Why it would serve the
interests of Apache, Eclipse, ObjectWeb, OSGi or the greater open source
community to have directly competing projects is beyond me.
I did interact with Jeff, but you are right, it was certainly not "an
official invitation".
Anyway, I think it is time to write down what "interest of the OSGi
community" means, as it is being quoted in many emails. As OSGi is meant
to be a very flexible platform, it means different things to different
people.
Requirements according to application area:
-------------------------------------------
Eclipse Applications (IDE, Rich client):
- Software goals: Code Quality & Stability, Scalability to many
different bundles, startup/load times...
- Installation & Deployment: Eclipse Runtime
- Legal: Eclipes License code only?
Research & company internal development:
- Software goals: Code Quality & Stability, Architecture that makes
additions / modifications to spec straightforward.
- Installation & Deployment: Easy of use, easy to debug/develop,
complete and spec compliant framework.
- Legal: OSI-compliant license, not important
Product for embedded devices (gateways):
- Software goals: Code Quality & Stability, small footprint,
- Installation & Deployment: Complete and spec compliant framework, test
suites (quality and performance), distribution (e.g. knowledge that ALL
bundles to be used have been extensively tested and proven to work
together for a given OS), easy to get going
- Legal: BSD-style ideal
Apache Middleware
- ...
- Legal: ASL
Product for cell phones / PDAs:
- ...
Product for vehicles:
- ...
I am not claiming that this list is correct leaving alone complete, but
I think any open source OSGi effort should identify which of these
vertical application areas are targeted and what their requirements are.
Furthermore, to be "unified" an open source OSGi effort must have ways
to accommodate all of these vertical applications. And even if this is
not possible right now, getting as close to that as possible should
still be a goal.
While each of these application areas will need their own packaging
and/or distribution and/or tool set, it would be great if as much code
as possible is shared between them.
--
Tom Enderes