Enrique Rodriguez <[EMAIL PROTECTED]> wrote on 08/03/2005 08:28:41 PM:
> 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.
I agree that the process has merit. The fact that your proposal has
gained great interest is a strong endorsement of the need for Java
component models and OSGi. I guess I would have liked there to have been
less haste in setting it up and more openness to alternatives now that it
is incubating. But hey, what is, is.
> 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.
Yes, this is a common misconception. Frankly it is one that we have,
unfortunately, not done much to counter. The Eclipse Platform's move to
OSGi fell under a larger umbrella of work commonly known as "the Rich
Client Platform" (RCP). This is middleware for building applications
(i.e., not tooling). The work began just after Eclipse 2.1 (mid 2003) and
is, in effect, a factoring of what was the Eclipse IDE platform into the
part that is completely generic (the RCP) and the part that is specific to
IDEs and tooling. The net result is that there are many people using RCP
as middleware/runtime in a wide range of scenarios from embedded to
servers and domains from scientific experimentation to finance to
healthcare to... Check out
http://eclipsecon.org/2005/presentations/EclipseCon2005_RCP_plenary.pdf
for a recent presentation on the subject.
To further illustrate that Eclipse is a place for runtimes as well as
tooling I'll point out that it hosts projects such as AspectJ (runtime
aspect weaving for Java), ECF (secure, reliable messaging), Higgins
(identity management) and eRCP (Eclipse technology on embedded devices
such as cell phones). All of these are clearly focused on
middleware/infrastructure/runtimes.
The Eclipse 3.1 OSGi implementation is completely separate from the rest
of Eclipse. See
http://eclipse.org/osgi
for more information. As you point out, we have failed to publicize this
fact widely. The upcoming 3.2 plan includes an item to clarify and better
position the Eclipse OSGi implementation as independently consumable.
> 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.
This too is a common misconception. Its somewhat academic for this
discussion but let me clear it up anyway. The Eclipse team has
contributed significantly to OSGi.
- Several Eclipse committers are active participants in the OSGi Core
Platform Expert Group. This group, along with Richard, has been
instrumental in a large number of the framework changes in R4.
- The extended Eclipse team (i.e., non-committers working behind the
scenes) does everything from work on the OSGi reference implementation to
write the compliance test suites to putting the Eclipse OSGi in embedded
devices.
- Much of this work has nothing to do with tooling or Eclipse per se and
everything to do with making OSGi and our implementation the best it can
be.
So, there is no particular reason that an OSGi project at Eclipse (for
example) would be any less focussed on OSGi for OSGi's sake. We are
already behaving that way.
> 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.
Absolutely. And there are parts of the spec that no one at Apache will
use...
> 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."
Yes, you are looking in the wrong place. Equinox is an incubator for new
runtime technology for he Eclipse Platform. Two years ago it was the
place that we started the Eclipse on OSGi work. As of Dec 2003 the OSGi
work "graduated" and was moved into the main Eclipse project. Phase 2 of
Equinox then started about a year ago to investigate further OSGi
modularity changes (e.g., RFC70 and 79) among other things. Sometime late
last year that code also graduated and was absorbed into the main code
stream. http://eclipse.org/osgi indicates the forums for OSGi-related
interaction at eclipse.org. Note that the vast majority of the
development interaction happens in Bugzilla in the Platform/Runtime
component.
> I hope that wasn't antagonistic.
Fact is fact. We have done poorly at highlighting OSGi and facilitating
community development. This characteristic was noted at the World
Congress last year yet we still were distracted with all the R4 work etc.
As mentioned, the 3.2 plan calls for us to rectify the situation.
> 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.
The code and "community" moves were announced on several lists as the
events unfolded.
> 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.
I'll point out that Cocoon, for example, was burnt by Avalon, an Apache
project. Having the work at Apache is no guarantee. Of course, neither
is having it at eclipse.org. Having two is interesting if you can avoid
container-isms.
To summarize what turned out to be a quite long post (sorry 'bout that),
we are all for competition and collaboration and look forward to both.
Lets keep it respectful, factual and technical.
Jeff
