Mike Milinkovich wrote:
> 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.
Hi, Mike,
After writing the proposal, we were fortunate to gain Oscar as an
"anchor tenant" and quickly add close to 50 community supporters. But,
this project pretty much just consists of the proposal you read; we
don't have a formal plan for unifying the OSGi community. We certainly
didn't mean to slight Eclipse. After getting the proposal out, we now
rely on proven Apache processes for working out additional details.
Clearly this process has merit, as it has started this dialogue.
As for involving Knopflerfish, we launched into this proposal during a
thread on the Knopflerfish forums:
https://sourceforge.net/forum/forum.php?thread_id=1179740&forum_id=328005
As noted by KF users, there was a desire for an organization and better
infrastructure. We have discussed this with the major players at KF and
we'd love to have them more involved, but the incubator process picked
up before we could solidify anything.
> 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?
I don't understand what the interest of Eclipse is in supporting an OSGi
community. In other words, what is the business case? My lack of
understanding here comes from two things:
1) My perception of Eclipse involves "software tools," a "universal
tool platform," and an "open extensible IDE." OSGi is an implementation
detail of the Eclipse platform. Before you had a proprietary plug-in
technology, now you use OSGi. Eclipse ships with Apache Ant and Apache
Lucene. If we were to have a single OSGi project, it would make sense
to have it at Apache, where the focus would be on OSGi, for OSGi's sake.
As I'm sure you're aware, there is way more to OSGi than the core
framework, much of which Eclipse wouldn't use. And, as the proposal
states, we hope to support much more of the greater R4 specification.
2) While I agree Eclipse has a sizable community, this has been at a
higher-level than OSGi. Unless I'm subscribed to the wrong mailing
list, my perception of the Eclipse OSGi community is that it is "dead."
I point your attention to the equinox-dev mailing list, where traffic
is light, half the posts this year are on threads I personally started,
and the 1 post in July went unanswered:
http://dev.eclipse.org/mhonarc/lists/equinox-dev/maillist.html
I hope that wasn't antagonistic. Perhaps you have a new mailing list or
forum where R4 development is taking place in public and that just
wasn't announced to the equinox-dev list. My point is if you want a
community around OSGi you have to work at it. In my opinion, this is
the primary reason for having this project at Apache.
> 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. What are the
> inhibitors to Apache using or referencing the Eclipse implementation
and its
> related tooling (which itself is a significant piece of work)?
Well, as mentioned above, the primary inhibitor is the "talk vs. walk"
of supporting a community around OSGi. And, as mentioned by other
Apache projects, more so than with libraries, container alternatives are
desirable, since projects are going to heavily rely on them and they've
been burnt before.
Enrique
