Home » Eclipse Projects » Equinox » OSGi?
| OSGi? [message #1558] |
Sat, 22 February 2003 23:47  |
Eclipse User |
|
|
|
Originally posted by: ted.stockwell.acxiom.com
Hi All,
First, I think that Equinox is a very timely and needed effort.
When I read the description of what the Equinox project is intended to
deliver I immediately thought of OSGi (http://www.osgi.org for those not
familiar with it).
It seems to me that the OSGi specification already covers all of the desired
functionality in spades...
....Dynamic plug-ins - OSGi's got it. Bundles can be installed, loaded,
started, stopped, unloaded and uninstalled all without stopping the server.
....Component management - OSGi's got it. OSGi provides a facility for
controlling access to code based on who is trying to run the code. OSGi
doesn't have anything equivalent to extension-points and extensions but
Eclipse covers that.
....Dependency management - OSGi's got it. Dependencies are nicely managed
through manifest files. If I remember correctly there is also a way to
query for dependencies at runtime. This doesn't reduce dependency chains
but it provides a facility for managing them.
....Services model - OSGi's got it, big time. Interface based services.
Attribute based Service lookup, etc.
I can imagine an OSGi plugin for Eclipse that provides an OSGi compatibility
layer on top of the Eclipse core runtime. The OSGi plugin could define
extension points that enable plugins to register OSGi bundles with the OSGi
server. The OSGi plugin could also provide a GUI facility for managing OSGi
bundles. And of course the OSGi plugin would implement the core OSGi
interfaces. Strict compliance to the OSGi model could be abandoned when
convenient. For instance, I'll bet that it would be more convenient to
always wrap OSGi bundles in plugins and use the Eclipse Update facility
instead of implementing the standard OSGi update facility.
Once upon a time I built an open source OSGi 1.0 server,
http://servicetango.sf.net. I would be very excited about helping to build
such a compatibility layer for Eclipse.
Is there is any reason for not adopting OSGi as the solution to the problems
that you want to solve?
I think that you should immediately consider whether OSGi provides the
solution to the problems that you want to solve. Is so, then we can
immediately get to work to implement the solution!
ted stockwell
jlense.sf.net
|
|
|
| Re: OSGi? [message #1647 is a reply to message #1558] |
Mon, 24 February 2003 18:44  |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
"ted stockwell" <ted.stockwell@acxiom.com> wrote in message
news:b390gp$h5t$1@rogue.oti.com...
> Hi All,
>
> First, I think that Equinox is a very timely and needed effort.
Thanks, we think that too ! :-)
Several committers have intimate knowledge of OSGi.
It is a candidate, but it presents challenges... Eclipse and OSGi
have made different choices on core technical points such as
versioning, order of class loading, etc.
I personnally believe that it would be great to make both Eclipse
and OSGi evolve so that Equinox would open the way to define
the next specification of OSGi and that Eclipse could just leverage
OSGi platform is its foundation. That was my idea when pushing
for this technology project, but there is work to be done, on both
sides.
Best regards,
Olivier.
>
> When I read the description of what the Equinox project is intended to
> deliver I immediately thought of OSGi (http://www.osgi.org for those not
> familiar with it).
> It seems to me that the OSGi specification already covers all of the
desired
> functionality in spades...
>
> ...Dynamic plug-ins - OSGi's got it. Bundles can be installed, loaded,
> started, stopped, unloaded and uninstalled all without stopping the
server.
> ...Component management - OSGi's got it. OSGi provides a facility for
> controlling access to code based on who is trying to run the code. OSGi
> doesn't have anything equivalent to extension-points and extensions but
> Eclipse covers that.
> ...Dependency management - OSGi's got it. Dependencies are nicely
managed
> through manifest files. If I remember correctly there is also a way to
> query for dependencies at runtime. This doesn't reduce dependency chains
> but it provides a facility for managing them.
> ...Services model - OSGi's got it, big time. Interface based services.
> Attribute based Service lookup, etc.
>
> I can imagine an OSGi plugin for Eclipse that provides an OSGi
compatibility
> layer on top of the Eclipse core runtime. The OSGi plugin could define
> extension points that enable plugins to register OSGi bundles with the
OSGi
> server. The OSGi plugin could also provide a GUI facility for managing
OSGi
> bundles. And of course the OSGi plugin would implement the core OSGi
> interfaces. Strict compliance to the OSGi model could be abandoned when
> convenient. For instance, I'll bet that it would be more convenient to
> always wrap OSGi bundles in plugins and use the Eclipse Update facility
> instead of implementing the standard OSGi update facility.
>
> Once upon a time I built an open source OSGi 1.0 server,
> http://servicetango.sf.net. I would be very excited about helping to
build
> such a compatibility layer for Eclipse.
>
> Is there is any reason for not adopting OSGi as the solution to the
problems
> that you want to solve?
> I think that you should immediately consider whether OSGi provides the
> solution to the problems that you want to solve. Is so, then we can
> immediately get to work to implement the solution!
>
> ted stockwell
> jlense.sf.net
>
>
|
|
|
| Re: OSGi? --- Overview [message #1672 is a reply to message #1558] |
Mon, 24 February 2003 21:56 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Here is an overview of OSGi. It has no pretention to be complete, on the
contrary, it is focused on the core platform concepts and functionality.
Above the core platform, OSGi defines many services such as an HTTP service,
a servlet engine, a logging service, or more administrative services such as
configuration. I am not presenting those, for information, please go to
www.osgi.org and download the specification. The intent here is to provide a
concise description (I know, not so concise :-) that will help moving
forward our analysis of Equinox and understand where OSGi could prove very
usefull.
The Open Services Gateway Initiative is a standard body, which started as
defining a service gateway for broadband connection. The gateway, a Java
platform, sits in between a local network of devices and remote service
providers. The gateway, in a home or a car for e.g., is intended to run
added-value services by controlling local devices. For instance, one may
envision the ability to remotely control the heating system of a weekend
house or providing real-time driving directions in a car leveraging a GPS.
Indeed, the Hertz Never-Lost system would be a perfect example of a service
that an OSGi platform in a car could provide. Phone services such as
call-waiting, caller-ids, or conference calling are other examples if the
phone is perceived as a human-interface device sitting in front of a home
gateway at the end of a broadband connection.
OSGi is one of the most advanced specification I am aware of that turns a
Java Runtime Environment (J2SE or J2ME) into a shared Java platform for
network-deployed software components. OSGi specifies a framework, above a
JRE, that manages software components in the Java Virtual Machine (JVM)
through class loaders. The OSGi framework also provides a service-oriented
architecture, leveraging software components. OSGi is small... we are
talking 66 Java class files for the abstract implementation of the
specification, 89 Java class files for a concrete implementation of the
specification.
This 155 class files for quite a powerful framework for managing Java
software components. It is important to insist that OSGi focuses on the
intra-JVM life-cycle management of components. It does not specify how
software components shall be managed persistently on the local platform
(file system, flash memory, or others). To add a local management layer
under OSGi framework that is Eclipse compatible, we need to add about
another 50 class files. So in about 200 class files, we would be replacing
most of the org.eclipse.core.boot and org.eclipse.core.runtime plug-ins,
which constitutes the Eclipse platform layer. Only remains the plug-in
registry classes, which are specific to Eclipse model. The entire class
loading scheme would be delegated to OSGi.
Another important point, often misunderstood, is that OSGi does not specify
how components are downloaded. Again, OSGi specifies the life cycle in the
JVM of downloaded components, it does not specifies how these components are
downloaded. The framework includes a full local administration API for
allowing a local bundle to download and install other components. The usage
of this API is secured through special permissions. Actually, OSGi specifies
a secure platform through Java2 security.
Enough of what OSGi is not, and let's see what OSGi is. :-)
OSGi advocates a simple software component model, called bundles, as a
straight extension to Java. An OSGi bundle is the unit of deployment, a jar
file packaging Java class files and resources (bitmaps, icons, or data
files). A bundle may also contain native code as shared libraries such as
DLLs, which are described in the bundle manifest. OSGi does not specify how
bundles are downloaded onto the platform, but it defines the runtime
life-cycle management of bundles once they are downloaded. Bundles can be
installed or updated dynamically, while the framework is running and with
minimal disruption to already loaded components and running services.
The framework loads bundles in isolation, cleverly using Java class loaders.
Although bundles are by default isolated, bundles may export or import
packages as declared in their manifest. When exporting a package, a bundle
exports both the Java types and resources present in that package. The
corollary is that a bundle may import packages exported by other bundles.
Exported packages constitute a global name space for Java types and
resources, shared across all loaded bundles. If conflict should arise, i.e.
two bundles are exporting two versions of a same package, the OSGi platform
ensures that only the newest version of a package is visible in the global
name space. Regarding class and resource loading, the global name space
always over-rides the bundle-local name spaces.
A bundle defines an activator class, whose purpose is to install the bundle.
In other words, when the framework loads a bundle, it creates an instance of
the activator class, called the activator object. The framework first tries
to resolve the bundle, that is, satisfy its imports. In a resolved state, a
bundle is already making its exports available. A resolved bundle may be
activated, in which case the framework calls the start method on the bundle
activator object. That start method is supposed to carry the necessary
bundle-specific installation steps. In particular, it creates and registers
the services the bundle wants to export and may lookup for some services
provided by others. When the bundle needs to be unloaded, the framework
first revokes the services registered by that bundle, and then stops the
bundle by calling the stop method on the activator object.
OSGi also promotes a service framework that is built above bundles. A
service in OSGi is a Java object that implements one or more Java
interfaces, and/or extends a super class. OSGi advocates a strong separation
between the interfaces and the implementation. Services are registered in a
registry, provided by the OSGi platform. The registry provides an LDAP-like
naming space for services where a service can be associated with properties
|
|
|
| Eclipse - OSGi Comparison [message #1684 is a reply to message #1558] |
Mon, 24 February 2003 23:51 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
This posting is a first attemtp at comparing OSGi and Eclipse. I believe
that OSGi is a very interesting open standard to study for Equinox. However,
Eclipse and OSGi have taken different technology stances on some core
aspects of their platforms. This is certainly not to say that OSGi is not a
great candidate to look at.
One of the first advantages is to leverage an existing open standard rather
than reinventing the wheel. When Eclipse started, OSGi was also in its
infancy and therefore an unlikely choice. Since then, Eclipse and OSGi have
both evolved toward a surprising similarity, as we will discuss in the
following paragraphs. We therefore feel that Equinox above an OSGi platform
would create a much-needed synergy in the Java community.
Another advantage would be the separation of concerns between Java
components and plug-in specifics. If Equinox would be a plug-in container
above an OSGi foundation, an Equinox plug-in would be an OSGi bundle that
defines extensions or extension points. The Java imports and exports are
expressed within the bundle manifest. The extensions and the extension
points are expressed in the plugin.xml, as an extra manifest without the
"require" and the "runtime" tags.
It is interesting to point out that OSGi and Eclipse have taken two
different routes to control exports. An OSGi bundle specifies its exports as
a list of Java packages, all other packages are private. Eclipse by default
exports all Java packages from a plug-in but allows for a filter. I am not
sure one mechanism is essentially better technically. However, I always felt
that a full encapsulation as a default policy is better, forcing explicit
exports when needed.
Another difference between OSGi bundle and Eclipse plug-ins is the
encapsulation promoted by OSGi. OSGi promotes a strong separation between a
bundle interface and its implementation. Nothing really enforces it, except
for the default of private packages, forcing explicit exports. Also, it is
stressed all over the specification. Additionally, the service-oriented
paradigm helps to reinforce this. Eclipse tends to have a more permissive
approach.
One very important difference between OSGi and Eclipse is on dependencies.
OSGi expresses dependencies on imported packages (name and version), but not
on which bundle actually exports them. In other words, in OSGi, any set of
bundles can replace another set of bundles as long as the Java packages they
export are the same (name and version). In Eclipse, dependencies are
expressed on plug-ins. So Eclipse bounds plug-ins explicit together,
providing no separation between a plug-in API and its implementation.
Another interesting property of OSGi is its ability to support hot-code
updates. In other words, OSGi supports the dynamic loading/unloading of
plug-ins, with minimal impacts on the running platform. To my knowledge,
OSGi is one of the most advanced framework supporting dynamic
loading/updating/unloading of Java software components. This is clearly a
missing functionality in Eclipse.
This is an important point regarding how dependencies on expressed. In OSGi,
there is great freedom in updating or replacing bundles as long as the set
of exported packages remains the same. This is very interesting when doing
hot updates, where a new provider of a library or a service can be
substituted for the currently installed one. For instance, it would allow a
real player bundle to replace a windows player, assuming they both provide
the same API to play rich media. In Eclipse, this is not possible.
Because OSGi is often confused with an end-to-end deployment infrastructure,
it is often believed to conflict with Eclipse features. OSGi does not
conflict with the Eclipse features because OSGi does not specify a
deployment infrastructure at all, not even an update policy. As far as I
can tell, features, plug-ins, and fragments can all be managed above OSGi
bundles, leveraging the local administration API. A side efect of this is
that OSGi does not improve Eclipse management of feature-level dependencies
and feature management.
Here is another very interesting side effect of considering Equinox as a
plug-in container above an OSGi platform. By moving the update manager as a
administration-aware bundle, I believe we improve the overall robustness
regarding installing new software components or updating already installed
ones. Eclipse is somehow weak in resisting install failures since the update
manager depends on most of the platform to be able to come up... Not very
robust when the configuration is screwed up and needs repair, but Eclipse
can't come up and the update manager is therefore unavailable.
By decoupling the Java foundation for software components and the plug-in
container, one achieves less dependencies for the update manager. The update
manager moves down to the OSGi layer, being a regular bundle with
administrative permissions. As a bundle, the update manager could have
minimal dependencies for coming up. None if we consider a textual interface.
SWT only if we consider a more graphical interface. Another avenue would be
an HTTP daemon and a servlet engine for a remote web interface. OSGi
provides a very small footpring web application server suited for this.
This would allow to support most configuration failures. If an SWT interface
is supported, we can still integrate the update manager in the workbench,
but as an option, not a requirement. Even more severe configuration or
failures could be handled by reinstalling the platform as long as we can
remember the configuration across full re-installs (either locally or on a
server). Indeed, we can reinstall the core OSGi platform and installing back
the last configuration known to work.
Another aspect to discuss is the version model. Eclipse and OSGi have
adopted conflicting versioning model. OSGi is Java compliant, following the
Java versioning model. This means that OSGi imposes full backward compliance
between bundle versions. Eclipse on the contrary allows major releases of a
plug-in to break backward compatibility. This is undoubtly one of the major
differences between Eclipse and OSGi.
A more minor difference is that Eclipse may actually load multiple versions
on a library... leading to have different versions of the same packages
exported concurrently. Eclipse attempts quite complex matching between
exports and imports, which may lead to loading only an older version, only
the most recent one, or both. OSGi on the contrary ensures that the platform
will share only the latest version available of any exported Java package.
Notice that for most plug-ins, the ones declaring extensions or extension
points, Eclipse only loads one version and thereby follows the OSGi
behavior. Eclipse is therefore able to potentially satisfy more intricate
dependency situations.
Another minor difference is with the order for class loading. Eclipse class
loading allows local classes to shadow global shared classes. OSGi has
adopted a more robust approach where the global space of share classes
always prevails on local classes.
There are several other minor aspects that need to be discussed. One aspect
is about configuration data of software components. Another is about the
persistent data of software components. Another one is natural language
support.
One last important comment is regarding tooling. Adopting OSGi would require
to bring OSGi-awareness into JDT and PDE. We expect minimal impacts on JDT
but more important ones on PDE. But tooling biggest concern is certainly a
better support for self-hosting, OSGi bundles versus plug-ins is a minimal
issue.
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
|
|
|
| Re: OSGi? [message #2747 is a reply to message #1558] |
Tue, 25 February 2003 00:29 |
| Eclipse User |
|
|
|
Originally posted by: kduffey.marketron.com
Hell, why we are at it we should use my engine! It is similar to Eclipse,
only that it unloads, reloads, and handle dependency reloading, along with
the ability to look up plugins at runtime, activate them as needed, etc.
Plus, at its core including xml parser its only 50K or so. So it could be a
candidate for J2ME. I am confused, is this Equinox to be built on Eclipse? I
am not sure how OSGi comes into the picture if this project is to build upon
Eclipse. Seems to me OSGi and Eclipse are now vying for the same space. At
least my engine is completely generic for any purpose. :D It's not quite as
robust, but does pretty much the same thing.
"ted stockwell" <ted.stockwell@acxiom.com> wrote in message
news:b390gp$h5t$1@rogue.oti.com...
> Hi All,
>
> First, I think that Equinox is a very timely and needed effort.
>
> When I read the description of what the Equinox project is intended to
> deliver I immediately thought of OSGi (http://www.osgi.org for those not
> familiar with it).
> It seems to me that the OSGi specification already covers all of the
desired
> functionality in spades...
>
> ...Dynamic plug-ins - OSGi's got it. Bundles can be installed, loaded,
> started, stopped, unloaded and uninstalled all without stopping the
server.
> ...Component management - OSGi's got it. OSGi provides a facility for
> controlling access to code based on who is trying to run the code. OSGi
> doesn't have anything equivalent to extension-points and extensions but
> Eclipse covers that.
> ...Dependency management - OSGi's got it. Dependencies are nicely
managed
> through manifest files. If I remember correctly there is also a way to
> query for dependencies at runtime. This doesn't reduce dependency chains
> but it provides a facility for managing them.
> ...Services model - OSGi's got it, big time. Interface based services.
> Attribute based Service lookup, etc.
>
> I can imagine an OSGi plugin for Eclipse that provides an OSGi
compatibility
> layer on top of the Eclipse core runtime. The OSGi plugin could define
> extension points that enable plugins to register OSGi bundles with the
OSGi
> server. The OSGi plugin could also provide a GUI facility for managing
OSGi
> bundles. And of course the OSGi plugin would implement the core OSGi
> interfaces. Strict compliance to the OSGi model could be abandoned when
> convenient. For instance, I'll bet that it would be more convenient to
> always wrap OSGi bundles in plugins and use the Eclipse Update facility
> instead of implementing the standard OSGi update facility.
>
> Once upon a time I built an open source OSGi 1.0 server,
> http://servicetango.sf.net. I would be very excited about helping to
build
> such a compatibility layer for Eclipse.
>
> Is there is any reason for not adopting OSGi as the solution to the
problems
> that you want to solve?
> I think that you should immediately consider whether OSGi provides the
> solution to the problems that you want to solve. Is so, then we can
> immediately get to work to implement the solution!
>
> ted stockwell
> jlense.sf.net
>
>
|
|
|
| Re: OSGi? --- Overview [message #2768 is a reply to message #1672] |
Tue, 25 February 2003 03:10 |
| Eclipse User |
|
|
|
Originally posted by: pascal_rapicault.yahoo.fr
Be careful communicating about Equinox:
There is no intent to do an equinox plugin (as far as Jeff told me).
We also want to avoid any branching from Eclipse.
From the website:
"The Equinox project is primarily meant as an incubator for the Eclipse
platform project. While the platform team is under no obligation to accept
changes proposed by Equinox, the intention is that members of the platform
team be involved in Equinox and that the models, mechanisms and
implementations developed be immediately and obviously beneficial to the
platform"
PaScaL
"Olivier Gruber" <ogruber@us.ibm.com> a
|
|
|
| Re: Eclipse - OSGi Comparison [message #2786 is a reply to message #1684] |
Tue, 25 February 2003 03:37 |
| Eclipse User |
|
|
|
Originally posted by: ted.stockwell.acxiom.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b3e9b2$frb$1@rogue.oti.com...
>
> One of the first advantages is to leverage an existing open standard
rather
> than reinventing the wheel. When Eclipse started, OSGi was also in its
> infancy and therefore an unlikely choice. Since then, Eclipse and OSGi
have
> both evolved toward a surprising similarity, as we will discuss in the
> following paragraphs. We therefore feel that Equinox above an OSGi
platform
> would create a much-needed synergy in the Java community.
>
Ditto this.
As you have pointed out in your other posts, there are differences between
how Eclipse and OSGi export/import packages, how they load plugins/bundles,
etc. Do you have a feel for how significant these differences really are?
I suspect that most plugins could easily be ported to bundles and the
differences in platform semantics would be easily resolved. Also, the
plugin container that you envision could probably hide most of the
differences from plugins.
I think that supporting OSGi would buy Equinox an instant community of
supporters.
>
> Another advantage would be the separation of concerns between Java
> components and plug-in specifics. If Equinox would be a plug-in container
> above an OSGi foundation, an Equinox plug-in would be an OSGi bundle that
> defines extensions or extension points. The Java imports and exports are
> expressed within the bundle manifest. The extensions and the extension
> points are expressed in the plugin.xml, as an extra manifest without the
> "require" and the "runtime" tags.
>
I have read your other posts. I think the idea of an OSGi-based 'Java
layer' that can install/update bundles is very well reasoned and right on
target. OSGi definitely needs the update facility that Eclipse can provide
and OSGi would improve the 'self hosting' story in Eclipse.
I think the idea of a plugin container bundle is another good idea.
How about workspaces? I see the Eclipse workspace API as belonging to the
plugin container. The workspace API may be implementable on top of the OSGi
Persistent Storage Facility.
>
> It is interesting to point out that OSGi and Eclipse have taken two
> different routes to control exports. An OSGi bundle specifies its exports
as
> a list of Java packages, all other packages are private. Eclipse by
default
> exports all Java packages from a plug-in but allows for a filter. I am not
> sure one mechanism is essentially better technically. However, I always
felt
> that a full encapsulation as a default policy is better, forcing explicit
> exports when needed.
>
Another difference between OSGi and Eclipse is that OSGi bundles can export
packages to other bundles and those packages will be available to other
bundles even if the other bundles do not explicitly import the packages. I
have found that low level plugins absolutely need this capability (like
plugins that are responsible for deserializing objects coming in on the
wire, those plugins will need to basically import almost every other plugin,
it's nasty).
ted stockwell
|
|
|
| Re: OSGi? [message #2802 is a reply to message #2747] |
Tue, 25 February 2003 04:14 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Kevin,
Sounds interesting. Don't tease. Tell us more.
As for Equinox's relationship to Eclipse... Equinox is more of a place than
a thing. It is a place for people to experiment with changes to Eclipse
that help Eclipse accomodate more usecases. The particular issue being
discussed here is using a standard Java component management framework
(e.g., OSGi) to handle the runtime aspects of Eclipse.
Jeff
"Kevin" <kduffey@marketron.com> wrote in message
news:b3ebmg$h2t$1@rogue.oti.com...
> Hell, why we are at it we should use my engine! It is similar to Eclipse,
> only that it unloads, reloads, and handle dependency reloading, along with
> the ability to look up plugins at runtime, activate them as needed, etc.
> Plus, at its core including xml parser its only 50K or so. So it could be
a
> candidate for J2ME. I am confused, is this Equinox to be built on Eclipse?
I
> am not sure how OSGi comes into the picture if this project is to build
upon
> Eclipse. Seems to me OSGi and Eclipse are now vying for the same space. At
> least my engine is completely generic for any purpose. :D It's not quite
as
> robust, but does pretty much the same thing.
>
>
> "ted stockwell" <ted.stockwell@acxiom.com> wrote in message
> news:b390gp$h5t$1@rogue.oti.com...
> > Hi All,
> >
> > First, I think that Equinox is a very timely and needed effort.
> >
> > When I read the description of what the Equinox project is intended to
> > deliver I immediately thought of OSGi (http://www.osgi.org for those not
> > familiar with it).
> > It seems to me that the OSGi specification already covers all of the
> desired
> > functionality in spades...
> >
> > ...Dynamic plug-ins - OSGi's got it. Bundles can be installed, loaded,
> > started, stopped, unloaded and uninstalled all without stopping the
> server.
> > ...Component management - OSGi's got it. OSGi provides a facility for
> > controlling access to code based on who is trying to run the code. OSGi
> > doesn't have anything equivalent to extension-points and extensions but
> > Eclipse covers that.
> > ...Dependency management - OSGi's got it. Dependencies are nicely
> managed
> > through manifest files. If I remember correctly there is also a way to
> > query for dependencies at runtime. This doesn't reduce dependency
chains
> > but it provides a facility for managing them.
> > ...Services model - OSGi's got it, big time. Interface based services.
> > Attribute based Service lookup, etc.
> >
> > I can imagine an OSGi plugin for Eclipse that provides an OSGi
> compatibility
> > layer on top of the Eclipse core runtime. The OSGi plugin could define
> > extension points that enable plugins to register OSGi bundles with the
> OSGi
> > server. The OSGi plugin could also provide a GUI facility for managing
> OSGi
> > bundles. And of course the OSGi plugin would implement the core OSGi
> > interfaces. Strict compliance to the OSGi model could be abandoned when
> > convenient. For instance, I'll bet that it would be more convenient to
> > always wrap OSGi bundles in plugins and use the Eclipse Update facility
> > instead of implementing the standard OSGi update facility.
> >
> > Once upon a time I built an open source OSGi 1.0 server,
> > http://servicetango.sf.net. I would be very excited about helping to
> build
> > such a compatibility layer for Eclipse.
> >
> > Is there is any reason for not adopting OSGi as the solution to the
> problems
> > that you want to solve?
> > I think that you should immediately consider whether OSGi provides the
> > solution to the problems that you want to solve. Is so, then we can
> > immediately get to work to implement the solution!
> >
> > ted stockwell
> > jlense.sf.net
> >
> >
>
>
|
|
|
| Re: Eclipse - OSGi Comparison [message #2820 is a reply to message #1684] |
Tue, 25 February 2003 04:14 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Some points of clarification:
- Eclipse plugin code is private by default. The following extract from the
doc:
"Each <library> element can specify which portion of the library should be
exported. The export rules are specified as a set of export masks. By
default (no export rules specified), the library is considered to be
private. "
It just happens that most people export "*". That was their explicit choice
however.
- OSGi's encapsulation is not (to my understanding) stronger than that of
Eclipse. For example, most of the core resources plugin's API is spec'd
with interfaces. The implementation is almost completely separated. Again,
this was a design choice the plugin developers made. It was not forced on
them by the infrastructure. SWT would be much worse off if they were forced
to write interfaces for everything. What you can't do natively in Eclipse
is "substitute" implementations using some sort of service mechanism. The
OSGi service model and Eclipse extension/extension-point model are different
and complementary.
- The fragility of the Eclipse update story is a bit of a red herring. You
could easily see the Eclipse "plugin container" as being Runtime + Update
Core rather than OSGi bundles. These two plugins do the bulk of the plugin
management. In the same way as you would have a textual/minimal
graphics/HTTP UI for OSGi to manage bundles in a faulty install, such an
interface could be implemented on Eclipse to manage faulty plugins/features.
You are not pointing out an inherent flaw but rather a missing usecase. Is
this sort of facility part of standard OSGi implementations? Since OSGi
does not spec much about install/update, its unclear how it particularly
helps in this situation.
- totally minor nit: "self-hosting" already means something in the Eclipse
community (i.e., running an Eclipse target from an Eclipse development
workspace). Using that same term in this context will be confusing for
people.
- Finally, I must re-emphasize Pascal's comments. I'm not entirely sure how
to talk about the things that we produce (especially if they are new) but do
believe it is confusing and misleading to call them Equinox. Further, there
are several aspects to the project.
Jeff
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b3e9b2$frb$1@rogue.oti.com...
> This posting is a first attemtp at comparing OSGi and Eclipse. I believe
> that OSGi is a very interesting open standard to study for Equinox.
However,
> Eclipse and OSGi have taken different technology stances on some core
> aspects of their platforms. This is certainly not to say that OSGi is not
a
> great candidate to look at.
>
> One of the first advantages is to leverage an existing open standard
rather
> than reinventing the wheel. When Eclipse started, OSGi was also in its
> infancy and therefore an unlikely choice. Since then, Eclipse and OSGi
have
> both evolved toward a surprising similarity, as we will discuss in the
> following paragraphs. We therefore feel that Equinox above an OSGi
platform
> would create a much-needed synergy in the Java community.
>
> Another advantage would be the separation of concerns between Java
> components and plug-in specifics. If Equinox would be a plug-in container
> above an OSGi foundation, an Equinox plug-in would be an OSGi bundle that
> defines extensions or extension points. The Java imports and exports are
> expressed within the bundle manifest. The extensions and the extension
> points are expressed in the plugin.xml, as an extra manifest without the
> "require" and the "runtime" tags.
>
> It is interesting to point out that OSGi and Eclipse have taken two
> different routes to control exports. An OSGi bundle specifies its exports
as
> a list of Java packages, all other packages are private. Eclipse by
default
> exports all Java packages from a plug-in but allows for a filter. I am not
> sure one mechanism is essentially better technically. However, I always
felt
> that a full encapsulation as a default policy is better, forcing explicit
> exports when needed.
>
> Another difference between OSGi bundle and Eclipse plug-ins is the
> encapsulation promoted by OSGi. OSGi promotes a strong separation between
a
> bundle interface and its implementation. Nothing really enforces it,
except
> for the default of private packages, forcing explicit exports. Also, it is
> stressed all over the specification. Additionally, the service-oriented
> paradigm helps to reinforce this. Eclipse tends to have a more permissive
> approach.
>
> One very important difference between OSGi and Eclipse is on dependencies.
> OSGi expresses dependencies on imported packages (name and version), but
not
> on which bundle actually exports them. In other words, in OSGi, any set of
> bundles can replace another set of bundles as long as the Java packages
they
> export are the same (name and version). In Eclipse, dependencies are
> expressed on plug-ins. So Eclipse bounds plug-ins explicit together,
> providing no separation between a plug-in API and its implementation.
>
> Another interesting property of OSGi is its ability to support hot-code
> updates. In other words, OSGi supports the dynamic loading/unloading of
> plug-ins, with minimal impacts on the running platform. To my knowledge,
> OSGi is one of the most advanced framework supporting dynamic
> loading/updating/unloading of Java software components. This is clearly a
> missing functionality in Eclipse.
>
> This is an important point regarding how dependencies on expressed. In
OSGi,
> there is great freedom in updating or replacing bundles as long as the set
> of exported packages remains the same. This is very interesting when doing
> hot updates, where a new provider of a library or a service can be
> substituted for the currently installed one. For instance, it would allow
a
> real player bundle to replace a windows player, assuming they both provide
> the same API to play rich media. In Eclipse, this is not possible.
>
> Because OSGi is often confused with an end-to-end deployment
infrastructure,
> it is often believed to conflict with Eclipse features. OSGi does not
> conflict with the Eclipse features because OSGi does not specify a
> deployment infrastructure at all, not even an update policy. As far as I
> can tell, features, plug-ins, and fragments can all be managed above OSGi
> bundles, leveraging the local administration API. A side efect of this is
> that OSGi does not improve Eclipse management of feature-level
dependencies
> and feature management.
>
> Here is another very interesting side effect of considering Equinox as a
> plug-in container above an OSGi platform. By moving the update manager as
a
> administration-aware bundle, I believe we improve the overall robustness
> regarding installing new software components or updating already installed
> ones. Eclipse is somehow weak in resisting install failures since the
update
> manager depends on most of the platform to be able to come up... Not very
> robust when the configuration is screwed up and needs repair, but Eclipse
> can't come up and the update manager is therefore unavailable.
>
> By decoupling the Java foundation for software components and the plug-in
> container, one achieves less dependencies for the update manager. The
update
> manager moves down to the OSGi layer, being a regular bundle with
> administrative permissions. As a bundle, the update manager could have
> minimal dependencies for coming up. None if we consider a textual
interface.
> SWT only if we consider a more graphical interface. Another avenue would
be
> an HTTP daemon and a servlet engine for a remote web interface. OSGi
> provides a very small footpring web application server suited for this.
>
> This would allow to support most configuration failures. If an SWT
interface
> is supported, we can still integrate the update manager in the workbench,
> but as an option, not a requirement. Even more severe configuration or
> failures could be handled by reinstalling the platform as long as we can
> remember the configuration across full re-installs (either locally or on a
> server). Indeed, we can reinstall the core OSGi platform and installing
back
> the last configuration known to work.
>
> Another aspect to discuss is the version model. Eclipse and OSGi have
> adopted conflicting versioning model. OSGi is Java compliant, following
the
> Java versioning model. This means that OSGi imposes full backward
compliance
> between bundle versions. Eclipse on the contrary allows major releases of
a
> plug-in to break backward compatibility. This is undoubtly one of the
major
> differences between Eclipse and OSGi.
>
> A more minor difference is that Eclipse may actually load multiple
versions
> on a library... leading to have different versions of the same packages
> exported concurrently. Eclipse attempts quite complex matching between
> exports and imports, which may lead to loading only an older version, only
> the most recent one, or both. OSGi on the contrary ensures that the
platform
> will share only the latest version available of any exported Java package.
> Notice that for most plug-ins, the ones declaring extensions or extension
> points, Eclipse only loads one version and thereby follows the OSGi
> behavior. Eclipse is therefore able to potentially satisfy more intricate
> dependency situations.
>
> Another minor difference is with the order for class loading. Eclipse
class
> loading allows local classes to shadow global shared classes. OSGi has
> adopted a more robust approach where the global space of share classes
> always prevails on local classes.
>
> There are several other minor aspects that need to be discussed. One
aspect
> is about configuration data of software components. Another is about the
> persistent data of software components. Another one is natural language
> support.
>
> One last important comment is regarding tooling. Adopting OSGi would
require
> to bring OSGi-awareness into JDT and PDE. We expect minimal impacts on JDT
> but more important ones on PDE. But tooling biggest concern is certainly a
> better support for self-hosting, OSGi bundles versus plug-ins is a minimal
> issue.
>
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
>
>
>
|
|
|
| Re: Eclipse - OSGi Comparison [message #2837 is a reply to message #2786] |
Tue, 25 February 2003 04:17 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Ted,
I don't see that one. Eclipse can reexport plugins (the UI plugin reexports
SWT for example).
Jeff
"ted stockwell" <ted.stockwell@acxiom.com> wrote in message
news:b3emn8$n8r$1@rogue.oti.com...
>
> Another difference between OSGi and Eclipse is that OSGi bundles can
export
> packages to other bundles and those packages will be available to other
> bundles even if the other bundles do not explicitly import the packages.
I
> have found that low level plugins absolutely need this capability (like
> plugins that are responsible for deserializing objects coming in on the
> wire, those plugins will need to basically import almost every other
plugin,
> it's nasty).
>
>
> ted stockwell
>
>
|
|
|
| Classloading in Eclipse (was: Eclipse - OSGi Comparison) [message #2855 is a reply to message #2837] |
Tue, 25 February 2003 11:16 |
| Eclipse User |
|
|
|
Originally posted by: ted.stockwell.acxiom.com
Y'know, I went back and read the OSGi spec and I think that I have always
misinterpreted how exports should behave in OSGi.
So, let me give you the details of a problem I had developing a J2EE client
application in Eclipse. I have never been able to resolve this problem in a
satisfactory way in Eclipse, it would be good if Equinox had some good way
to deal with it.
My client application talks to an EJB session bean. The signature of the
session bean is something like this:
public interface GeneralLedgerService implements Remote {
Account getAccount(String accountId) throws RemoteException;
}
The session bean is hosted in an instance of JBoss. On the client side I
have a plugin, org.jboss.client, that wraps the JBoss client libraries. The
JBoss client libraries are basically responsible for marshalling calls to
EJB beans and unmarshalling the results. The client libraries also
propagate the Transaction and Security contexts to the server.
When a plugin on the client side calls the GeneralLedgerService.getAccount
method eventually the org.jboss.client plugin must marshal the account id,
invoke the remote getAccount method, and then deserialize the returned
Account object. However, if the org.jboss.client plugin doesn't have access
to the Account class then it will throw a NoClassDefFoundError. So, in
order to function the org.jboss.client must basically import packages from
all plugins that want to use it. Nasty.
I suppose I could have configured my client application to load classes from
server but then I figured that I would get ClassCastExceptions when
instances loaded by the org.jboss.client plugin were returned to other
plugins (since the other plugins would be loading GeneralLedgerService from
elsewhere).
--------------------------------------------
Meanwhile, since I didn't want to actually add all those imports to the
org.jboss.client plugin, I hacked the Eclipse plugin classloader as
follows...
....All my plugins explicitly export all thier packages.
....When a plugin classloader is looking for a class it first looks in all
the plugins explicitly imported by the plugin. If the class is not found
then it starts looking through the plugins that were not explicitly imported
for a matching package in the list of exported packages from the other
plugins. If a match is found then the class is loaded from the other plugin
even though it was not explicitly imported.
ted
|
|
|
| Re: Classloading in Eclipse (was: Eclipse - OSGi Comparison) [message #2890 is a reply to message #2855] |
Tue, 25 February 2003 14:22 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Ted, Jeff,
First a clarification... an OSGi bundle has to import a package in order
to see the exported classes. Otherwise, you will get an exception class not
found.
However, OSGi supports a dynamic import... where a bundle manifest
could specify package name prefixes for dynamic lookup.
So for instance, a bundle may specify that it wants to dynamically import
org.eclipse.*
which will allow the runtime to dynamically lookup for
any exported package org.eclipse.* when it needs to resolve a class
with a prefix of org.eclipse.
The * prefix is also supported where it means any package.
So I believe that it would do what you want Ted.
Cheers,
Olivier.
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"ted stockwell" <ted.stockwell@acxiom.com> wrote in message
news:b3fhja$ad0$1@rogue.oti.com...
> Y'know, I went back and read the OSGi spec and I think that I have always
> misinterpreted how exports should behave in OSGi.
>
> So, let me give you the details of a problem I had developing a J2EE
client
> application in Eclipse. I have never been able to resolve this problem in
a
> satisfactory way in Eclipse, it would be good if Equinox had some good way
> to deal with it.
>
> My client application talks to an EJB session bean. The signature of the
> session bean is something like this:
> public interface GeneralLedgerService implements Remote {
> Account getAccount(String accountId) throws RemoteException;
> }
> The session bean is hosted in an instance of JBoss. On the client side I
> have a plugin, org.jboss.client, that wraps the JBoss client libraries.
The
> JBoss client libraries are basically responsible for marshalling calls to
> EJB beans and unmarshalling the results. The client libraries also
> propagate the Transaction and Security contexts to the server.
>
> When a plugin on the client side calls the GeneralLedgerService.getAccount
> method eventually the org.jboss.client plugin must marshal the account id,
> invoke the remote getAccount method, and then deserialize the returned
> Account object. However, if the org.jboss.client plugin doesn't have
access
> to the Account class then it will throw a NoClassDefFoundError. So, in
> order to function the org.jboss.client must basically import packages from
> all plugins that want to use it. Nasty.
>
> I suppose I could have configured my client application to load classes
from
> server but then I figured that I would get ClassCastExceptions when
> instances loaded by the org.jboss.client plugin were returned to other
> plugins (since the other plugins would be loading GeneralLedgerService
from
> elsewhere).
>
> --------------------------------------------
>
> Meanwhile, since I didn't want to actually add all those imports to the
> org.jboss.client plugin, I hacked the Eclipse plugin classloader as
> follows...
>
> ...All my plugins explicitly export all thier packages.
>
> ...When a plugin classloader is looking for a class it first looks in all
> the plugins explicitly imported by the plugin. If the class is not found
> then it starts looking through the plugins that were not explicitly
imported
> for a matching package in the list of exported packages from the other
> plugins. If a match is found then the class is loaded from the other
plugin
> even though it was not explicitly imported.
>
>
> ted
>
>
|
|
| |
| Re: Eclipse - OSGi Comparison [message #2945 is a reply to message #2820] |
Tue, 25 February 2003 15:20 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
My technical comments below...
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b3eos6$o7t$1@rogue.oti.com...
> Some points of clarification:
>
> - Eclipse plugin code is private by default. The following extract from
the
> doc:
> "Each <library> element can specify which portion of the library should be
> exported. The export rules are specified as a set of export masks. By
> default (no export rules specified), the library is considered to be
> private. "
>
> It just happens that most people export "*". That was their explicit
choice
> however.
>
That sounds good, just a different way to achieve the same thing.
However, it seems to work in the packaged form of plug-ins...
when classes are loaded from jar files.
Does it work the same in development mode where classes are loaded
from the "bin" directory?
> - OSGi's encapsulation is not (to my understanding) stronger than that of
> Eclipse. For example, most of the core resources plugin's API is spec'd
> with interfaces. The implementation is almost completely separated.
Again,
> this was a design choice the plugin developers made. It was not forced on
> them by the infrastructure. SWT would be much worse off if they were
> forced to write interfaces for everything. What you can't do natively in
> Eclipse is "substitute" implementations using some sort of service
mechanism. The
> OSGi service model and Eclipse extension/extension-point model are
different
> and complementary.
They are different and complementary agreed.
But you are missing the point about interfaces and implementations.
I must have been unclear.
This is NOT about forcing the use of Java interfaces only.
SWT would not be implemented differently in OSGi than it
is in Eclipse. You can export/import any regular Java package
in OSGi, with classes and interfaces---nothing forces you to
do strictly Java interfaces.
I used the term interface in the software engineering sense,
so in that sense, I agree, there is no contradiction with Eclipse.
At least in its ability to export/import Java packages, especially
with you correction about export filters. Thanks :-)
However, remains a question. For the independence between
interfaces and implementations to be usefull, one needs to be able
to replace one implementation with another. This is where I don't
think Eclipse is going the right direction.
The main issue is that dependencies are on plug-ins.... therefore
not on the interface part but on the provider of an implementation.
This is true for the Java-level imports and exports (the require in
the plugin.xml). Consequently, this also applies to extensions and
extension points that require importing Java classes. Agreed not
all of them do, but many do.
This is where OSGi advocates clearly a separation. The idea is
that the API packages are clearly separated from the implementation.
The goal is that other bundles could provide those packages
with an alternative implementation. The core issue is that
dependencies are through import/export declarations,
not through requiring bundles. Thereby, the runtime is able to do
the matching between available exporters and importers.
This is a huge difference right there.
For instance, I can't provide in Eclipse another implementation of
SWT that would be compatible in some other plug-in because
the dependencies are on OTI SWT plug-in. The same applies
for the workbench, the resource plug-in, etc... This has nothing
to do with using Java interfaces. It has to do to have proper
separation between exported packages and private ones,
and expressing dependencies at the proper level: the public interface.
Sorry if my usage of the word interface was misleading, I probably
should have used the term API.
>
> - The fragility of the Eclipse update story is a bit of a red herring.
You
> could easily see the Eclipse "plugin container" as being Runtime + Update
> Core rather than OSGi bundles. These two plugins do the bulk of the
plugin
> management. In the same way as you would have a textual/minimal
> graphics/HTTP UI for OSGi to manage bundles in a faulty install, such an
> interface could be implemented on Eclipse to manage faulty
plugins/features.
> You are not pointing out an inherent flaw but rather a missing usecase.
Is
> this sort of facility part of standard OSGi implementations? Since OSGi
> does not spec much about install/update, its unclear how it particularly
> helps in this situation.
>
> - totally minor nit: "self-hosting" already means something in the
Eclipse
> community (i.e., running an Eclipse target from an Eclipse development
> workspace). Using that same term in this context will be confusing for
> people.
I don't agree here.
Eclipse has simply got self-hosting partially, more accurately,
Eclipse has self-hosting fragmented. One team looks at the
development aspects of it (PDE) and another looks at deployment
aspects (update manager and web sites)... But from a developer
and end user point of view, I am interested to have a seamless
and coherent life cycle for plug-ins across the development and
deployment phase. I don't see it being the case today.
As I pointed out, deploying plug-ins from a host Eclipse down
to a target Eclipse is only one aspect of self-hosting. Indeed,
these same plug-ins are then packaged in features by the same
PDE, published by the same PDE, and then deployed through
the update manager. And by the way, PDE also relies on
the update manager to install features so that they would provide
external plug-ins to the build proces...
So how is my definition of self-hosting different... I don't believe
it is... it just putting the different facets of self-hosting in perspective
in one global picture. It is just that currently Eclipse seems to have
the different facets of the life-cycle management designed
independently. It is confusing, at least to me :-)
>
> - Finally, I must re-emphasize Pascal's comments. I'm not entirely sure
how
> to talk about the things that we produce (especially if they are new) but
do
> believe it is confusing and misleading to call them Equinox. Further,
there
> are several aspects to the project.
>
> Jeff
>
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b3e9b2$frb$1@rogue.oti.com...
>
> > This posting is a first attemtp at comparing OSGi and Eclipse. I believe
> > that OSGi is a very interesting open standard to study for Equinox.
> However,
> > Eclipse and OSGi have taken different technology stances on some core
> > aspects of their platforms. This is certainly not to say that OSGi is
not
> a
> > great candidate to look at.
> >
> > One of the first advantages is to leverage an existing open standard
> rather
> > than reinventing the wheel. When Eclipse started, OSGi was also in its
> > infancy and therefore an unlikely choice. Since then, Eclipse and OSGi
> have
> > both evolved toward a surprising similarity, as we will discuss in the
> > following paragraphs. We therefore feel that Equinox above an OSGi
> platform
> > would create a much-needed synergy in the Java community.
> >
> > Another advantage would be the separation of concerns between Java
> > components and plug-in specifics. If Equinox would be a plug-in
container
> > above an OSGi foundation, an Equinox plug-in would be an OSGi bundle
that
> > defines extensions or extension points. The Java imports and exports are
> > expressed within the bundle manifest. The extensions and the extension
> > points are expressed in the plugin.xml, as an extra manifest without the
> > "require" and the "runtime" tags.
> >
> > It is interesting to point out that OSGi and Eclipse have taken two
> > different routes to control exports. An OSGi bundle specifies its
exports
> as
> > a list of Java packages, all other packages are private. Eclipse by
> default
> > exports all Java packages from a plug-in but allows for a filter. I am
not
> > sure one mechanism is essentially better technically. However, I always
> felt
> > that a full encapsulation as a default policy is better, forcing
explicit
> > exports when needed.
> >
> > Another difference between OSGi bundle and Eclipse plug-ins is the
> > encapsulation promoted by OSGi. OSGi promotes a strong separation
between
> a
> > bundle interface and its implementation. Nothing really enforces it,
> except
> > for the default of private packages, forcing explicit exports. Also, it
is
> > stressed all over the specification. Additionally, the service-oriented
> > paradigm helps to reinforce this. Eclipse tends to have a more
permissive
> > approach.
> >
> > One very important difference between OSGi and Eclipse is on
dependencies.
> > OSGi expresses dependencies on imported packages (name and version), but
> not
> > on which bundle actually exports them. In other words, in OSGi, any set
of
> > bundles can replace another set of bundles as long as the Java packages
> they
> > export are the same (name and version). In Eclipse, dependencies are
> > expressed on plug-ins. So Eclipse bounds plug-ins explicit together,
> > providing no separation between a plug-in API and its implementation.
> >
> > Another interesting property of OSGi is its ability to support hot-code
> > updates. In other words, OSGi supports the dynamic loading/unloading of
> > plug-ins, with minimal impacts on the running platform. To my knowledge,
> > OSGi is one of the most advanced framework supporting dynamic
> > loading/updating/unloading of Java software components. This is clearly
a
> > missing functionality in Eclipse.
> >
> > This is an important point regarding how dependencies on expressed. In
> OSGi,
> > there is great freedom in updating or replacing bundles as long as the
set
> > of exported packages remains the same. This is very interesting when
doing
> > hot updates, where a new provider of a library or a service can be
> > substituted for the currently installed one. For instance, it would
allow
> a
> > real player bundle to replace a windows player, assuming they both
provide
> > the same API to play rich media. In Eclipse, this is not possible.
> >
> > Because OSGi is often confused with an end-to-end deployment
> infrastructure,
> > it is often believed to conflict with Eclipse features. OSGi does not
> > conflict with the Eclipse features because OSGi does not specify a
> > deployment infrastructure at all, not even an update policy. As far as
I
> > can tell, features, plug-ins, and fragments can all be managed above
OSGi
> > bundles, leveraging the local administration API. A side efect of this
is
> > that OSGi does not improve Eclipse management of feature-level
> dependencies
> > and feature management.
> >
> > Here is another very interesting side effect of considering Equinox as a
> > plug-in container above an OSGi platform. By moving the update manager
as
> a
> > administration-aware bundle, I believe we improve the overall robustness
> > regarding installing new software components or updating already
installed
> > ones. Eclipse is somehow weak in resisting install failures since the
> update
> > manager depends on most of the platform to be able to come up... Not
very
> > robust when the configuration is screwed up and needs repair, but
Eclipse
> > can't come up and the update manager is therefore unavailable.
> >
> > By decoupling the Java foundation for software components and the
plug-in
> > container, one achieves less dependencies for the update manager. The
> update
> > manager moves down to the OSGi layer, being a regular bundle with
> > administrative permissions. As a bundle, the update manager could have
> > minimal dependencies for coming up. None if we consider a textual
> interface.
> > SWT only if we consider a more graphical interface. Another avenue would
> be
> > an HTTP daemon and a servlet engine for a remote web interface. OSGi
> > provides a very small footpring web application server suited for this.
> >
> > This would allow to support most configuration failures. If an SWT
> interface
> > is supported, we can still integrate the update manager in the
workbench,
> > but as an option, not a requirement. Even more severe configuration or
> > failures could be handled by reinstalling the platform as long as we can
> > remember the configuration across full re-installs (either locally or on
a
> > server). Indeed, we can reinstall the core OSGi platform and installing
> back
> > the last configuration known to work.
> >
> > Another aspect to discuss is the version model. Eclipse and OSGi have
> > adopted conflicting versioning model. OSGi is Java compliant, following
> the
> > Java versioning model. This means that OSGi imposes full backward
> compliance
> > between bundle versions. Eclipse on the contrary allows major releases
of
> a
> > plug-in to break backward compatibility. This is undoubtly one of the
> major
> > differences between Eclipse and OSGi.
> >
> > A more minor difference is that Eclipse may actually load multiple
> versions
> > on a library... leading to have different versions of the same packages
> > exported concurrently. Eclipse attempts quite complex matching between
> > exports and imports, which may lead to loading only an older version,
only
> > the most recent one, or both. OSGi on the contrary ensures that the
> platform
> > will share only the latest version available of any exported Java
package.
> > Notice that for most plug-ins, the ones declaring extensions or
extension
> > points, Eclipse only loads one version and thereby follows the OSGi
> > behavior. Eclipse is therefore able to potentially satisfy more
intricate
> > dependency situations.
> >
> > Another minor difference is with the order for class loading. Eclipse
> class
> > loading allows local classes to shadow global shared classes. OSGi has
> > adopted a more robust approach where the global space of share classes
> > always prevails on local classes.
> >
> > There are several other minor aspects that need to be discussed. One
> aspect
> > is about configuration data of software components. Another is about
the
> > persistent data of software components. Another one is natural language
> > support.
> >
> > One last important comment is regarding tooling. Adopting OSGi would
> require
> > to bring OSGi-awareness into JDT and PDE. We expect minimal impacts on
JDT
> > but more important ones on PDE. But tooling biggest concern is certainly
a
> > better support for self-hosting, OSGi bundles versus plug-ins is a
minimal
> > issue.
> >
> > Olivier Gruber, Ph.D.
> > Persistent & Distributed Object Platforms and Frameworks
> > IBM TJ Watson Research Center
> >
> >
> >
> >
>
>
|
|
|
| Re: Classloading in Eclipse (was: Eclipse - OSGi Comparison) [message #2961 is a reply to message #2908] |
Tue, 25 February 2003 15:27 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Right. The eclipse model is one of depending on plugins not packages. The
changes you (Ted) did to the classloader essentially mimic the OSGi
behaviour.
Back to your base issue...
Your situation is not unique. Basically you have a mechanism which handles
arbitrary objects from other plugins. These plugins require your plugin.
You cannot do the reverse both because it would cause a circularity and
because you don't necessarily know about all other plugins which may use
you.
Ok, this is largely the same as the UI and menus (for example). The UI
supplies a general mechanism for populating, showing and running menus.
Various plugins want to add their menus/entries. The way this is resolved
is for the UI to expose an extension point for menu entries (I am taking
liberties here with the details). Plugins extend this extension point to
define menu entries/actions. In doing this definition they specify a class
related to the action. When the UI needs to run that action it knows which
class, from which plugin to load. The UI does not "depend" on the plugin,
it has simply been extended with supplied function.
Another approach is the one taken by the Ant support. Ant allows users to
define more tasks and Eclipse wants to support this addition from plugins.
A similar extension mechanism is used to define the tasks/classes but since
we don't want to modify the Ant infrastructure, Eclipse supplies a
classloader for use by Ant. The classloader knows how to load the classes
for the task and is also hooked into the Eclipse classloader structure.
(this is a pretty vague description. I suggest you look at the Ant code.
It's pretty simple).
So, neither of these approaches are quite as simple as simply "importing
using a wildcard" but that approach likely has drawbacks as well.
- in your case you would have to import * to allow for all possible classes
to be marshalled. This likely presents a performance challenge both for the
marshalling code and the other code in your bundle.
- there is no ordering implied so you cannot be assured as to what
implementation you will get. One (i.e., Olivier :-) might counter that it
doesn't matter as "one will be picked" but that sort of non-determinism can
be painful.
- for you to import something, the other bundles must export. That forces
them to make it API.
Jeff
"ted stockwell" <ted.stockwell@acxiom.com> wrote in message
news:b3ftvu$m86$1@rogue.oti.com...
>
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b3fscn$kli$1@rogue.oti.com...
> >
> > The * prefix is also supported where it means any package.
> > So I believe that it would do what you want Ted.
> >
>
> That's it! That's what I was thinking of.
> AFAIK there is no equivalent way to do this in Eclipse.
>
>
|
|
|
| Re: OSGi? [message #2978 is a reply to message #1558] |
Tue, 25 February 2003 15:39 |
| Eclipse User |
|
|
|
Originally posted by: dominic.nospam.com
This looks really promising. I hope it does not get moded down because of
the NIH virus. The plugins versioning of eclipse is really retarded it
reminds me of mfc days {remember mfc42,msvcrt6 ,gtk2 etc.. } that still
prevails these days. When are people going to understand that the major plus
of a component architecture lies in the *versioning*.
I was mulling over alternatives ways of doing components based in eclipse.
How do you solve components distributed by other applications ? for now
there is just no way one can discover/(re)use components shiped with other
applications. So much for components !
"ted stockwell" <ted.stockwell@acxiom.com> wrote in message
news:b390gp$h5t$1@rogue.oti.com...
> Hi All,
>
> First, I think that Equinox is a very timely and needed effort.
>
> When I read the description of what the Equinox project is intended to
> deliver I immediately thought of OSGi (http://www.osgi.org for those not
> familiar with it).
> It seems to me that the OSGi specification already covers all of the
desired
> functionality in spades...
>
> ...Dynamic plug-ins - OSGi's got it. Bundles can be installed, loaded,
> started, stopped, unloaded and uninstalled all without stopping the
server.
> ...Component management - OSGi's got it. OSGi provides a facility for
> controlling access to code based on who is trying to run the code. OSGi
> doesn't have anything equivalent to extension-points and extensions but
> Eclipse covers that.
> ...Dependency management - OSGi's got it. Dependencies are nicely
managed
> through manifest files. If I remember correctly there is also a way to
> query for dependencies at runtime. This doesn't reduce dependency chains
> but it provides a facility for managing them.
> ...Services model - OSGi's got it, big time. Interface based services.
> Attribute based Service lookup, etc.
>
> I can imagine an OSGi plugin for Eclipse that provides an OSGi
compatibility
> layer on top of the Eclipse core runtime. The OSGi plugin could define
> extension points that enable plugins to register OSGi bundles with the
OSGi
> server. The OSGi plugin could also provide a GUI facility for managing
OSGi
> bundles. And of course the OSGi plugin would implement the core OSGi
> interfaces. Strict compliance to the OSGi model could be abandoned when
> convenient. For instance, I'll bet that it would be more convenient to
> always wrap OSGi bundles in plugins and use the Eclipse Update facility
> instead of implementing the standard OSGi update facility.
>
> Once upon a time I built an open source OSGi 1.0 server,
> http://servicetango.sf.net. I would be very excited about helping to
build
> such a compatibility layer for Eclipse.
>
> Is there is any reason for not adopting OSGi as the solution to the
problems
> that you want to solve?
> I think that you should immediately consider whether OSGi provides the
> solution to the problems that you want to solve. Is so, then we can
> immediately get to work to implement the solution!
>
> ted stockwell
> jlense.sf.net
>
>
|
|
|
| Re: Eclipse - OSGi Comparison [message #2994 is a reply to message #2945] |
Tue, 25 February 2003 15:41 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b3fvpi$npr$1@rogue.oti.com...
> > It just happens that most people export "*". That was their explicit
> choice
> > however.
> >
>
> That sounds good, just a different way to achieve the same thing.
> However, it seems to work in the packaged form of plug-ins...
> when classes are loaded from jar files.
> Does it work the same in development mode where classes are loaded
> from the "bin" directory?
yes. The export mechanism is completely independent from the location of
the code.
> They are different and complementary agreed.
> But you are missing the point about interfaces and implementations.
> I must have been unclear.
>
> This is NOT about forcing the use of Java interfaces only.
> SWT would not be implemented differently in OSGi than it
> is in Eclipse. You can export/import any regular Java package
> in OSGi, with classes and interfaces---nothing forces you to
> do strictly Java interfaces.
Understood (now at least :-). This strikes me as an issue relating to a
service model. OSGi has one built-in, Eclipse does not.
Jeff
|
|
|
| Re: Eclipse - OSGi Comparison [message #3011 is a reply to message #2820] |
Tue, 25 February 2003 15:45 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Hum... that one is more difficult to discuss... and a good one
to bring up to the surface early on.
On the one hand, I clearly understand the need for staying aligned
with Eclipse...we don't want to break things for the sake of breaking
them... but on the other hand, Eclipse is not the perfect platform,
otherwise Equinox would not have been created. :-)
Therefore we will have to break some things.
Also, I understand that we want to be able to deliver to Eclipse
on small chunks... but I also want us to do the right thing,
technically. This is the time to break things if they need to.
So let's talk about what we intend to break and the consequences.
We are talking mostly about breaking things within the platform...
and the PDE... this is not the entire Eclipse... this is not about
breaking all existing plug-ins... which should be our main focus.
So aren't we too much change averse here?
We are talking about the following changes:
1) Introducing a Java foundation for software components.
This impacts org.eclipse.core.boot, org.eclipse.core.runtime,
and org.eclipse.update.core. This would be basically invisible
to existing plug-ins. At the most, it requires a change in their
plugin.xml... not a big deal.
Notice that this would be good that we adopt OSGi or not.
2) We are talking about changing how to deal with Java-level
dependencies... moving from requiring plug-ins to have import
statements on Java packages. Again, this is not visible to plug-ins
but at the level of their manifest, not a big deal.
3) Changing self-hosting... that is how JDT, PDE, and the update
manager are working together to provide a seamless life cycle.
Again, this would not make existing plug-in invalid, this is mostly
an internal change to the platform (including the update manager)
and the tooling (JDT and PDE). I don't see why we would be
scared of changes there, especially that they are not that big
anyway, they are more about getting a consistent .
4) We are talking about dynamic plug-ins... as you perfectly know
this is the one that no one argues against but this is the only one
that seriously impacts on the plug-in programming model.
Moreover, this one has nothing to do with the previous three
changes... the impacts will be there no matter what we decide
on the previous three issues.
This requires to re-write virtually almost all plug-ins... because
none of the current plug-ins can deal with extensions or extension
points appearing and disappearing. We may get away with shutting
down some plug-ins, but in most cases, we will have to rewrite
the plug-ins so that they are dynamic-aware. The workbench is
a typical example... as well as any plug-in which implements a
cooperation framework around extension points.
So I would like to call all of the above Equinox... a project
attempting to provide Eclipse with a state of the art platform
and life-cycle management for Java software components,
and of course including a plug-in container and all its goodies.
Now, that we approach it from two angles is fine with me.
One angle could be just dynamic plug-ins... basically upward
from the plug-in registry... focusing mostly on the changes on
the plug-in programming model, but not changing any of
the other aspects. The other would be more internal to the
platform, introducing the split between Java components and
plug-ins, and improving self-hosting.
However, I would rather have the two in one concerted effort,
given that we are not that many.
Best regards,
Olivier.
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b3eos6$o7t$1@rogue.oti.com...
> - Finally, I must re-emphasize Pascal's comments. I'm not entirely sure
how
> to talk about the things that we produce (especially if they are new) but
do
> believe it is confusing and misleading to call them Equinox. Further,
there
> are several aspects to the project.
>
> Jeff
|
|
|
| Re: Eclipse - OSGi Comparison [message #3030 is a reply to message #2994] |
Tue, 25 February 2003 15:47 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b3g14p$pc6$1@rogue.oti.com...
>
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b3fvpi$npr$1@rogue.oti.com...
> > > It just happens that most people export "*". That was their explicit
> > choice
> > > however.
> > >
> >
> > That sounds good, just a different way to achieve the same thing.
> > However, it seems to work in the packaged form of plug-ins...
> > when classes are loaded from jar files.
> > Does it work the same in development mode where classes are loaded
> > from the "bin" directory?
>
> yes. The export mechanism is completely independent from the location of
> the code.
>
> > They are different and complementary agreed.
> > But you are missing the point about interfaces and implementations.
> > I must have been unclear.
> >
> > This is NOT about forcing the use of Java interfaces only.
> > SWT would not be implemented differently in OSGi than it
> > is in Eclipse. You can export/import any regular Java package
> > in OSGi, with classes and interfaces---nothing forces you to
> > do strictly Java interfaces.
>
> Understood (now at least :-). This strikes me as an issue relating to a
> service model. OSGi has one built-in, Eclipse does not.
>
Yep, right on the money... the service framework is really suggesting for
interfaces
rather than classes... but even then, OSGi alllows you to do classes.
Olivier.
> Jeff
>
>
|
|
|
| Re: Eclipse - OSGi Comparison [message #4076 is a reply to message #3011] |
Tue, 25 February 2003 17:24 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Great observations. see my embedded comments...
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b3g181$pfa$1@rogue.oti.com...
> Hum... that one is more difficult to discuss... and a good one
> to bring up to the surface early on.
>
> On the one hand, I clearly understand the need for staying aligned
> with Eclipse...we don't want to break things for the sake of breaking
> them... but on the other hand, Eclipse is not the perfect platform,
> otherwise Equinox would not have been created. :-)
> Therefore we will have to break some things.
>
> Also, I understand that we want to be able to deliver to Eclipse
> on small chunks... but I also want us to do the right thing,
> technically. This is the time to break things if they need to.
> So let's talk about what we intend to break and the consequences.
Some new things will be introduced and there may be some breakage. We are
obliged to keep this to a minimum and develop migration/backfilling
strategies. For example, it doesn't matter how great the new story is if
every plugin out there has be even just tweaked, it will be a *very* hard
sell.
The changes may come over a long period of time. We hope to get some into
2.2. Others will not be ready/possible until 3.0 (whenever that is). It is
important that we not go for a "big bang".
> We are talking mostly about breaking things within the platform...
> and the PDE... this is not the entire Eclipse... this is not about
> breaking all existing plug-ins... which should be our main focus.
> So aren't we too much change averse here?
>
> We are talking about the following changes:
>
> 1) Introducing a Java foundation for software components.
> This impacts org.eclipse.core.boot, org.eclipse.core.runtime,
> and org.eclipse.update.core. This would be basically invisible
> to existing plug-ins. At the most, it requires a change in their
> plugin.xml... not a big deal.
We must ensure there is a legacy path so that as much as possible existing
plugins work or can be made to work automatically/transparently.
> 2) We are talking about changing how to deal with Java-level
> dependencies... moving from requiring plug-ins to have import
> statements on Java packages. Again, this is not visible to plug-ins
> but at the level of their manifest, not a big deal.
ditto
> 4) We are talking about dynamic plug-ins... as you perfectly know
> this is the one that no one argues against but this is the only one
> that seriously impacts on the plug-in programming model.
> Moreover, this one has nothing to do with the previous three
> changes... the impacts will be there no matter what we decide
> on the previous three issues.
>
> This requires to re-write virtually almost all plug-ins... because
> none of the current plug-ins can deal with extensions or extension
> points appearing and disappearing. We may get away with shutting
> down some plug-ins, but in most cases, we will have to rewrite
> the plug-ins so that they are dynamic-aware. The workbench is
> a typical example... as well as any plug-in which implements a
> cooperation framework around extension points.
I think this judgement is premature. If it is true then we can just stop
and go home. Part of the challenge will be figuring out how to do this and
accomodating existing plugins. I don't have the answers yet. That's why
this is a technology project :-)
> Now, that we approach it from two angles is fine with me.
> One angle could be just dynamic plug-ins... basically upward
> from the plug-in registry... focusing mostly on the changes on
> the plug-in programming model, but not changing any of
> the other aspects. The other would be more internal to the
> platform, introducing the split between Java components and
> plug-ins, and improving self-hosting.
>
> However, I would rather have the two in one concerted effort,
> given that we are not that many.
Agreed re two vs one. This work can be staged. For example, parts of
dynamic plugins can be done now and rolled into the 2.2 stream. Other
things will be longer. There is no point in keeping arbitrary barriers
between these efforts but people also need to keep in mind the goal to
release code into the platform early and often. This is absolutely vital to
the success of our efforts.
Jeff
|
|
|
| Re: Eclipse - OSGi Comparison [message #4348 is a reply to message #4076] |
Wed, 26 February 2003 14:54 |
| Eclipse User |
|
|
|
Originally posted by: ted.stockwell.acxiom.com
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b3g74t$vd8$1@rogue.oti.com...
>
> > 4) We are talking about dynamic plug-ins... as you perfectly know
> > this is the one that no one argues against but this is the only one
> > that seriously impacts on the plug-in programming model.
> > Moreover, this one has nothing to do with the previous three
> > changes... the impacts will be there no matter what we decide
> > on the previous three issues.
> >
> > This requires to re-write virtually almost all plug-ins... because
> > none of the current plug-ins can deal with extensions or extension
> > points appearing and disappearing. We may get away with shutting
> > down some plug-ins, but in most cases, we will have to rewrite
> > the plug-ins so that they are dynamic-aware. The workbench is
> > a typical example... as well as any plug-in which implements a
> > cooperation framework around extension points.
>
> I think this judgement is premature. If it is true then we can just stop
> and go home. Part of the challenge will be figuring out how to do this
and
> accomodating existing plugins. I don't have the answers yet. That's why
> this is a technology project :-)
>
For instance, could there just be a new plugin type, the DynamicPlugin?
Regular plugins would still be supported but DynamicPlugins could respond to
extension point state changes.
BTW...
I haven't seen anything on the Equinox site that really details what your
current plans are.
Is Oliver's list of four items relatively accurate?
Those items being:
1) Introducing a Java foundation for software components.
2) changing how to deal with Java-level dependencies...
moving from requiring plug-ins to have import statements on Java packages.
3) Changing self-hosting... that is how JDT, PDE, and the update
manager are working together to provide a seamless life cycle.
4) dynamic plug-ins that can deal with extensions or extension
points appearing and disappearing.
Also, I'm serious about my willingness to help this group implement it's
solutions. The items above are all things that I would like to see in
Eclipse. The above items would be very useful for my project, JLense, so I
have a self-interest in helping to make them a reality. Perhaps you could
make one of the outputs of your discovery and design phase a list of Tasks
to be completed. Then it would be possible for people that want to
contribute to pick up some of the tasks for you.
Any suggestions on how to contribute would are welcome.
ted stockwell
jlense.sf.net
|
|
|
| Plans [message #4627 is a reply to message #4348] |
Fri, 28 February 2003 03:57 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"ted stockwell" <ted.stockwell@acxiom.com> wrote:
> BTW...
> I haven't seen anything on the Equinox site that really details what your
> current plans are.
> Is Oliver's list of four items relatively accurate?
> Those items being:
> 1) Introducing a Java foundation for software components.
> 2) changing how to deal with Java-level dependencies...
> moving from requiring plug-ins to have import statements on Java packages.
> 3) Changing self-hosting... that is how JDT, PDE, and the update
> manager are working together to provide a seamless life cycle.
> 4) dynamic plug-ins that can deal with extensions or extension
> points appearing and disappearing.
Planning should start in earnest next week...
Here is my cut on Olivier's list
1 + 2) These are related. I do not assume a change from plugin prereqing to
package prereqing, OSGi, JMX/jboss, .... A more general characterization is
"alternative runtime designs/implemenations".
3) Work on PDE and JDT etc should wait until more is known about any changes
that might happen. Its hard to write tools when you don't know what you are
tooling.
4) yes. For me this is the poster child of what Equinox can/should/will do.
5) I would also add to the list a service model. It is unclear how this
fits in. That is, should it be something that is integrated in Eclipse or
can the function be provided in a separate plugin? What parts of the
platform would benefit from services? Can these changes be made in a
reasonable way? etc etc.
> Also, I'm serious about my willingness to help this group implement it's
> solutions. The items above are all things that I would like to see in
> Eclipse. The above items would be very useful for my project, JLense, so
I
> have a self-interest in helping to make them a reality. Perhaps you could
> make one of the outputs of your discovery and design phase a list of Tasks
> to be completed. Then it would be possible for people that want to
> contribute to pick up some of the tasks for you.
Great Ted, thanks for your enthusiasm. I look forward to working with you.
Your model matches ours. It is important also that people out there in the
community suggest courses of action and/or work items as well. We have an
idea of where we want to go but there are different routes. When suggesting
things however, people should keep in mind:
- relevance to Eclipse and the stated goals of Equinox
- likelihood of adoption by the platform team
- your level of commitment
- who is going to do the work
Jeff
|
|
|
| Re: OSGi? [message #5043 is a reply to message #1558] |
Fri, 28 February 2003 20:49 |
| Eclipse User |
|
|
|
Originally posted by: dominic.nospam.com
Can somone shed some light on the licensing involved ? Or even better if
there are any patents associated with this thing ? No one would like to see
the whole eclipse community subject to patents disputes.
"ted stockwell" <ted.stockwell@acxiom.com> wrote in message
news:b390gp$h5t$1@rogue.oti.com...
> Hi All,
>
> First, I think that Equinox is a very timely and needed effort.
>
> When I read the description of what the Equinox project is intended to
> deliver I immediately thought of OSGi (http://www.osgi.org for those not
> familiar with it).
> It seems to me that the OSGi specification already covers all of the
desired
> functionality in spades...
>
> ...Dynamic plug-ins - OSGi's got it. Bundles can be installed, loaded,
> started, stopped, unloaded and uninstalled all without stopping the
server.
> ...Component management - OSGi's got it. OSGi provides a facility for
> controlling access to code based on who is trying to run the code. OSGi
> doesn't have anything equivalent to extension-points and extensions but
> Eclipse covers that.
> ...Dependency management - OSGi's got it. Dependencies are nicely
managed
> through manifest files. If I remember correctly there is also a way to
> query for dependencies at runtime. This doesn't reduce dependency chains
> but it provides a facility for managing them.
> ...Services model - OSGi's got it, big time. Interface based services.
> Attribute based Service lookup, etc.
>
> I can imagine an OSGi plugin for Eclipse that provides an OSGi
compatibility
> layer on top of the Eclipse core runtime. The OSGi plugin could define
> extension points that enable plugins to register OSGi bundles with the
OSGi
> server. The OSGi plugin could also provide a GUI facility for managing
OSGi
> bundles. And of course the OSGi plugin would implement the core OSGi
> interfaces. Strict compliance to the OSGi model could be abandoned when
> convenient. For instance, I'll bet that it would be more convenient to
> always wrap OSGi bundles in plugins and use the Eclipse Update facility
> instead of implementing the standard OSGi update facility.
>
> Once upon a time I built an open source OSGi 1.0 server,
> http://servicetango.sf.net. I would be very excited about helping to
build
> such a compatibility layer for Eclipse.
>
> Is there is any reason for not adopting OSGi as the solution to the
problems
> that you want to solve?
> I think that you should immediately consider whether OSGi provides the
> solution to the problems that you want to solve. Is so, then we can
> immediately get to work to implement the solution!
>
> ted stockwell
> jlense.sf.net
>
>
|
|
|
| Re: OSGi? [message #5112 is a reply to message #5043] |
Sat, 01 March 2003 17:07 |
| Eclipse User |
|
|
|
Originally posted by: ted.stockwell.acxiom.com
"dominic" <dominic@nospam.com> wrote in message
news:b3oibh$vvk$1@rogue.oti.com...
> Can somone shed some light on the licensing involved ? Or even better if
> there are any patents associated with this thing ? No one would like to
see
> the whole eclipse community subject to patents disputes.
>
That's a good question.
When I created my open-source version of the OSGi 1.0 specification,
http://servicetango.sf.net, I was under the impression that I was allowed
to create such an implementation royalty free, totally royalty free. The
current licensing overview here,
http://www.osgi.org/resources/spec_licensing.asp , states that members that
contribute to the spec may charge patent royalties. I'm not sure but
perhaps that's a new element of OSGi 2.0 licensing or perhaps I just missed
it the first time. Anyway, that doesn't look good :-(.
I've advocated OSGi because it's a great specification but I would not have
done so if I thought that it could expose people to patent royalties. I'm
scratching OSGi off my list of specifications to implement in JLense some
day.
ted stockwell
|
|
|
| Re: OSGi? [message #5249 is a reply to message #5043] |
Sun, 02 March 2003 20:37 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Its a little unclear what "thing" you are talking about. If you mean
Equinox, as with all other parts of eclipse, it is under the CPL. Besides
Equinox produces changes to the Platform not something separate.
Jeff
"dominic" <dominic@nospam.com> wrote in message
news:b3oibh$vvk$1@rogue.oti.com...
> Can somone shed some light on the licensing involved ? Or even better if
> there are any patents associated with this thing ? No one would like to
see
> the whole eclipse community subject to patents disputes.
|
|
|
| Re: OSGi? [message #6091 is a reply to message #5043] |
Tue, 04 March 2003 08:48 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Sorry I missed all the fun in the list so far, I just heard it got started.
Anyway, OSGi does NOT have to be licensed in any way. The spec can be
downloaded without signing a license.
In the OSGi, members must claim any patents they are aware off before
the spec is voted upon. The "aware off" does not mean they can discover
later they own a patent, as always.
There are several public domain version available: The service tango as
mentioned by Ted, OSCAR (sourceforge) and Espial promissed to place
their compliant implementation in the public domain (I am not sure they
already have done that btw).
Overall, I do not think that implementing a core framework is that hard.
Kind regards,
Peter Kriens
dominic wrote:
> Can somone shed some light on the licensing involved ? Or even better if
> there are any patents associated with this thing ? No one would like to see
> the whole eclipse community subject to patents disputes.
>
> "ted stockwell" <ted.stockwell@acxiom.com> wrote in message
> news:b390gp$h5t$1@rogue.oti.com...
>
>>Hi All,
>>
>>First, I think that Equinox is a very timely and needed effort.
>>
>>When I read the description of what the Equinox project is intended to
>>deliver I immediately thought of OSGi (http://www.osgi.org for those not
>>familiar with it).
>>It seems to me that the OSGi specification already covers all of the
>>
> desired
>
>>functionality in spades...
>>
>>...Dynamic plug-ins - OSGi's got it. Bundles can be installed, loaded,
>>started, stopped, unloaded and uninstalled all without stopping the
>>
> server.
>
>>...Component management - OSGi's got it. OSGi provides a facility for
>>controlling access to code based on who is trying to run the code. OSGi
>>doesn't have anything equivalent to extension-points and extensions but
>>Eclipse covers that.
>>...Dependency management - OSGi's got it. Dependencies are nicely
>>
> managed
>
>>through manifest files. If I remember correctly there is also a way to
>>query for dependencies at runtime. This doesn't reduce dependency chains
>>but it provides a facility for managing them.
>>...Services model - OSGi's got it, big time. Interface based services.
>>Attribute based Service lookup, etc.
>>
>>I can imagine an OSGi plugin for Eclipse that provides an OSGi
>>
> compatibility
>
>>layer on top of the Eclipse core runtime. The OSGi plugin could define
>>extension points that enable plugins to register OSGi bundles with the
>>
> OSGi
>
>>server. The OSGi plugin could also provide a GUI facility for managing
>>
> OSGi
>
>>bundles. And of course the OSGi plugin would implement the core OSGi
>>interfaces. Strict compliance to the OSGi model could be abandoned when
>>convenient. For instance, I'll bet that it would be more convenient to
>>always wrap OSGi bundles in plugins and use the Eclipse Update facility
>>instead of implementing the standard OSGi update facility.
>>
>>Once upon a time I built an open source OSGi 1.0 server,
>>http://servicetango.sf.net. I would be very excited about helping to
>>
> build
>
>>such a compatibility layer for Eclipse.
>>
>>Is there is any reason for not adopting OSGi as the solution to the
>>
> problems
>
>>that you want to solve?
>>I think that you should immediately consider whether OSGi provides the
>>solution to the problems that you want to solve. Is so, then we can
>>immediately get to work to implement the solution!
>>
>>ted stockwell
>>jlense.sf.net
>>
>>
>>
>
>
|
|
|
| Re: OSGi? [message #6149 is a reply to message #6091] |
Tue, 04 March 2003 16:37 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
What is the state of this for the current spec? That is, 3.0 is just/soon
out. Are there any patent royalties required?
What does this say for future versions of the spec? For example, is it
possible that for 4.0 one of the involved companies will claim some patent
rights and all of a sudden the people who have bought into OSGi and want to
move forward have to start paying royalties?
Jeff
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E646862.2010508@aQute.se...
> Sorry I missed all the fun in the list so far, I just heard it got
started.
>
> Anyway, OSGi does NOT have to be licensed in any way. The spec can be
> downloaded without signing a license.
>
> In the OSGi, members must claim any patents they are aware off before
> the spec is voted upon. The "aware off" does not mean they can discover
> later they own a patent, as always.
>
> There are several public domain version available: The service tango as
> mentioned by Ted, OSCAR (sourceforge) and Espial promissed to place
> their compliant implementation in the public domain (I am not sure they
> already have done that btw).
>
> Overall, I do not think that implementing a core framework is that hard.
>
> Kind regards,
>
> Peter Kriens
>
>
> dominic wrote:
>
> > Can somone shed some light on the licensing involved ? Or even better if
> > there are any patents associated with this thing ? No one would like to
see
> > the whole eclipse community subject to patents disputes.
> >
> > "ted stockwell" <ted.stockwell@acxiom.com> wrote in message
> > news:b390gp$h5t$1@rogue.oti.com...
> >
> >>Hi All,
> >>
> >>First, I think that Equinox is a very timely and needed effort.
> >>
> >>When I read the description of what the Equinox project is intended to
> >>deliver I immediately thought of OSGi (http://www.osgi.org for those not
> >>familiar with it).
> >>It seems to me that the OSGi specification already covers all of the
> >>
> > desired
> >
> >>functionality in spades...
> >>
> >>...Dynamic plug-ins - OSGi's got it. Bundles can be installed, loaded,
> >>started, stopped, unloaded and uninstalled all without stopping the
> >>
> > server.
> >
> >>...Component management - OSGi's got it. OSGi provides a facility for
> >>controlling access to code based on who is trying to run the code. OSGi
> >>doesn't have anything equivalent to extension-points and extensions but
> >>Eclipse covers that.
> >>...Dependency management - OSGi's got it. Dependencies are nicely
> >>
> > managed
> >
> >>through manifest files. If I remember correctly there is also a way to
> >>query for dependencies at runtime. This doesn't reduce dependency
chains
> >>but it provides a facility for managing them.
> >>...Services model - OSGi's got it, big time. Interface based services.
> >>Attribute based Service lookup, etc.
> >>
> >>I can imagine an OSGi plugin for Eclipse that provides an OSGi
> >>
> > compatibility
> >
> >>layer on top of the Eclipse core runtime. The OSGi plugin could define
> >>extension points that enable plugins to register OSGi bundles with the
> >>
> > OSGi
> >
> >>server. The OSGi plugin could also provide a GUI facility for managing
> >>
> > OSGi
> >
> >>bundles. And of course the OSGi plugin would implement the core OSGi
> >>interfaces. Strict compliance to the OSGi model could be abandoned when
> >>convenient. For instance, I'll bet that it would be more convenient to
> >>always wrap OSGi bundles in plugins and use the Eclipse Update facility
> >>instead of implementing the standard OSGi update facility.
> >>
> >>Once upon a time I built an open source OSGi 1.0 server,
> >>http://servicetango.sf.net. I would be very excited about helping to
> >>
> > build
> >
> >>such a compatibility layer for Eclipse.
> >>
> >>Is there is any reason for not adopting OSGi as the solution to the
> >>
> > problems
> >
> >>that you want to solve?
> >>I think that you should immediately consider whether OSGi provides the
> >>solution to the problems that you want to solve. Is so, then we can
> >>immediately get to work to implement the solution!
> >>
> >>ted stockwell
> >>jlense.sf.net
> >>
> >>
> >>
> >
> >
>
|
|
|
| Re: OSGi? [message #6211 is a reply to message #6149] |
Tue, 04 March 2003 19:31 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Currently nobody has claimed patents on release 3 so it is patent free
so far. Release 3 will be public before the summer.
Patents are an unfortunate part of our lifes. Any piece of software,
including Eclipse, can be struck by a company that decides one of their
patents is applicable. At least with the OSGi specification the persons
that have been involved in the technical work must have declared to the
best of their knowledge their company has no claim on the spec. This
prevents sub-marine patents. With companies like IBM, Motorola,
Ericsson, Philips etc. it is probably about the best you can get.
I think the problem of patents is pretty remote. The problems are likely
much less than the current Eclipse code base because we only specify
interfaces and no implementations. Patents are usually about
implementaton (though M$ is now patenting their .NET API!!!).
Obviously the spec cannot be patented once it is published so as long as
we stick to the published information there is we should be ok. It is
imho highly unlikely that the OSGi would ever start asking royalties.
Summary: The problem is no worse than what you already got.
Kind regards,
Peter Kriens
Jeff McAffer wrote:
> What is the state of this for the current spec? That is, 3.0 is just/soon
> out. Are there any patent royalties required?
>
> What does this say for future versions of the spec? For example, is it
> possible that for 4.0 one of the involved companies will claim some patent
> rights and all of a sudden the people who have bought into OSGi and want to
> move forward have to start paying royalties?
>
> Jeff
>
> "pkriens" <Peter.Kriens@aQute.se> wrote in message
> news:3E646862.2010508@aQute.se...
>
>>Sorry I missed all the fun in the list so far, I just heard it got
>>
> started.
>
>>Anyway, OSGi does NOT have to be licensed in any way. The spec can be
>>downloaded without signing a license.
>>
>>In the OSGi, members must claim any patents they are aware off before
>>the spec is voted upon. The "aware off" does not mean they can discover
>>later they own a patent, as always.
>>
>>There are several public domain version available: The service tango as
>>mentioned by Ted, OSCAR (sourceforge) and Espial promissed to place
>>their compliant implementation in the public domain (I am not sure they
>>already have done that btw).
>>
>>Overall, I do not think that implementing a core framework is that hard.
>>
>>Kind regards,
>>
>>Peter Kriens
>>
>>
>>dominic wrote:
>>
>>
>>>Can somone shed some light on the licensing involved ? Or even better if
>>>there are any patents associated with this thing ? No one would like to
>>>
> see
>
>>>the whole eclipse community subject to patents disputes.
>>>
>>>"ted stockwell" <ted.stockwell@acxiom.com> wrote in message
>>>news:b390gp$h5t$1@rogue.oti.com...
>>>
>>>
>>>>Hi All,
>>>>
>>>>First, I think that Equinox is a very timely and needed effort.
>>>>
>>>>When I read the description of what the Equinox project is intended to
>>>>deliver I immediately thought of OSGi (http://www.osgi.org for those not
>>>>familiar with it).
>>>>It seems to me that the OSGi specification already covers all of the
>>>>
>>>>
>>>desired
>>>
>>>
>>>>functionality in spades...
>>>>
>>>>...Dynamic plug-ins - OSGi's got it. Bundles can be installed, loaded,
>>>>started, stopped, unloaded and uninstalled all without stopping the
>>>>
>>>>
>>>server.
>>>
>>>
>>>>...Component management - OSGi's got it. OSGi provides a facility for
>>>>controlling access to code based on who is trying to run the code. OSGi
>>>>doesn't have anything equivalent to extension-points and extensions but
>>>>Eclipse covers that.
>>>>...Dependency management - OSGi's got it. Dependencies are nicely
>>>>
>>>>
>>>managed
>>>
>>>
>>>>through manifest files. If I remember correctly there is also a way to
>>>>query for dependencies at runtime. This doesn't reduce dependency
>>>>
> chains
>
>>>>but it provides a facility for managing them.
>>>>...Services model - OSGi's got it, big time. Interface based services.
>>>>Attribute based Service lookup, etc.
>>>>
>>>>I can imagine an OSGi plugin for Eclipse that provides an OSGi
>>>>
>>>>
>>>compatibility
>>>
>>>
>>>>layer on top of the Eclipse core runtime. The OSGi plugin could define
>>>>extension points that enable plugins to register OSGi bundles with the
>>>>
>>>>
>>>OSGi
>>>
>>>
>>>>server. The OSGi plugin could also provide a GUI facility for managing
>>>>
>>>>
>>>OSGi
>>>
>>>
>>>>bundles. And of course the OSGi plugin would implement the core OSGi
>>>>interfaces. Strict compliance to the OSGi model could be abandoned when
>>>>convenient. For instance, I'll bet that it would be more convenient to
>>>>always wrap OSGi bundles in plugins and use the Eclipse Update facility
>>>>instead of implementing the standard OSGi update facility.
>>>>
>>>>Once upon a time I built an open source OSGi 1.0 server,
>>>>http://servicetango.sf.net. I would be very excited about helping to
>>>>
>>>>
>>>build
>>>
>>>
>>>>such a compatibility layer for Eclipse.
>>>>
>>>>Is there is any reason for not adopting OSGi as the solution to the
>>>>
>>>>
>>>problems
>>>
>>>
>>>>that you want to solve?
>>>>I think that you should immediately consider whether OSGi provides the
>>>>solution to the problems that you want to solve. Is so, then we can
>>>>immediately get to work to implement the solution!
>>>>
>>>>ted stockwell
>>>>jlense.sf.net
>>>>
>>>>
>>>>
>>>>
>>>
>
>
|
|
|
| Re: Classloading in Eclipse [message #6263 is a reply to message #2890] |
Tue, 04 March 2003 20:38 |
| Eclipse User |
|
|
|
Originally posted by: delete_heavy_nospam.ungoverned.org
Olivier,
Could you point me to where in the OSGi 2.0 spec where I can read about
the functionality you describe below.
I implement Oscar, an open source OSGi framework implementation, and I
am unfamiliar with these capabilities...I am wondering if I missed
something.
Perhaps this is version 3.0?
-> richard
Olivier Gruber wrote:
> First a clarification... an OSGi bundle has to import a package in order
> to see the exported classes. Otherwise, you will get an exception class not
> found.
>
> However, OSGi supports a dynamic import... where a bundle manifest
> could specify package name prefixes for dynamic lookup.
> So for instance, a bundle may specify that it wants to dynamically import
>
> org.eclipse.*
>
> which will allow the runtime to dynamically lookup for
> any exported package org.eclipse.* when it needs to resolve a class
> with a prefix of org.eclipse.
>
> The * prefix is also supported where it means any package.
> So I believe that it would do what you want Ted.
>
> Cheers,
>
> Olivier.
>
> --
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
> "ted stockwell" <ted.stockwell@acxiom.com> wrote in message
> news:b3fhja$ad0$1@rogue.oti.com...
>
>>Y'know, I went back and read the OSGi spec and I think that I have always
>>misinterpreted how exports should behave in OSGi.
>>
>>So, let me give you the details of a problem I had developing a J2EE
>
> client
>
>>application in Eclipse. I have never been able to resolve this problem in
>
> a
>
>>satisfactory way in Eclipse, it would be good if Equinox had some good way
>>to deal with it.
>>
>>My client application talks to an EJB session bean. The signature of the
>>session bean is something like this:
>> public interface GeneralLedgerService implements Remote {
>> Account getAccount(String accountId) throws RemoteException;
>> }
>>The session bean is hosted in an instance of JBoss. On the client side I
>>have a plugin, org.jboss.client, that wraps the JBoss client libraries.
>
> The
>
>>JBoss client libraries are basically responsible for marshalling calls to
>>EJB beans and unmarshalling the results. The client libraries also
>>propagate the Transaction and Security contexts to the server.
>>
>>When a plugin on the client side calls the GeneralLedgerService.getAccount
>>method eventually the org.jboss.client plugin must marshal the account id,
>>invoke the remote getAccount method, and then deserialize the returned
>>Account object. However, if the org.jboss.client plugin doesn't have
>
> access
>
>>to the Account class then it will throw a NoClassDefFoundError. So, in
>>order to function the org.jboss.client must basically import packages from
>>all plugins that want to use it. Nasty.
>>
>>I suppose I could have configured my client application to load classes
>
> from
>
>>server but then I figured that I would get ClassCastExceptions when
>>instances loaded by the org.jboss.client plugin were returned to other
>>plugins (since the other plugins would be loading GeneralLedgerService
>
> from
>
>>elsewhere).
>>
>>--------------------------------------------
>>
>>Meanwhile, since I didn't want to actually add all those imports to the
>>org.jboss.client plugin, I hacked the Eclipse plugin classloader as
>>follows...
>>
>>...All my plugins explicitly export all thier packages.
>>
>>...When a plugin classloader is looking for a class it first looks in all
>>the plugins explicitly imported by the plugin. If the class is not found
>>then it starts looking through the plugins that were not explicitly
>
> imported
>
>>for a matching package in the list of exported packages from the other
>>plugins. If a match is found then the class is loaded from the other
>
> plugin
>
>>even though it was not explicitly imported.
>>
>>
>>ted
>>
>>
>
>
>
|
|
|
| Re: Classloading in Eclipse [message #6293 is a reply to message #6263] |
Tue, 04 March 2003 21:32 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Hi Richard,
Good to hear that other OSGi believers are reading those postings... :-)
Yep, I am afraid that this in the 3.0 spec...
sorry for spilling the beans :-)
Interested in Equinox and the potential merge between Eclipse and OSGi ?
Please join... :-)
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Richard S. Hall" <delete_heavy_nospam@ungoverned.org> wrote in message
news:b4334m$g4t$1@rogue.oti.com...
> Olivier,
>
> Could you point me to where in the OSGi 2.0 spec where I can read about
> the functionality you describe below.
>
> I implement Oscar, an open source OSGi framework implementation, and I
> am unfamiliar with these capabilities...I am wondering if I missed
> something.
>
> Perhaps this is version 3.0?
>
> -> richard
>
> Olivier Gruber wrote:
> > First a clarification... an OSGi bundle has to import a package in order
> > to see the exported classes. Otherwise, you will get an exception class
not
> > found.
> >
> > However, OSGi supports a dynamic import... where a bundle manifest
> > could specify package name prefixes for dynamic lookup.
> > So for instance, a bundle may specify that it wants to dynamically
import
> >
> > org.eclipse.*
> >
> > which will allow the runtime to dynamically lookup for
> > any exported package org.eclipse.* when it needs to resolve a class
> > with a prefix of org.eclipse.
> >
> > The * prefix is also supported where it means any package.
> > So I believe that it would do what you want Ted.
> >
> > Cheers,
> >
> > Olivier.
> >
> > --
> > Olivier Gruber, Ph.D.
> > Persistent & Distributed Object Platforms and Frameworks
> > IBM TJ Watson Research Center
> >
> > "ted stockwell" <ted.stockwell@acxiom.com> wrote in message
> > news:b3fhja$ad0$1@rogue.oti.com...
> >
> >>Y'know, I went back and read the OSGi spec and I think that I have
always
> >>misinterpreted how exports should behave in OSGi.
> >>
> >>So, let me give you the details of a problem I had developing a J2EE
> >
> > client
> >
> >>application in Eclipse. I have never been able to resolve this problem
in
> >
> > a
> >
> >>satisfactory way in Eclipse, it would be good if Equinox had some good
way
> >>to deal with it.
> >>
> >>My client application talks to an EJB session bean. The signature of
the
> >>session bean is something like this:
> >> public interface GeneralLedgerService implements Remote {
> >> Account getAccount(String accountId) throws RemoteException;
> >> }
> >>The session bean is hosted in an instance of JBoss. On the client side
I
> >>have a plugin, org.jboss.client, that wraps the JBoss client libraries.
> >
> > The
> >
> >>JBoss client libraries are basically responsible for marshalling calls
to
> >>EJB beans and unmarshalling the results. The client libraries also
> >>propagate the Transaction and Security contexts to the server.
> >>
> >>When a plugin on the client side calls the
GeneralLedgerService.getAccount
> >>method eventually the org.jboss.client plugin must marshal the account
id,
> >>invoke the remote getAccount method, and then deserialize the returned
> >>Account object. However, if the org.jboss.client plugin doesn't have
> >
> > access
> >
> >>to the Account class then it will throw a NoClassDefFoundError. So, in
> >>order to function the org.jboss.client must basically import packages
from
> >>all plugins that want to use it. Nasty.
> >>
> >>I suppose I could have configured my client application to load classes
> >
> > from
> >
> >>server but then I figured that I would get ClassCastExceptions when
> >>instances loaded by the org.jboss.client plugin were returned to other
> >>plugins (since the other plugins would be loading GeneralLedgerService
> >
> > from
> >
> >>elsewhere).
> >>
> >>--------------------------------------------
> >>
> >>Meanwhile, since I didn't want to actually add all those imports to the
> >>org.jboss.client plugin, I hacked the Eclipse plugin classloader as
> >>follows...
> >>
> >>...All my plugins explicitly export all thier packages.
> >>
> >>...When a plugin classloader is looking for a class it first looks in
all
> >>the plugins explicitly imported by the plugin. If the class is not
found
> >>then it starts looking through the plugins that were not explicitly
> >
> > imported
> >
> >>for a matching package in the list of exported packages from the other
> >>plugins. If a match is found then the class is loaded from the other
> >
> > plugin
> >
> >>even though it was not explicitly imported.
> >>
> >>
> >>ted
> >>
> >>
> >
> >
> >
>
|
|
|
| Re: Classloading in Eclipse [message #7605 is a reply to message #6293] |
Wed, 05 March 2003 14:19 |
| Eclipse User |
|
|
|
Originally posted by: delete_heavy_nospam.ungoverned.org
Olivier Gruber wrote:
> Interested in Equinox and the potential merge between Eclipse and OSGi ?
> Please join... :-)
I am definitely interested...I have been trying for something similar
now for two years...I'm getting tired... :^)
-> richard
|
|
|
| Re: Classloading in Eclipse [message #7646 is a reply to message #7605] |
Wed, 05 March 2003 14:59 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
I know the feeling... been pushing for a self-hosting object-oriented
platform (like Equinox) for years... almost 4 years now...
Well, let's join forces... Welcome !
I looked at your service binder a bit, looks really interesting...
Nice adjunct to OSGi... Now the question here is regarding
extension points in Eclipse... how do they relate to services...
they are quite different beasts but share some of the same
characteristics... they come and go (when Equinox will be
dynamic), they require event notification about life cycle,
they need that references be dropped so that they
can be updated...
So the question is how are they mixing in one design and
architecture ?
Best regards,
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Richard S. Hall" <delete_heavy_nospam@ungoverned.org> wrote in message
news:b451a7$qbr$1@rogue.oti.com...
> Olivier Gruber wrote:
> > Interested in Equinox and the potential merge between Eclipse and OSGi ?
> > Please join... :-)
>
> I am definitely interested...I have been trying for something similar
> now for two years...I'm getting tired... :^)
>
> -> richard
>
|
|
| |
| Re: Classloading in Eclipse [message #13010 is a reply to message #7646] |
Thu, 13 March 2003 12:05 |
| Eclipse User |
|
|
|
Originally posted by: delete_heavy_nospam.ungoverned.org
So, I was gone for a week of meetings in both Spain and Paris trying to
push this view of OSGi as a dynamic component-oriented application
framework...the idea actually seems to be gaining momentum.
The work I (and a colleague) are doing with OSGi is definitely
interesting; this includes the Service Binder, which is part of a bigger
project, called Gravity, that includes an application composition and
run-time environment...all of which focuses on dynamic availability of
components. It is shaping up to be some really interesting stuff.
Hopefully I will have a paper available on it shortly, for those who are
interested.
I don't really know anything about Eclipse, so it is difficult for me to
comment on its relationships to OSGi...the only thing I know is what I
have read on this forum. Perhaps you could point me to a specific
document that discusses extension points.
-> richard
Olivier Gruber wrote:
> I know the feeling... been pushing for a self-hosting object-oriented
> platform (like Equinox) for years... almost 4 years now...
> Well, let's join forces... Welcome !
>
> I looked at your service binder a bit, looks really interesting...
> Nice adjunct to OSGi... Now the question here is regarding
> extension points in Eclipse... how do they relate to services...
> they are quite different beasts but share some of the same
> characteristics... they come and go (when Equinox will be
> dynamic), they require event notification about life cycle,
> they need that references be dropped so that they
> can be updated...
>
> So the question is how are they mixing in one design and
> architecture ?
>
> Best regards,
> --
> Olivier Gruber, Ph.D.
> Persistent & Distributed Object Platforms and Frameworks
> IBM TJ Watson Research Center
>
> "Richard S. Hall" <delete_heavy_nospam@ungoverned.org> wrote in message
> news:b451a7$qbr$1@rogue.oti.com...
>
>>Olivier Gruber wrote:
>>
>>>Interested in Equinox and the potential merge between Eclipse and OSGi ?
>>>Please join... :-)
>>
>>I am definitely interested...I have been trying for something similar
>>now for two years...I'm getting tired... :^)
>>
>>-> richard
>>
>
>
>
|
|
|
| Re: Classloading in Eclipse [message #13039 is a reply to message #8946] |
Thu, 13 March 2003 12:08 |
| Eclipse User |
|
|
|
Originally posted by: delete_heavy_nospam.ungoverned.org
Christophe Elek wrote:
> Small world :-) Welcome back Rick
Hey, I never went anywhere! :^)
> FYI. Most of my research to create Update Manager was based on Rick thesis
> and other relted SERL doc...
My work still hovers around deployment, but now focused on deploying
dynamic, component-based systems...this allows me to do stuff that is
more fun that trying to deploy legacy apps...
-> richard
|
|
|
Goto Forum:
Current Time: Fri Apr 26 16:30:36 GMT 2024
Powered by FUDForum. Page generated in 0.05974 seconds |
] 
Search
Help
Register
Login
Home
