[kepler-dev] OSGi presentation

Thu Jul 17 08:59:17 PDT 2008

Yes, this investigation into OSGi has been enlightening.  We are also 
considering other, lighter-weight possibilities that may require less 
refactoring.  There are also some questions about OSGi that need to be resolved, 
such as whether the overhead in loading these components is acceptable when 
large numbers of components are involved.

Although I am enthusiastic about the modularization implied by OSGi, I agree 
with Edward that we need to be careful to have a clear trajectory that lets us 
maintain continuity with the current Ptolemy and Kepler systems.  We've 
discussed a transition strategy that would keep much of the current system in 
place as a few large bundles, and then  incrementally factor out independent 
components to improve system modularization into independent bundles.  I think 
this is a better strategy than Tristan's proposal, which is likely to be far 
more disruptive because it creates a system with little functionality that needs 
to be built back up and may not gain complete functionality present in the 
current system for quite a while.

Matt

Edward A. Lee wrote:
> I believe this is the right way to go...
> Let's proceed cautiously so that we avoid forking a separate
> version of Ptolemy II... It's bad enough that Kepler's UI doesn't
> allow inclusion of such (rather central) actors as Case...
> It could get much worse if we fork a new version.
> I hope you and Christopher will coordinate closely.
> 
> Edward
> 
> 
> At 08:59 PM 7/16/2008, 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 <<mailto:aschultz at nceas.ucsb.edu>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://tinyurl.com/5zgyph
>>
>> http://help.nceas.ucsb.edu/Marratech
>>
>> *Aaron
>> _______________________________________________
>> Kepler-dev mailing list
>> <mailto:Kepler-dev at ecoinformatics.org>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: <mailto:tristan.king at jcu.edu.au>tristan.king at jcu.edu.au www: <http://eresearch.jcu.edu.au>http://eresearch.jcu.edu.au 
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at ecoinformatics.org
>> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> 
> ------------ 
> Edward A. Lee
> Robert S. Pepper Distinguished Professor
> EECS Dept., 545Q Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
> phone: 510-642-0253, fax: 510-642-2845
> eal at eecs.Berkeley.EDU, http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html  
> 
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
> 

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matthew B. Jones
Director of Informatics Research and Development
National Center for Ecological Analysis and Synthesis (NCEAS)
UC Santa Barbara
jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~