[kepler-dev] OSGi presentation

Thu Jul 17 12:36:19 PDT 2008

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) 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> 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
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/ 
> kepler-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080717/0008e054/attachment-0001.html>