[kepler-dev] OSGi presentation
Aaron Schultz
aschultz at nceas.ucsb.edu
Thu Jul 17 17:42:20 PDT 2008
Oh right, thanks for checking me on that Tim.
"Everyone" who is interested in the high level architecture or involved
with developing the core or breaking out/developing extensions. And by
"study" I mean "looking to see what is there and getting an idea of the
different pieces and what can be done with modularization in OSGi".
Also, if you are messing around with a prototype it makes a good reference.
As for the long run I'll take a best guess with the current knowledge I
have. It is a good question and starts to get into implementation so I
will assume an implementation that replaces KARs with OSGi bundles for
individual actors as well as actor libraries. In this scenario I don't
think end users would need to understand the details of OSGi. But they
may need to be conscious of the fact that the new actor they are
developing is dependent on other modules in the system.
For example, a brand new R actor would need to depend on the kepler-R
bundle (and the kepler-core bundle and the ptolemy-core bundle, which
would be gotten for free if the developer of the kepler-R bundle
remembers to include the "uses" directive on their package exports which
allows for inter-package dependencies - see section 3.6.4 of spec). So
the end user developing the new R actor might have a few options for
doing this.
They could choose to associate their actor with an existing standard
library of R actors. In which case the dependencies would be inherited
by the new actor.
They could choose another individual R actor and inherit the
dependencies from there.
They could get a list of all the bundles they have in their system and
select the R bundle as a dependency.
They could choose to just depend on the configuration of Kepler that
they are currently running and inherit dependencies on all of the
bundles in their system during the development of their Actor. Then
when they are finished with development they could run an optimizer to
trim off all the dependencies that are unused. Eclipse PDE will do this
for you, which means that code already exists in a bundle somewhere with
a defined api and could be implemented as a part of the actor SDK.
Or you could try your best to completely hide dependencies and make them
transparent to the user by automating that last option in the background
or by doing something else that hasn't come to mind yet... :)
Aaron
Timothy McPhillips wrote:
> Hi Aaron,
>
> You said you'd recommend that "everyone take some time to study
> section 3 of the OSGi spec." Can you be more specific than 'everyone'?
> Who should read the spec? All those who will write Kepler actors in
> the future? All prospective developers of other types of Kepler
> extensions? Those interested in discussing architectural decisions
> for Kepler at a high level? Or just those doing the hands-on work to
> move Kepler to a new extension framework? And who must understand the
> OSGi standard in the long run if Kepler is to adhere to it?
>
> Thanks!
>
> Tim
>
> On Jul 17, 2008, at 12:21 PM, Aaron Schultz wrote:
>
>>
>> Hi Tristan,
>>
>> I think the bottom up approach would be a slightly more ideal way for
>> converting an existing project to OSGi bundles if there weren't a lot
>> of developers and existing infrastructure already in place. I also
>> remember hearing in one of the presentations at the Equinox Portal
>> (maybe it was this one
>> <http://www.redmonk.com/cote/2007/12/07/eclipse-equinox-and-component-oriented-development-overview-and-demo/>)
>> that for big projects the right way to go is to start by breaking one
>> big bundle into two and then into three, and so on. So I think Matt
>> is correct in that we need to try to not disturb the existing system
>> too much as we proceed. The nice thing about moving to OSGi bundles
>> though is that you don't really need to change any of the existing
>> code to do it. So you shouldn't run into the kind of code breaking
>> that you mention below. The only code that needs to be changed is
>> anywhere a file is accessed from disk and anywhere that we want to
>> put extension points (and perhaps one or two other places that we'll
>> uncover as we go). The challenge really is the physical separation
>> of the code and correctly wiring the dependencies between the new
>> bundles that get created.
>>
>> As for Maven, you can think of the collection of all the OSGi bundle
>> Manifest files as equivalent to the pom.xml. The "Master" dependency
>> information is kept in the Jar manifests of the particular set of
>> bundles that you are building under the headers Require-Bundle,
>> Import-Package, Export-Package. Then Maven with the OSGi plugin or
>> perhaps another method for building a particular bundle configuration
>> would do it using the manifests of the bundles and not any other data
>> kept in an external file like the pom.xml (although the Maven plugin
>> may auto generate a pom.xml from the manifests or something like
>> that, I haven't looked at this yet). This is very important since
>> both the build system and the run-time system needs the dependency
>> information in order to work properly.
>>
>> There is enough to learn about OSGi that I'd recommend everyone take
>> some time to study section 3 of the OSGi spec and go through some
>> tutorials from the many resources available on the web until you have
>> your own working prototype with a couple bundles, fragments, and
>> extensions. Learning in this environment is definitely preferred to
>> the large bundle environment as operations on large bundles can be
>> very slow and cumbersome and not at all a fun way to learn (as I can
>> attest).
>>
>> I also think having a sound understanding of the class loader
>> architecture will help alleviate frustration.
>> And probably most others are familiar with the difference between
>> accessing a resource through the classpath of a jar as opposed to
>> just reading it from disk, this I had to figure out and spent some
>> time getting a good handle on.
>>
>> Also, since I'm on a role here, I think we want to try to stick to
>> the OSGi standard as much as possible. Eclipse has a lot of good
>> documentation and extra features to it so it may be tempting to
>> stray. But I think we want to avoid using too many special features
>> of Eclipse (like all the RCP tools) and try to keep everything as
>> compatible with the OSGi standard and the other available frameworks
>> as possible (unless at some point we decide that the advantages of
>> marrying a platform outweigh the disadvantages).
>>
>> Aaron
>>
>>
>> Tristan King wrote:
>>> Ok, so OSGi looks like it'll solve a bunch of problems like easy
>>> loading of actor packages and addons etc. I really think the first
>>> step is to modularise kepler and ptolemy. Also, I think such a
>>> change needs to be done bottom up. Working from the existing base
>>> and trying to modularise things is difficult due to the large amount
>>> of things that depend on each other within ptolemy.
>>>
>>> For example, when playing with my actor-IO idea, simply changing the
>>> XYPlotter actor to use the actor-IO package broke a whole range of
>>> other things inside ptolemy that depend on that actor.
>>>
>>> Of course, moving the code bit by bit will still have these
>>> problems, but it allows you to make a change that would normally
>>> break things, but still have compilable code. You can move the
>>> dependencies over at a later date and deal with the changes that
>>> need to be made to them then rather than when you're trying to mess
>>> with the base code.
>>>
>>> I think that most of this work should probably be done in ptolemy
>>> since it is the core of kepler. Trying to build modularity around
>>> ptII as it is, i think, is pointless.
>>>
>>> So I would tackle this in the following way:
>>> * make a new branch from the ptII trunk (called something like
>>> ptII-osgi or ptII-modular)
>>> * set it up for maven (i.e. create the pom.xml and the src/...
>>> directories)
>>> * start moving the ptII code bit by bit into maven.
>>>
>>> The main advantage of this over starting an empty project is that
>>> maven provides you with an empty workspace to start moving code into
>>> but all the original code is still available. And when you move a
>>> file in from ptII into the maven source hierarchy, the change-log of
>>> the file is preserved.
>>>
>>> As for the OSGi stuff, I need to do a bit more research into it to
>>> understand it fully so i can't yet say where it should be put it.
>>> maybe a base OSGi framework should be built which we will start to
>>> build ptolemy on top of, or maybe we can just focus on modularizing
>>> ptolemy and worry about the OSGi stuff when we find a solid use case
>>> for it.
>>>
>>> The work Christopher's done on breaking up the
>>> PtolemyPackageDependencies page of the kepler wiki seems like a good
>>> place to start with modularising things. I think the Kore, and
>>> probablybits (if not all) of the Actor Kore and Domains packages
>>> should be enough to start working on things. From those packages,
>>> actor libraries should be able to be built (using the Kore package
>>> as a dependency rather than writing the actors into the core) where
>>> the first use of OSGi might be put into place.
>>>
>>> As for my maven work with ptII, the biggest problem left to tackle
>>> is the tests. I dunno if maven is able to run the tcl tests, I think
>>> it should be able to, but i need to do a bit more research into
>>> exactly how. worst case scenario is that the tests have to be
>>> re-written as junit tests which would be a pain, but maybe not so
>>> bad if we are working on modularising ptII bit by bit.
>>>
>>> So for now, I'm gonna look into getting the ptII tests to work from
>>> maven while we discuss how we should proceed with the rest of this.
>>> Hopefully we can get the modularisation of ptolemy/kepler going
>>> soon. it's gonna be a long and tiring journey but i can see nothing
>>> but advantages at the end.
>>>
>>> On Tue, Jul 15, 2008 at 11:40 AM, Aaron Schultz
>>> <aschultz at nceas.ucsb.edu <mailto:aschultz at nceas.ucsb.edu>> wrote:
>>>
>>>
>>> Hi everyone,
>>>
>>> I'm going to go through the presentation on the OSGi solution
>>> for a Kepler architecture this Wednesday at 3:30 pm PST in the
>>> Marratech Auditorium. Please feel free to join in and bring
>>> questions.
>>>
>>> *http://tinyurl.com/5zgyph
>>>
>>> http://help.nceas.ucsb.edu/Marratech
>>>
>>> *Aaron
>>> _______________________________________________
>>> Kepler-dev mailing list
>>> Kepler-dev at ecoinformatics.org <mailto:Kepler-dev at ecoinformatics.org>
>>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>>>
>>>
>>>
>>>
>>> --
>>> Tristan King
>>> Research Officer,
>>> eResearch Centre
>>> James Cook University, Townsville Qld 4811
>>> Australia
>>>
>>> Phone: +61747816902
>>> E-mail: tristan.king at jcu.edu.au <mailto:tristan.king at jcu.edu.au>
>>> www: http://eresearch.jcu.edu.au
>>
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org <mailto:Kepler-dev at ecoinformatics.org>
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
More information about the Kepler-dev
mailing list