[kepler-dev] RFC new directory structure

Edward A Lee eal at eecs.berkeley.edu
Thu Mar 18 10:50:37 PST 2004

OK, but then the "look inside" mechanism probably needs to be adjusted
to find the source code... Perhaps you've done this already?


At 08:50 AM 3/18/2004 -0900, Matt Jones wrote:
>Here I disagree.  One of the most confusing things about the ptolemy tree 
>is that the source is spread out over many directories in the root.  It is 
>so non-traditional that it makes it much less approachable to a new 
>developer than the typical method of putting all source code in a src 
>directory.  The .class files do go in a separate tree (they build into the 
>"build" directory, and xml files and the like currently go into lib, 
>although that is under discussion.  Currently (AFAIK) the only things in 
>the src tree are *.java and *.cpp files.  I think we should keep this 
>Edward A Lee wrote:
>>We have avoided having a directory called "src" because in Unix
>>culture such directories are optional.  I.e., you don't need them
>>to run the software.  If you have a "src" tree, then there
>>should be a separate tree for .class and .xml files, which is a
>>hassle.  If you are releasing open source, there really isn't
>>any reason (that I see) to do this...
>>At 03:20 PM 3/17/2004 -0800, Xiaowen Xin wrote:
>>>David, Ilkay, Zhengang, Dan and I have discussed on the phone and over
>>>email the last couple of days about the directory hierarchy
>>>reorganization and have come to a rough consensus.  This will be a long
>>>email, so please bear with me =)
>>>The problem basically is that there is currently no clear organization
>>>of the files in the CVS repository.  Workflows are scattered around the
>>>lib/ directory for example, and it's not clear, looking at the
>>>repository, which files relate to SPA and which to one of the other
>>>Here's a pictorial view of how we would like to reorganize the
>>>repository.  I will be talking mostly about SPA, but the concepts should
>>>carry over to the other Kepler projects as well.
>>>- copyright.txt
>>>- build.xml
>>>- bin
>>>         - runVergil.bat
>>>         - runVergil.sh
>>>- build (directory used for compiling the sources)
>>>- docs
>>>- lib
>>>         - jar (directory for all the jars)
>>>         - dll (directory for all the dlls)
>>>- src
>>>         - org
>>>                 - ecoinformatics
>>>                 - geon
>>>                 - sdm
>>>                         - spa (directory for all the spa-related actors)
>>>                         - util
>>>- test
>>>- workflows
>>>         - spa (directory for spa workflows)
>>>         - seek
>>>         - geon
>>>So all the SPA related actors will be in the org.sdm.spa package.
>>>Currently there are some SPA actors in edu.ncsu.sdm, but this doesn't
>>>make much conceptual sense.  There's no reason to divide up SPA source
>>>files according to the organization that developed it, since all of SPA
>>>will be working closely together to create _one_ set of interrelated
>>>actors.  Zhengang will work on moving the actors from edu.ncsu.sdm to
>>>org.sdm.spa.  It's better to divide up the source files by project
>>>rather than by organization because the boundary between organizations
>>>is artificial and only serves to confuse things.
>>>Currently, there's a util/ directory in src/.  This isn't really
>>>consistent with our naming convention so far (i.e. putting source files
>>>in packages that reflect which project made them).  The argument for
>>>having a util/ directory has been that we'd like to put useful classes
>>>in there that can be shared between the projects.  However, this
>>>argument doesn't make much sense because theoretically, all of our
>>>actors could be shared between the projects.  So we'd like to move the
>>>files in util/ to org/sdm/spa/util.  If another project requires the
>>>functionality of those two classes, then it would have to include the
>>>org.sdm.spa.util package instead of simply the util package.
>>>After making these changes, all the SPA source files will be in
>>>org/sdm/spa, thus making it much easier to distinguish SPA and its
>>>contribution to Kepler.
>>>Currently, all the workflows are in lib/ and there are some that are not
>>>in CVS at all.  We would like create a top-level workflows/ directory to
>>>store all of the workflows.  spa, seek, and geon would be subdirectories
>>>under there.  Thus all SPA workflows will be put in workflows/spa/.
>>>Similarly, GEON and SEEK should probably do the same with their
>>>With this directory structure, it would be easy to tell which workflows
>>>are designed for which project, but we must also remember to check all
>>>of our workflows into CVS, and update them when/if they break.  Having
>>>PIW-full.xml, PIW-full_new_matt.xml, PIW-int-ex0.xml, and
>>>PIW-full_new.xml, as we do right now is just plain confusing!
>>>Currently the lib/ directory is a mess.  It appears to be the garbage
>>>bin, where everything is dumped if the author can't find a better
>>>container for it.  So we propose a series of steps to clean this up.
>>>1. There are two dll's in lib/.  There should probably be a subdirectory
>>>called dll/ under lib/ that contains these dll's.  The person who put
>>>these there should probably move them ...
>>>2. demos.htm and ptolemy-index.html should probably be moved out of lib/
>>>and into a more appropriate folder, probably into src/.
>>>3. Ilkay will dispose of lib/forBerkeley/ and lib/forSB/ folders or move
>>>them into the top-level test/ folder since they contain testing material
>>>and so don't belong in lib/.  Whoever's responsible for
>>>lib/ecoPipelines/ should probably do the same because that's testing
>>>material also as I understand it.
>>>4. Is everyone ok with our deleting makefile and makefile.lib from
>>>lib/?  These are also not library files, and we're not using makefiles
>>>any more.
>>>5. We should move runVergil.bat and runVergil.sh into a top-level bin/
>>>6. Does anyone know what lib/sample.dat and lib/scew-0.3.1.tar.gz are?
>>>Can we delete them?
>>>7. We will delete the lib/soap directory because it's empty, and there's
>>>already a lib/jar/soap that contains jar files.
>>>8. We need to do something about lib/testdata/ because it's not a
>>>library file.  I personally think it should be moved into the global
>>>test/ directory.
>>>9. We will move lib/workflow/ into the top-level workflows/ directory.
>>>The existence of src/exp/ seems a bit questionable.  It seems to stand
>>>for "experimental".  Maybe it's time to either make it stable and
>>>incorporate it into an existing project, or delete it ...
>>>Please comment!  If nobody objects to the proposed restructuring here, I
>>>can do nothing but assume everybody loves it =)  We'd like to get this
>>>finalized as soon as possible, which would make it easier to create a
>>>distribution.  Matt will be back next week from travel I believe, and it
>>>would be wonderful to have some kind of rudimentary installer for him.
>>>kepler-dev mailing list
>>>kepler-dev at ecoinformatics.org
>>Edward A. Lee, Professor
>>518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>>phone: 510-642-0455, fax: 510-642-2739
>>eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>>kepler-dev mailing list
>>kepler-dev at ecoinformatics.org
>Matt Jones                                     jones at nceas.ucsb.edu
>http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
>National Center for Ecological Analysis and Synthesis (NCEAS)
>University of California Santa Barbara
>Interested in ecological informatics? http://www.ecoinformatics.org

Edward A. Lee, Professor
518 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0455, fax: 510-642-2739
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal

More information about the Kepler-dev mailing list