[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?
Edward
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
>structure.
>
>Matt
>
>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...
>>Edward
>>At 03:20 PM 3/17/2004 -0800, Xiaowen Xin wrote:
>>
>>>Hi,
>>>
>>>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
>>>projects.
>>>
>>>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
>>>- README
>>>- 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
>>>workflows.
>>>
>>>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/
>>>directory.
>>>
>>>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.
>>>
>>>Xiaowen
>>>
>>>_______________________________________________
>>>kepler-dev mailing list
>>>kepler-dev at ecoinformatics.org
>>>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>>
>>------------
>>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
>>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>
>--
>-------------------------------------------------------------------
>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