[kepler-dev] Independent developer SDK for Kepler?

Christopher Brooks cxh at eecs.berkeley.edu
Wed Jun 6 07:11:48 PDT 2007

Hi Tony
This is an interesting idea that is between providing static releases
and dynamic CVS.  However, my personal opinion is that people should
pick one or the other.  The reason is that if people grab a copy of
the CVS trees and there is a small bug, then they need to grab another
copy of the CVS trees and if there is a small bug . . .
As you can see, I've been down this path before :-)

Another middle ground is to provide nightly releases that may or may
not be stable.  The Ptolemy project does this, though I don't think
people use them that much.

I'm very much opposed to people making copies of CVS trees, it flies
in the face of what open source is about.  For example, for fairly
good reasons, Kepler duplicates code in the Ptolemy tree.  However,
this is a maintenance headache, since when those files change in
Ptolemy, someone needs to merge the changes in by hand.  Yes, version
control should handle this for us, but it does not.

About the system start up time.  Ptolemy starts much more quickly than
Kepler because Ptolemy does not have the ability to search the actors.
Ptolemy does not create all the actors in the graph editor at start
up, it only creates them as a branch in the actor tree browser is
opened.  The downside of the Ptolemy method of lazy loading is that
we cannot quickly query the actors.  We've discussed various ideas
around this, probably the best would be to have proxies or a database
of the cached actor info that was quickly available at startup and
then do lazy loading (perhaps in the background).

You are correct in that loading from jars is usually faster than
loading from discrete .class files.  I have not tested this lately,
but it was the case awhile ago.  The downside is for developers
because of the time necessary to build jar files.  I'm not aware of
many jar files containing both .class and .java files.  In Ptolemy, there
are a few .java files in .jar files, I think that perhaps the Copernicus
Soot jar files have .java files.  It might be good to visit the .java 
in .jar files issues and see how bad it is.

Anyway, the above are just my $0.02.  Interesting idea about a SDK,
but I think we should stick with either releases or CVS access.



    On another topic .. related to building src/class jars ...
    Since many Actor developers don't (and probably shouldn't) have full access
    to your CVS repository it would be expedient to create a software developer
    kit (SDK) build of Kepler.  You'd add a new ant task that creates a single
    downloadable ZIP that includes separate jars for compiled .class files, JNI
    files, config/resource files, icons/image files and .java source files and
    instructions to the create an Eclipse project file that uses these jars.
    Developers then only need to create a very small Eclipse project that they
    can check in to their **local** CVS/Subversion repository.  Their
    respository would now only need your jars + their source code + a tiny
    build.xml.  They can then link your source code jars to your .class jars in
    the Eclipse project to view (but not edit) the snapshot of the Ptolemy and
    Kepler source code.  This would remove considerable setup time and effort i
    rebuilding the 7,000+ classes and most importantly would allow independent
    local version control.  Go one better and include in the ZIP a sample
    Eclipse project containing the HelloWorld actor sample.  This would ensure
    that the developer had all the needed folders (like src/actors) setup to
    build their new actors.  
    I suspect that you might then need a different mechanism to ensure that
    developers don't use conflicting LSIDs.  
    I have considered doing this myself but my lack of familiarity with all the
    pieces of the Kepler puzzle would make this a bit risky for me to safely
    Thanks for Kepler,
    Tony O'Hagan
    Kepler-dev mailing list
    Kepler-dev at ecoinformatics.org

More information about the Kepler-dev mailing list