[kepler-dev] Problems for building Kepler

Matthew Brooke brooke at nceas.ucsb.edu
Tue Oct 25 16:03:27 PDT 2005


Zhijie

 >> Do you have any idea on how to add actors into Kepler now? It
 >> seems I really need an updated tutorial for the new Kar issue. B->

I believe the procedure for adding actors is unchanged, apart from the 
additional step of needing to add their definitions to one of these 
files: configs/ptolemy/configs/kepler/actorLists.moml or directorList.moml

For details, see the following email that Chad sent out, regarding the 
KAR update:


-------- Original Message --------
Subject: [kepler-dev] IMPORTANT: ksw system now in use
Date: Thu, 29 Sep 2005 15:02:34 -0700
From: Chad Berkley <berkley at nceas.ucsb.edu>
To: Kepler-Dev <kepler-dev at ecoinformatics.org>

Hi All,

I just checked in all of the needed code and configurations to make the
ksw system fully operational in the head of CVS.  It seems to be working
pretty well now so I think it's time for everyone to start using it.
I'm not promising that it's bug free, so please let me know if you see
any problems.  Below is a complete description of how it now works and
how you get the system to build (it's a bit different now).

Building Kepler
---------------
Kepler now depends on ksw files to load actors and directors into the
actor library.  I built an automated system for building the ksw files.
   The files configs/ptolemy/configs/kepler/actorLists.moml and
directorList.moml lists out all of the ksw files that will be built.  If
you want to add an actor or director to the system, you edit one of
these two files.

To build kepler, do a full cvs update, then delete your $HOME/.kepler
directory.  On winXP this is c:\Documents and Settings\<your
name>\.kepler.  On linux and other unices, it is /home/<user>/.kepler.
This directory must be empty to start the build process.

Next, run 'ant buildkswlib' from within the kepler directory.  This will
build the library of ksw files.  You'll see a bunch of text scrolling
down the screen telling you that it's building ksw file "X" and what the
assigned id is.

Next just run 'ant run-dev' (or startup kepler your favorite way).  Note
that the directory $HOME/.kepler/ksw must now be in your classpath.
Kepler should startup.  You'll notice a ton of messages streaming down
the terminal.  This only happens the first time you start kepler after
adding new ksw files.  Kepler is caching each ksw file and processing it
into the actor library.  The first startup may take a minute or so.  The
next time you start kepler, you'll be back to the normal (not so fast,
but faster) startup time.

Please check to make sure all of your favorite actors are in the actor
library and are categorized correctly.  I had to hand copy/paste all of
the annotation information and i might have messed some of them up in
doing so.  I looked it over pretty well, and didn't see any glaring
errors, but i still might have missed something.  Just let me know if I did.

That's all for building kepler.  If you run into any problems, let me know.

How it all works
----------------
Kepler now builds all of it's internal structures dynamically instead of
relying on the basicKeplerActorLibrary.xml and Annotations.owl files in
the configs dir.  If you look at the basicKeplerLibrary.xml file, you'll
see a property that points to 2 different directories on your machine
(kepler/ksw/actors and kepler/ksw/directors).  There are two only for
organization, there could just be one.  When kepler starts up, it looks
in those directories for any ksw files that it hasn't already cached.
if it finds one, it copies it to the .kepler/ksw directory and explodes
its contents.  The objects inside are registered with the LSID and cache
sub systems and any annotations are read into the annotation sub system.
   Kepler is then started where it uses all of the automatically built
structures instead of the static moml that it used to use.

A ksw file can be built automatically from a configured actor on the
canvas.  You can rt. click on the actor and choose "build KSW from
actor".  It will ask you where you want to save the ksw file and what
annotation you want to assign to it (note you can only create a
'transport' ksw at this time).  This dialog is pretty crude now, but
will be improved.  Once you click ok, the ksw file is saved and read
into the system where it is reloaded into the actor library for use.

You can also build a ksw file from an actor that is not already in the
library.  To do this, use the class org.kepler.ksw.KSWCreator.  It has a
command line interface for building your ksw.  Eventually, you'll be
able to do this through the kepler gui.

The easiest way to build a ksw file right now, is to add the metadata
about your actor to the actorList.moml file then run 'ant buildkswlib'.
   Note that all LSID's must be unique and well formed.  If you specify
an lsid that does not use the 'localhost' authority, the object must
actually be obtainable from the location pointed to by the LSID.  For
instance, if you specify an LSID of
urn:lsid:lsid.yourhost.com:actor:1:1, there better be an actual lsid
authority at lsid.yourhost.com that points to where the object exists.
If not, you'll get an error.

Here's an entity entry in the actorList.moml file with some C style
comments explaing the different parts:
<entity name="GridFTP" class="ptolemy.actor.TypedCompositeActor">
    //the name is the name of the actor as it will show up in the
    //actor library.  the class is the class for this entity.
    //confusingly, atomic actors are TypedCompositeActors...
    <property name="entityId" class="org.kepler.moml.NamedObjId"
              value="urn:lsid:localhost:actor:173:1"/>
    //the entityId is the lsid of the actor
    <property name="documentation"
              class="org.kepler.moml.DocumentationAttribute">
    </property>
    //the documentation attribute isn't finished yet.  matt
    //came up with a format, but i haven't yet implemented
    //it.  Docs will be added to all actors soon.
    <property name="class"
              value="org.nmiworkflow.GridFTP"
              class="ptolemy.kernel.util.StringAttribute">
    //the class property is the actual implementing class of this
    //actor.  In this case, org.nmiworkflow.GridFTP.
      <property name="id" value="urn:lsid:localhost:class:1030:1"
                class="ptolemy.kernel.util.StringAttribute"/>
      //the id property within the class is the lsid of the
      //implementing class itself.
    </property>
    <property name="semanticType0"
       value="http://seek.ecoinformatics.org/ontology#GridFunctionActor"
       class="org.kepler.sms.SemanticType"/>
    //one or more semantic types can be added to classify the actor.
    //right now, the namespace 'http://seek.ecofinformatics.org/ontology#'
    //must be used.  soon, you will be able to specify an actual
    //lsid to an ontology in the system so that more than one
    //ontology can be used.  note that the name of the
    //semanticType property must be unique, hence the semanticType0,
    //semanticType1... naming scheme.
    <property name="semanticType1"
value="http://seek.ecoinformatics.org/ontology#GlobusExternalInputActor"
      class="org.kepler.sms.SemanticType"/>
</entity>

Note that you no longer need to edit the basicKeplerActorLibrary.xml and
annotations.owl files.  In fact, i will be removing them soon, so don't
add anything to them you don't want removed.

To do
-----
Here's an (incomplete) list of things that will be implemented that
aren't yet:
-Dynamic class loading/unloading for multiple versions of the same actor
-Building a ksw from an entire workflow
-read the ontology information from the cache instead of using an xml
namespace
-Be able to add a ksw directly to a remote actor repository
-Be able to get a ksw directly from a remote actor repository
-Probably a bunch of other stuff that I can't think of right now.

Hopefully this all works for everyone.  Please let me know on irc or via
email if you see weird behavior.  I should probably add a sub-category
to bugzilla for this.  It's a huge change to the way kepler works and I
think a big improvment so please be patient with any problems there
might be.

Thanks,
chad

_______________________________________________
Kepler-dev mailing list
Kepler-dev at ecoinformatics.org
http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev

-- 

---------------------------------------------
Matthew Brooke, Ph.D.
Marine Sciences Research Building, Room #3407
University of California
Santa Barbara, CA  93106-6150
ph: (805) 893-7108   fx: 805-893-8062
brooke at nceas.ucsb.edu
---------------------------------------------


More information about the Kepler-dev mailing list