[kepler-dev] Kepler user interface + relation to Recito
tristan.king at jcu.edu.au
Tue Jan 22 15:44:40 PST 2008
You can view the individual source files here:
I use maven to build the classes, if you check out the whole project
there is a pom.xml file in the root. I use subversion, so to check the
project out (sorry these instructions are linux specific, you'll have to
figure it out yourself if you use windows):
svn co https://dev.archer.edu.au/projects/kepler/svn/WebPortal/trunk/
then from the hydrant/ directory do:
this will check your local maven repositories and download the required
dependencies and give you instructions on how to load the kepler and
ptolemy jars as well. It also requires the jython jar. but if you remove
the jython dependency from the pom.xml (lines 29 - 34) and remove the
ReplacementManager.java file (and all references to it) you can go
without it (but it may be simpler to just find the jython jar). If i
recall correctly you'll have to manually download jfree chart as well,
but maven will let you know for sure.
you'll then end up with a jar file at target/hydrant-1.0-SNAPSHOT.jar
which you can add to your kepler classpath then use the "instantiate
component" menu option to load them onto your canvas.
I haven't made kar files for them, because i never intended them to be
let me know if you have any problems
On Tue, 2008-01-22 at 09:25 -0500, Paul Allen wrote:
> Hi Tristan,
> I'm wondering if you would be willing to share the new actors mention
> below. I.e. the ones that provide web-enabled output.
> At 08:17 PM 11/19/2007, Tristan King wrote:
> >This is a big problem i have with running workflows on my web portal.
> >currently i've built a MoMLFilter that replaces actors such at Display
> >and XYPlotter with new actors i've built to store the outputs as web
> >enabled output (i.e. just text for the Display, and as a PNG for
> >This is all well and good. but it requires a lot of extra coding and
> >work arounds, and it means i need to build replacement actors for each
> >type of output actor. Having standard, non-gui depended, subscription
> >based outputs would be a life saver for me.
More information about the Kepler-dev