[kepler-dev] Re: [SDM-SPA] RFC new directory structure
Matt Jones
jones at nceas.ucsb.edu
Thu Mar 18 10:04:36 PST 2004
Agreed. But....we haven't formally started code reviews yet, which is
the basis for the color changes :). We should start those reviews. I
know Ilkay had planned a review of some of Chad's code a couple f months
ago -- maybe we should pick back up on that. A good criteria for any
code that is written is that the JUnit tests for that code should be
complete, which we don't currently have at this point, I think.
Matt
Bertram Ludaescher wrote:
>>>>>>"EAL" == Edward A Lee <eal at eecs.berkeley.edu> writes:
>
> EAL>
> EAL> The way we handle this is that we have an "apps" subdirectory
> EAL> of the main $PTII/ptolemy directory that never ships with a release,
> EAL> but is present in the CVS repository.
> EAL>
> EAL> Experimental work that is far from releasing gets done in there.
> EAL> As it matures, it moves into regular packages in the released tree.
> EAL> Moving it can be a bit of a chore, but generally we do this in
> EAL> conjunction with rework based on design and code reviews, which
> EAL> usually involve significant rewriting anyway...
> EAL>
> EAL> Our only rule about checking things into the apps directory
> EAL> is that they must build. I.e., no compile errors.
> EAL>
> EAL> To check into the regular part of the tree, they need to also
> EAL> follow the Ptolemy coding standards, but they can still be
> EAL> unreviewed code (marked "red").
>
> I like this"color-coding" of the code. I think we should adopt it for
> Kepler as well. If I'm not mistaken it is already in the guidelines
> that Edward provided at the Kepler site:
>
> http://kepler.ecoinformatics.org/swguidelines.html
>
> (Ilkay: I saw that this has a link to
> http://users.sdsc.edu/~altintas/codingStyle.pdf
> Can you put it on the actual Kepler site? Thanks!)
>
> Bertram
>
>
> EAL>
> EAL> Edward
> EAL>
> EAL>
> EAL> At 06:37 PM 3/17/2004 -0500, Vouk wrote:
>
>>>Xiaowen,
>>>Where does new development go, and stuff in progress?
>>>Programmer X works on item Z. Does not
>>>finish it that day, goes home.
>>>
>>>Normally, I would say, put it into a development
>>>archive (shared nevertheless and put a lock on it),
>>>but do not leave it on your machine, the latter may
>>>not exist in the morning.
>>>
>>>Do you plan to have development directories
>>>(or are we just discussing integrated release level codes?)
>>>
>>>It also looks like the jar and lib files will be a mixture
>>>of project-specific and shared items (according to
>>>the sctructure below). Is that true or am I misreading it?
>>>Same for bins etc.
>>>?
>>>Thanks
>>>Mladen
>>>
>>>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
>
> EAL>
> EAL> ------------
> EAL> Edward A. Lee, Professor
> EAL> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
> EAL> phone: 510-642-0455, fax: 510-642-2739
> EAL> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
> EAL>
> EAL> _______________________________________________
> EAL> kepler-dev mailing list
> EAL> kepler-dev at ecoinformatics.org
> EAL> 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
-------------------------------------------------------------------
More information about the Kepler-dev
mailing list