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

[Bertram Ludaescher]

David and Xiaowen:

Just wanted to thank you both for stepping up to the plate and jumping 
into the (certainly quite complex) issues of improving the directory
structure! 

I know there have been lots of emails going back and forth on the
various options, but I think this is educational and useful for all of
those who need to get their hands dirty with the actual code.

I leave the floor now to you guys, the developers, to figure out which
options make most sense. It seems were converging towards a general
solution for Kepler. If not, we can always have a separate SPA
branch. But if we can avoid duplicating existing work and know-how, we 
should probably do it (avoid it)

Bertram 




>>>>> "DB" == David Buttler <buttler1 at llnl.gov> writes:
DB> 
DB> Yes, it would be good to clean up the repository a little at a time.  I 
DB> also think that changes should be done in a two step process to make 
DB> sure nothing is broken between changes.  For example:
DB> 
DB> The first thing I would like to do (or have Xiaowen do once she gets 
DB> write access) is to simply create a top level workflow directory and 
DB> copy the workflows there.  Any changes that are required to point to the 
DB> new location can be made, and only after that should the workflows be 
DB> removed from the lib directory.
DB> 
DB> Another item high on my agenda is moving all of the edu.ncsu source into 
DB> the org.sdm.spa package.  I don't think that this should have too much 
DB> of an impact on others, so could be done concurrently with moving the 
DB> workflows.  I will take a quick look to see if any other package  
DB> depends on the ncsu source.
DB> 
DB> The next step, I would like to reform the build file to use file sets 
DB> and rename the jars to include version numbers.  Again, this could be 
DB> done in a two-step process where we create the new resources in parallel 
DB> with the existing resources, and only after making sure that the new 
DB> version works removing the old resources.
DB> 
DB> After these steps are taken care of, along with the other changes the 
DB> rest of the team has agreed to, it should be much easier to see what 
DB> else can be done to make the CVS repository cleaner and more manageable