[kepler-dev] OSGi presentation

Tristan King tristan.king at jcu.edu.au
Wed Jul 16 20:59:20 PDT 2008


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>
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
> 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 www: http://eresearch.jcu.edu.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080717/ddf870d0/attachment.html>


More information about the Kepler-dev mailing list