Home » Eclipse Projects » Equinox » let's get started!
| let's get started! [message #6179] |
Tue, 04 March 2003 17:05  |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Ok, we have all/most of the infrastructure in place, the CVS repo is
populated with M5 and RC1, there have been several good discussion threads
started in the newsgroup and some proposed work items. Its time for rubber
to hit the road.
It seems that there are two main directions represented so far; dynamic
plugins and OSGi. Of course, this two overlap in ways but progress can be
made independently.
Dynamic-plugins
==========
Pascal outlined some of the issues and they have been duplicated/updated in
the "plans" section of the Equinox website. Specifically, the dynamic
plugins work should focus on a simple mechanism for unloading plugins (to
get our feet wet) and then look at how to manage a dynamically changing
registry. The unloading mechanism (for now) need not try to be the optimal
implementation. Several people have pointed out that breaking all the
references is a hard problem requiring lifecycle (should come as part of
registry management), programmer diligence and perhaps some tooling. We
should take baby steps here.
From what I have seen, Pascal, Olivier and Peter are keen in this area.
OSGi
====
This is a little less clear (to me at least). Ideally we should have a
clear/concise description of the relationship between Eclipse and OSGi and
the mapping from Eclipse plugin to OSGi bundle. We already have a start in
that Olivier has done a partial implementation of Eclipse on OSGi. I
suspect that Peter and others have ideas on this as well. Another issue is
picking an OSGi implementation to use. I guess in theory it should not
matter but in reality some will be better than others. So, those who know
should identify one as the reference.
It appears that Olivier and Peter are pointed in this direction.
Jeff
|
|
|
| Re: let's get started! [message #6233 is a reply to message #6179] |
Tue, 04 March 2003 19:35  |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Sounds good to me :-)
As I posted in a reply to Pascal posting on the details about dynamic
plug-ins,
there are issues regarding the component model and respective tooling
when considering the full load/unload of plug-ins...
So independently of OSGi adoption, I would like to really start a design
discussion on those issues, even though they are not relevant in the 2.2
timeframe. They will impact what the 3.0 release will be like, with OSGi or
not... it is also paramount in determining if OSGi is applicable as is or
if Eclipse will require OSGi to evolve. If OSGi is ask for an evolution,
it would be fair to have the why's and how's fairly rapidly to enable
a possible merge for the 3.0 timeframe...
Fellow committers, how do we see those discussions happening?
In particular, how do we involve Eclipse committers early on?
As I said, the issues are likely to impact profoundly the platform,
somewhat the tooling (JDT,PDE), and marginally plug-ins... if
at all for most of them (changing their manifest might be all that
most require... some may require recompilation).
Best regards,
--
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:b42mks$5ds$1@rogue.oti.com...
> Ok, we have all/most of the infrastructure in place, the CVS repo is
> populated with M5 and RC1, there have been several good discussion threads
> started in the newsgroup and some proposed work items. Its time for
rubber
> to hit the road.
>
> It seems that there are two main directions represented so far; dynamic
> plugins and OSGi. Of course, this two overlap in ways but progress can be
> made independently.
>
> Dynamic-plugins
> ==========
> Pascal outlined some of the issues and they have been duplicated/updated
in
> the "plans" section of the Equinox website. Specifically, the dynamic
> plugins work should focus on a simple mechanism for unloading plugins (to
> get our feet wet) and then look at how to manage a dynamically changing
> registry. The unloading mechanism (for now) need not try to be the
optimal
> implementation. Several people have pointed out that breaking all the
> references is a hard problem requiring lifecycle (should come as part of
> registry management), programmer diligence and perhaps some tooling. We
> should take baby steps here.
>
> From what I have seen, Pascal, Olivier and Peter are keen in this area.
>
> OSGi
> ====
> This is a little less clear (to me at least). Ideally we should have a
> clear/concise description of the relationship between Eclipse and OSGi and
> the mapping from Eclipse plugin to OSGi bundle. We already have a start
in
> that Olivier has done a partial implementation of Eclipse on OSGi. I
> suspect that Peter and others have ideas on this as well. Another issue
is
> picking an OSGi implementation to use. I guess in theory it should not
> matter but in reality some will be better than others. So, those who know
> should identify one as the reference.
>
> It appears that Olivier and Peter are pointed in this direction.
>
> Jeff
>
>
|
|
|
| Picking OSGi implementation [message #6247 is a reply to message #6179] |
Tue, 04 March 2003 20:01 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
IBM has a very good implementation of OSGi with SMF. Somebody might ask
them if they would be willing to donate it to Eclipse looking at their
close association with Eclipse. Ted Stockwell in this list seems to have
made a public domain version which is release 1. Upgrading to release 3
will probably not be a major effort with the help form some insiders
:-) There is also OSCAR on sourceforge which seems to be pretty active
over time. We might ask the developer Richard Hall to participate.
Espial stated in September in Stockholm that they would put their
framework implementation in the open source domain. I can put a question
to other companies if they would be willing to donate their Framework
version.
http://www-3.ibm.com/software/pervasive/products/wme/
http://oscar-osgi.sourceforge.net/
http://servicetango.sourceforge.net/topics/Introduction.html
http://www.espial.com
Kind regards,
Peter Kriens
Jeff McAffer wrote:
> Ok, we have all/most of the infrastructure in place, the CVS repo is
> populated with M5 and RC1, there have been several good discussion threads
> started in the newsgroup and some proposed work items. Its time for rubber
> to hit the road.
>
> It seems that there are two main directions represented so far; dynamic
> plugins and OSGi. Of course, this two overlap in ways but progress can be
> made independently.
>
> Dynamic-plugins
> ==========
> Pascal outlined some of the issues and they have been duplicated/updated in
> the "plans" section of the Equinox website. Specifically, the dynamic
> plugins work should focus on a simple mechanism for unloading plugins (to
> get our feet wet) and then look at how to manage a dynamically changing
> registry. The unloading mechanism (for now) need not try to be the optimal
> implementation. Several people have pointed out that breaking all the
> references is a hard problem requiring lifecycle (should come as part of
> registry management), programmer diligence and perhaps some tooling. We
> should take baby steps here.
>
> From what I have seen, Pascal, Olivier and Peter are keen in this area.
>
> OSGi
> ====
> This is a little less clear (to me at least). Ideally we should have a
> clear/concise description of the relationship between Eclipse and OSGi and
> the mapping from Eclipse plugin to OSGi bundle. We already have a start in
> that Olivier has done a partial implementation of Eclipse on OSGi. I
> suspect that Peter and others have ideas on this as well. Another issue is
> picking an OSGi implementation to use. I guess in theory it should not
> matter but in reality some will be better than others. So, those who know
> should identify one as the reference.
>
> It appears that Olivier and Peter are pointed in this direction.
>
> Jeff
>
>
>
|
|
|
| Re: Picking OSGi implementation [message #6278 is a reply to message #6247] |
Tue, 04 March 2003 21:13 |
| Eclipse User |
|
|
|
Originally posted by: delete_heavy_nospam.ungoverned.org
As Peter mentioned, I have an implementation of the OSGi framework,
called Oscar, on source forge. It is not 100% compliant with the 2.0
specification, but it is close...it is not really my day job, so I can't
devote all of my time to it. Regardless, it has been the only
consistently available open OSGi framework implementation for the last
two years. As a result, the community (albeit small) is pretty loyal.
I actually tried, unsuccessfully, to push jEdit to use OSGi as its
plugin mechanism because it suffers from static plugins as well. I wrote
a simple document and example about it, which is available here:
http://oscar-osgi.sf.net/oscarplugin.html
The above document is outdated and will probably no longer work with the
newest version of jEdit, but the ideas are still relevant.
I started Oscar as a way to do my research for a dynamic application
framework, pretty much like what you are discussing here. The project,
called Gravity and also on source forge (but not completely available),
is trying to support applications built out of dynamically available
building blocks. As part of this effort, a colleague and myself have
defined a mechanism, called the Service Binder, for automating service
dependency resolution (something that is lacking in OSGi), more
information about this is available at:
http://gravity.sf.net/servicebinder
I also have a paper about the service binder I could make available to
interested people, but most of the information is available on the web
site, perhaps in less readable form.
Gravity itself, is sort of an application framework, GUI RAD tool all
rolled into one. It uses OSGi to handle component deployment and service
integration and uses the service binder to automatically assembly
applications that can dynamically change and adapt at run time. I have a
demo (with scant documentation) available here:
http://gravity.sf.net/gravity-demo.html
Gravity itself is very much a prototype, whereas Oscar and the Service
Binder are very stable. The above demo illustrates the auto-adaptive
behavior of an application built using the Gravity framework;. I will
have a paper describing Gravity available by March 14th, for those that
are interested.
As for whether you "pick Oscar" for experimentation, the more the
merrier with respect to the Oscar community. No good arguments on my
part why or why not, other than its there and it works...I am not much
for popularity contests. As always, there are some design decisions in
Oscar that I regret (and will probably change), but I am confident in
its functionality since it is used by many people.
I would love to say that I would be able to spend a lot of time
contributing to this project since it is definitely covering some of my
core research topics, but I cannot make any commitment. I am definitely
willing to keep working on Oscar and to offer my expertise and
judgement...perhaps more, if sufficiently piqued. :^)
-> richard
|
|
|
| Re: Picking OSGi implementation [message #7564 is a reply to message #6247] |
Wed, 05 March 2003 02:51 |
| Eclipse User |
|
|
|
Originally posted by: pascal_rapicault.yahoo.fr
As a matter of curiosity:
- How long does it takes to implement the core of the OSGi framework, if
we need
to start from scratch?
- Question to Richard: do you think it is complicated to change your
regretted
implementation choice, if we decide to go for your implementation
- Is there any compliance test suite available?
PaScaL
|
|
|
| Re: Picking OSGi implementation [message #7584 is a reply to message #7564] |
Wed, 05 March 2003 06:51 |
| Eclipse User |
|
|
|
Originally posted by: Peter.Kriens.aQute.se
Pascal Rapicault wrote:
> - How long does it takes to implement the core of the OSGi framework, if we need
> to start from scratch?
I know one person who stated that he implemented the core framework in 2
days. However, I think mortal souls, being good Java programmers, can
put together a framework in 10-15 man-days.
> - Question to Richard: do you think it is complicated to change your
> regretted
> implementation choice, if we decide to go for your implementation
> - Is there any compliance test suite available?
Yes. This compliance suite is only available to OSGi members. However, a
member may use his membership to submit a framework on behalf of another
party. Currently running the compliance program costs $3000. I guess we
can always ask the OSGi board to wave this fee for this project. This
will probably not be easy be worth a shot.
Kind regards,
Peter Kriens
>
> PaScaL
>
>
>
|
|
|
| Re: Picking OSGi implementation [message #7625 is a reply to message #7564] |
Wed, 05 March 2003 14:26 |
| Eclipse User |
|
|
|
Originally posted by: delete_heavy_nospam.ungoverned.org
> As a matter of curiosity:
> - How long does it takes to implement the core of the OSGi framework, if
> we need
> to start from scratch?
Depends on whether you work on it full-time or not. I was able to get
some basic bundles loading over a weekend when I started with 1.0, but I
also started from a project that had similar capabilities.
I haven't really worked on it full-time...I just add things as I go and
as they are requested (and introduced in the new specs)...
As always, its the little "gotchas" that are the problem, not the gross
functionality.
> - Question to Richard: do you think it is complicated to change your
> regretted
> implementation choice, if we decide to go for your implementation
The regretted decision is how I handle concurrency, it is too
complicated and I would like to simplify it considerably. I could go
into detail as to why it is the way that it is, if you are interested,
but suffice it to say, I want to modify it so that it is less
"concurrent" for the sake of simplicity.
> - Is there any compliance test suite available?
Not from me. Some guy recently started to test Oscar on one (or so he
told me in email), but he got called off to do more important work, so
the results are not in.
-> richard
|
|
|
| Re: Picking OSGi implementation [message #7667 is a reply to message #7584] |
Wed, 05 March 2003 15:10 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Just a point of clarification...
Ideally we do not need to do an OSGi implementation in Equinox. As we have
seen, there are several existing ones. If they need changes/help, we should
cooperate with those projects to get what is needed.
Jeff
"pkriens" <Peter.Kriens@aQute.se> wrote in message
news:3E659E63.5060600@aQute.se...
> Pascal Rapicault wrote:
>
> > - How long does it takes to implement the core of the OSGi
framework, if we need
> > to start from scratch?
>
> I know one person who stated that he implemented the core framework in 2
> days. However, I think mortal souls, being good Java programmers, can
> put together a framework in 10-15 man-days.
>
>
> > - Question to Richard: do you think it is complicated to change your
> > regretted
> > implementation choice, if we decide to go for your implementation
> > - Is there any compliance test suite available?
>
> Yes. This compliance suite is only available to OSGi members. However, a
> member may use his membership to submit a framework on behalf of another
> party. Currently running the compliance program costs $3000. I guess we
> can always ask the OSGi board to wave this fee for this project. This
> will probably not be easy be worth a shot.
>
> Kind regards,
>
> Peter Kriens
>
>
> >
> > PaScaL
> >
> >
> >
>
|
|
|
| Re: let's get started! [message #7711 is a reply to message #6179] |
Wed, 05 March 2003 15:53 |
| Eclipse User |
|
|
|
Originally posted by: ted.stockwell.acxiom.com
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b42mks$5ds$1@rogue.oti.com...
>
> OSGi
> ====
> We already have a start in
> that Olivier has done a partial implementation of Eclipse on OSGi.
>
I have some questions about this...
....is this going to be added to CVS?
....what is used for the OSGi layer? Anything this group can use for an
initial OSGi implementation?
....I thought there were some questions regarding whether the Eclipse plugin
layer should be implemented on OSGi or whether the OSGi layer should be
implemented on top of the Eclipse plugin layer (an enhanced Eclipse plugin
layer with support for dynamic plugins). Is there an 'official' decision
regarding the approach here?
Thanks,
ted
PS: Wow, I left for a fews days and missed a lot!
|
|
|
| Re: let's get started! [message #7839 is a reply to message #7711] |
Wed, 05 March 2003 21:43 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"ted stockwell" <ted.stockwell@acxiom.com> wrote in message
news:b456pf$vjc$1@rogue.oti.com...
>
> "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> news:b42mks$5ds$1@rogue.oti.com...
> >
> > OSGi
> > ====
> > We already have a start in
> > that Olivier has done a partial implementation of Eclipse on OSGi.
> >
>
> I have some questions about this...
>
> ...is this going to be added to CVS?
This is unclear. Initially I thought yes but Olivier reports that his
implementation is tied to a particular OSGi implementation that cannot be
made available. In the end it may be just as well that we start with a
clean slate and what he/others have learned and move ahead.
> ...what is used for the OSGi layer? Anything this group can use for an
> initial OSGi implementation?
see above.
> ...I thought there were some questions regarding whether the Eclipse
plugin
> layer should be implemented on OSGi or whether the OSGi layer should be
> implemented on top of the Eclipse plugin layer (an enhanced Eclipse plugin
> layer with support for dynamic plugins). Is there an 'official' decision
> regarding the approach here?
I believe the initial direction was to run Eclipse on various runtime
frameworks (e.g., OSGi, JMX/Jboss, Avalon, ...).
side note: OSGi itself is not a stated goal of Equinox. It is one
possibility. Since people with OSGi backgrounds/interests seem to be more
numerous at the moment, we should go with the flow and use OSGi as the
"stalking-horse" to help flesh out the problems/issues etc. I would like us
all to seek out and encourage folks with knowledge of other runtime
frameworks to join in the discussions and work on the problems.
> Thanks,
> ted
> PS: Wow, I left for a fews days and missed a lot!
That'll teach you...
|
|
|
| Re: let's get started! [message #7903 is a reply to message #7839] |
Wed, 05 March 2003 23:03 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Jeff answer is pretty much on the money.
I cannot for the moment put the OSGi implementation I used
onto the public open source domain, not so far...
But I can overflow the newsgroup with comments and theories
resulting from more than 7 months of work on the subject... :-)
Anyway, my port of Eclipse was an experiment to understand
the issues... it is not usable as is. Mostly, the problem to use
OSGi as a class loader framework for Eclispe resides in the following:
- different versioning model
- different dependency schemes
- different class loading schemes.
As stated in other posts. OSGi assumes Java versioning with
full backward compatibility. Eclipse assumes major releases to be
incompatible. This changes the algorithm for updating or installing
a bundle drastically.
Eclipse has dependencies on plug-in, mixing API and implementation.
OSGi ensures more independence through dependencies on API only.
So an OSGi cannot support the current semantics of Eclipse, binding
plug-ins together... it can only match imports and exports of packages.
Moreover, OSGi assumes a global name space for exported packages...
all imports are satisfied from that name space... Eclipse assumes that the
loaded classes flows through the "require" graph... so sharing is local
between one exporter and the ones transitively requiring that exporter.
This also dramatically impacts how dynamic loading and unloading
needs to be done... What I would like to see is a minimal restructuring
of the Eclipse code base within Equinox so that we have an explicit
layer very similar to OSGi framework... above which the plug-in registry
would sit. That framework could then implement either behavior... so that
we can compare. At least, everthing else would be shared... that is,
all the modifications and extra support for dynamicity above the plug-in
registry.
I will start giving this a crack pretty soon... we will see.
Cheers,
--
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:b45rao$fqp$1@rogue.oti.com...
>
> "ted stockwell" <ted.stockwell@acxiom.com> wrote in message
> news:b456pf$vjc$1@rogue.oti.com...
> >
> > "Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
> > news:b42mks$5ds$1@rogue.oti.com...
> > >
> > > OSGi
> > > ====
> > > We already have a start in
> > > that Olivier has done a partial implementation of Eclipse on OSGi.
> > >
> >
> > I have some questions about this...
> >
> > ...is this going to be added to CVS?
>
> This is unclear. Initially I thought yes but Olivier reports that his
> implementation is tied to a particular OSGi implementation that cannot be
> made available. In the end it may be just as well that we start with a
> clean slate and what he/others have learned and move ahead.
>
> > ...what is used for the OSGi layer? Anything this group can use for an
> > initial OSGi implementation?
>
> see above.
>
> > ...I thought there were some questions regarding whether the Eclipse
> plugin
> > layer should be implemented on OSGi or whether the OSGi layer should be
> > implemented on top of the Eclipse plugin layer (an enhanced Eclipse
plugin
> > layer with support for dynamic plugins). Is there an 'official'
decision
> > regarding the approach here?
>
> I believe the initial direction was to run Eclipse on various runtime
> frameworks (e.g., OSGi, JMX/Jboss, Avalon, ...).
>
> side note: OSGi itself is not a stated goal of Equinox. It is one
> possibility. Since people with OSGi backgrounds/interests seem to be more
> numerous at the moment, we should go with the flow and use OSGi as the
> "stalking-horse" to help flesh out the problems/issues etc. I would like
us
> all to seek out and encourage folks with knowledge of other runtime
> frameworks to join in the discussions and work on the problems.
>
> > Thanks,
> > ted
> > PS: Wow, I left for a fews days and missed a lot!
>
> That'll teach you...
>
>
|
|
|
Goto Forum:
Current Time: Sat Apr 27 03:06:53 GMT 2024
Powered by FUDForum. Page generated in 0.04286 seconds |
] 
Search
Help
Register
Login
Home
