[kepler-dev] OSGi presentation
cxh at eecs.berkeley.edu
Thu Jul 17 14:50:16 PDT 2008
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:
Jacl is a 100% Java implementation of Tcl that we use for testing
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
<li> <a href="http://tcl.activestate.com/software/java/"
ate.com Jacl and Tcl Blend page</a>.
<li> <a href="http://ptolemy.eecs.berkeley.edu/~cxh/java"
pher Brooks' Java Page.</a>
<li>If you have a read/write account on
then the sources for ptjacl are available via cvs:
cvs -d :ext:source.eecs.berkeley.edu:/home/cvs_chess co tcl
<li> <a href="coding/tcljava.htm"><CODE>java::</CODE> man page</a>
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
> 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.
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org <mailto:Kepler-dev at ecoinformatics.org>
> Tristan King
> Research Officer,
> eResearch Centre
> James Cook University, Townsville Qld 4811
> Phone: +61747816902
> E-mail: tristan.king at jcu.edu.au <mailto:tristan.king at jcu.edu.au> www:
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
More information about the Kepler-dev