harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tian galaxy <harmonymail...@gmail.com>
Subject Re: [GOSP]Proposal For OSGi
Date Fri, 03 Apr 2009 01:58:58 GMT
MingJian
Hi ,
Thanks
To your second question ,I am a bit confused by that too
As far as I know ,the booting procedure is not specified in the OSGi
spec.There are some useful informantion in the doc of implementations,such
as Equinox and Felix .
Take Felix for example ,you could boot it by standard procedure or by custom
.But there should always be a host program to start lanch and do some
initial work.  For a large program such as eclipse you can first run the
host program and then the embeded OSGi .But what is the case for small one
?For a simple "hello world ",it is unnecessary and unwise to sun a host
program much larger. Where should be the host program reside in Harmony or
should it reside in harmony?Or I just got the wrong idea about the "Harmony
OSGi-ed".

For the first one, since Harmony is highly modularized in the Vm and
library ,so it is a good thing for OSGi I think.
Third , no...

Tian Yu


2009/4/2 Jin Mingjian <jin.phd@gmail.com>

> Tian, good idea for proposal:) I am a bit familiar with OSGI:) I'd
> like to some questions,
>
> 1. How do you think the the functionality of already existed osgi
> things in current harmony?
> 2. How do you think the starting point of osgi service in the JVM
> booting sequence?
> 3. Do you have some use cases/scenarios about your four subtasks?
>
>
>
> 2009/4/2 tian galaxy <harmonymail.ty@gmail.com>:
> > Hi All :
> >
> > My name is Tian Yu ,I am a post graduate students from Shanghai Jiaotong
> > University .
> > I have just submit proposal for the summer code on Harmony OSGi.I want to
> > send all of you a copy of my proposal cause I know my plan could not be
> the
> > best one and need further improvement .So suggestions and comments of any
> > kind is welcome and will be appreciated .
> > I paste the detailed description below .
> >
> > *Detailed Description:*
> >
> > OSGi has a lot of advantages due to its ability to manage modules'
> > dependences and the service it provided,like you could register different
> > versions of bundles of the type simutaneously and let the user to choose
> > according to version numbers ,not the classpath.
> >
> > Apache Harmony JRE implementation has already been designed to be
> > modularized and least coupled amongest the module .
> >
> > If we could integrate the two together , we will bring great  flexibility
> to
> > the development and update of Harmony.And more importantly this will be
> more
> > attractive to users for it is more easy to use Since you could pick which
> > module, which version , which package to use .More than one version of
> the
> > this same module could also be used in one application.
> >
> > So this is a very meaningful and interesting project .
> >
> > I already have some draft ideas of how to implement this but any
> suggestions
> > and comments are welcome and will be appreciated.
> >
> > I think our project could be further divede into four subtasks
> >
> > Subtask 1: As we  all know there are already several successful
> > implementations of OSGi  ,the most popular ones are Equinox ,Knopferfish
> > ,Felix .I think since Equinox and Felix are more related to Harmony ,we
> > could investigate on them to see how they could help us on this if
> > permitted. (I have installed both of them on my PC and  run some small
> > programs I wrote on them .I found both of them are easy to use , more
> > impressived by OSGi itself.)
> >
> > Subtask 2: Though the modularization structure of Harmony has made this
> > project a lot easier than it should be , there also are  many tough
> issues
> > we should handle.The dependecies issue if one the main issues should be
> > concerned with.As the ability to handle dependecy is one of main
> attributes
> > of OSGi , the development of dependency structure is very important .I
> think
> > harmony may already has many information and conclusions of the mutual
> > dependency between modules .So the work is to develop the dependency
> > structure suits OSGi and Harmony best . I think its necessary to make a
> more
> > comprehensive investigation on the inner structure of Harmony .
> >
> > Subtask 3: With 3 month it is hard to make huge changes .So we may borrow
> > some ideas of the implementation of J2EE ,as  to add an extra interface
> to
> > the class loader and make some adaptations .First of all , a bundle to
> > manage the OSGi itself is needed and should be loaded first .This module
> > should be able to manage the information of each bundle such as dependecy
> > ,and should be able to provide services to core to OSGi (Fisrt to
> implement
> > the functions very core in the OSGi spec then add more). When we need
> extra
> > classes to load into the VM , we should load it through the OSGi manage
> > bundle:first examine which package , bundle the class belongs to  in the
> > list of registered bundles using dependency information then load the
> > specified package .
> >
> > Subtask 4 : We could incorporate some module into Harmony to help the
> > development of OSGi programm ,as what the "bnd" do (if there is still
> enough
> > time ).This could futher reveal Harmony's advantage and feature as an
> > OSGi-ed JDK.
> >
> > Time available :
> >
> > At least 3 month(May-August) .Actually could start to prapare any time
> > before that  .More than 5 hours one day .
> >
>

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message