[kepler-dev] Re: [SDM-SPA] RFC new directory structure

[Vouk]

Works for me.
Mladen

Matt Jones wrote:

> Mladen,
>
> I think new work shoudl go in the regular trees.  It would be messy to 
> divide up new work form 'stable' work, because all of the code evolves 
> with time.  The Kepler development guidelines say that people should 
> check in regularly, but not check in code that is broken.  If you need 
> to checkpoint your work, it is easy enough to create a CVS branch and 
> check it in there, and then merge the source with the CVS HEAD when 
> the code has matured.  The HEAD of CVS is always recognized as a 
> developer's only land, but it needs to have a certain level of quality 
> just to enable collaboration.  The branches allow this to happen 
> cleanly. Releases will need to be tagged with CVS tags so that we can 
> return to the exact version of everything used in the release, as I 
> described in my earlier emails about releases.
>
> Matt
>
> 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
>
>