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

Thu Mar 18 11:05:25 PST 2004

Fine with me too.
- Efrat

From: "Ilkay Altintas" <altintas at sdsc.edu>


> For Chad's comments on 4&5:
>   I'm not using those files so I aggree.
>
> Ilkay
>
> -----Original Message-----
> From: sdm-dev-admin at sdsc.edu [mailto:sdm-dev-admin at sdsc.edu]On Behalf Of
> Chad Berkley
> Sent: Thursday, March 18, 2004 8:30 AM
> To: Xiaowen Xin
> Cc: sdm-dev at sdsc.edu; kepler-dev at ecoinformatics.org
> Subject: [SDM-SPA] Re: [kepler-dev] RFC new directory structure
>
>
> Hello,
>
> See my comments below:
>
> 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
> >
>
> this seems good to me, but it might be better to move the workflows
> directory under lib.  it's just nicer to have fewer top level directories.
>
> >
> > 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 ...
> >
>
> yeah, i'll do that.
>
> > 2. demos.htm and ptolemy-index.html should probably be moved out of lib/
> > and into a more appropriate folder, probably into src/.
>
> ptolemy-index.html isn't a demo.  it's the startup view for kepler.  it
> gets copied into the ptolemy directory as kepler-index.html.  I think
> it's fine in lib.
>
> >
> > 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.
>
> the ecoPipelines directory just contains some random seek stuff i was
> working on.  i can put them under the workflows directory, whereever it
> ends up.
>
> >
> > 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.
>
> I have no problem with that.  ilkay or efrat?
>
> >
> > 5. We should move runVergil.bat and runVergil.sh into a top-level bin/
> > directory.
>
> they aren't really binary, but sure.  Efrat and Ilkay, are you still
> using these?
>
> >
> > 6. Does anyone know what lib/sample.dat and lib/scew-0.3.1.tar.gz are?
> > Can we delete them?
>
> please do not delete these.  they go with the garp stuff i've been
> working on.  i can move sample.dat into testdata/garp.  scew is in there
> so i had access to the version that I know compiles with the garp cpp
code.
>
> >
> > 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.
>
> i personally think it's fine where it is, though it would also be fine
> in a test directory.  the test directory was supposed to be for junit
> tests, but more structure could be created under that as not many junit
> tests have been created yet.
>
> >
> > 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 ...
>
> the stuff in exp was was some stuff we were messing around with to
> extend the type system.  it hasn't been used yet but may be in the
> future.  please leave it there.
>
> >
> > 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.
>
> Thanks a lot for looking into this.  the messiness of it's been bugging
> me as well.
>
> chad
>
>
> >
> > Xiaowen
> >
> > _______________________________________________
> > kepler-dev mailing list
> > kepler-dev at ecoinformatics.org
> > http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>
>
> _______________________________________________
> kepler-dev mailing list
> kepler-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>