[kepler-dev] OSGi presentation

Thu Jul 17 14:50:16 PDT 2008

Hi Tristan,
How I would handle the Tcl Tests is write a JUnit test that
reads a tcl file and invokes the Tcl Interpreter.
Ptjacl is an extension of Jacl.  Writing Java that loads
the file is fairly straightforward.  $PTII/doc/install.htm says:
<h3><a name="Jacl">Jacl</a></h3>
Jacl is a 100% Java implementation of Tcl that we use for testing 
Ptolemy II.

Each Java directory contains a <CODE>test</CODE> subdirectory that contains
Tcl files that use Jacl to test the Ptolemy II Java code.

  <p>Jacl is <B>only</B> necessary if you are planning on running
the Ptolemy II test suite.

  <p>We ship a customized version of Jacl called Ptjacl.
The primary difference between Ptjacl and Jacl1.1 is that Ptjacl
is shipped as one jar file.

  <p>The Ptjacl jar file at <CODE>$PTII/lib/ptjacl.jar</CODE>
is shipped with Ptolemy II.

  <p>For more information about Jacl and Tcl Blend, see
<menu>
<li> <a href="http://tcl.activestate.com/software/java/" 
target="_top">Activest\
ate.com Jacl and Tcl Blend page</a>.

<li> <a href="http://ptolemy.eecs.berkeley.edu/~cxh/java" 
target="_top">Christo\
pher Brooks' Java Page.</a>
<li>If you have a read/write account on 
<code>source.eecs.berkeley.edu</code>, \
then the sources for ptjacl are available via cvs:
<pre>
cvs -d :ext:source.eecs.berkeley.edu:/home/cvs_chess co tcl
</pre>
or
<li> <a href="coding/tcljava.htm"><CODE>java::</CODE> man page</a>
</menu>

_Christopher

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
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev