[SDM-SPA] Re: [kepler-dev] moving edu.ncsu to org.sdm.spa

Wed Apr 7 09:47:04 PDT 2004

Hey Xiaowen,

I agree with Efrat's idea of jarring th e3rd party source under 
lib. I think that's how it should have done. 

For the rest of the util files, I am not against having project 
related util folders like seek does. That is the reason of the 
util folder under spa in my dir. hierarchy sketch, too. Putting 
joint actors in one project's folder also makes sense. 

My concern is about the generic util files like xslt.
They are not actor code at all and also not project specific.
When we use each others code, we don't directly include the actor code.
But as long as something becomes useful for another person, the 
core of the code (i.e. spa/XSLTActor<-->util/XSLT) was be moved to a 
generic util folder.

But either way, it doesn't matter for me where the util folder is.
I use Kepler as the main development hierarchy and can reach all 
the folders when I develop. I was just concerned that this will 
make the sync harder as it won't be clear if somebody used a util 
file from a util folder other than spa. The generic util folder would 
solve this. 

It was just my two cents. I'm back to my code design now... ;)

Ilkay

-----Original Message-----
From: kepler-dev-admin at ecoinformatics.org
[mailto:kepler-dev-admin at ecoinformatics.org]On Behalf Of Xiaowen Xin
Sent: Wednesday, April 07, 2004 7:40 AM
To: Ilkay Altintas
Cc: sdm-dev at sdsc.edu; kepler-dev at ecoinformatics.org
Subject: RE: [SDM-SPA] Re: [kepler-dev] moving edu.ncsu to org.sdm.spa

Hi Ilkay,

On Tue, 2004-04-06 at 19:24, Ilkay Altintas wrote:
> Hi All,
> 
> I understand we want the spa to be the top src folder in the 
> spa cvs and we have decided to have the util under it.
> But I believe it would be a better structure if we have it like
>    src
>     |_ org
>         |_ sdm
>            |_ spa
>                |_ util (SPA actor-specific utility files)
>     |_ util (Generic utility files)
> 
> This will also make the synch with Kepler easier. We can copy 
> the generic util files we need from Kepler into the top directory.
> Copying all the geon folder just for using a geon util file 
> doesn't make very much sense to me. I thought this was what
> we wanted to avoid in spa cvs. Did I misunderstand something?

That's why I suggested we could put them into org.geon.util, rather than
org.geon.  But even if we did just put it in org.geon, I don't think the
script that synchronizes SPA's CVS with Kepler's needs to copy the rest
of GEON over, does it?

> Also for Kepler, it might be a better organization to keep 
> the project-related/actor-specific util files in project
> folders and the generic util files in one top directory under 
> source (***as it is now) IMHO. It is easier to look for what's 
> already available in the top folder, etc. and some of these 
> files would be even not belonging to a kepler project but 
> anonymous code that is being used by some of the actors. 
> (e.g. UUIDGen.java is a universal id generator is an open-source 
> (see author info in the file) java code that is used to create 
> unique temporary file names for temporary storage.)

1) I looked at UUIDGen.java as you suggested, and I agree that it
doesn't seem to belong in org.sdm.spa.util.  I liked Efrat's suggestion
of jar'ing it up; we could call it thirdparty.jar.  For now, it would
seem silly since there's just one file in this jar, but in the future,
if we get more files like this one, we could put them all together in
thirdparty.jar.  We already have a lot of third party jar files in lib/,
so I think this would be a nice mechanism for collecting all third party
software in one place.  What do you think?

2) If you look at seek, there already is a
org.ecoinformatics.seek.util.  It presumably contains files that could
be useful to several aspects of seek.  But how do we know it can't
eventually be useful to SPA or GEON in the future as well?  When someone
first writes a utility file for SPA (for example), s/he may be doing it
for the specific purpose of implementing something useful for SPA, but
it could be useful later on to GEON, or SEEK as well.  Where should that
developer put this code?

I think in the end, most things currently in org.sdm.spa could
potentially be useful for the other projects, just as their code could
potentially be useful for us.  So it doesn't make sense to me to divide
up code based on which projects may potentially use it.

3) We have one naming scheme for the packages, i.e. we put classes in
packages according to which project originates it.  I think it
complicates it when we introduce a second naming scheme and say put all
generic utility files in a different folder.

What do you think?

Xiaowen

> There might be other ways of doing this. This is just an 
> idea that seemed reasonable to me. 
> 
> Ilkay
> 
> 
> -----Original Message-----
> From: kepler-dev-admin at ecoinformatics.org
> [mailto:kepler-dev-admin at ecoinformatics.org]On Behalf Of Xiaowen Xin
> Sent: Tuesday, April 06, 2004 4:46 PM
> To: Ilkay Altintas; efrat at sdsc.edu
> Cc: sdm-dev at sdsc.edu; kepler-dev at ecoinformatics.org
> Subject: RE: [SDM-SPA] Re: [kepler-dev] moving edu.ncsu to org.sdm.spa
> 
> 
> Another thing is we agreed a few weeks ago that we would have a
> org/sdm/spa/util directory for utility files.  So what's currently in
> kepler/src/util would ideally go there.  This switch wouldn't be as easy
> to make since there's a GEON file that apparently uses both files that
> are currently in util/.
> 
> Efrat: you're listed as the author for
> src/org/geon/OpenDBConnection.java, which is the only non-spa file I
> could find that uses the code in util/.  Would it be okay for me to move
> what's now in src/util into org/sdm/spa/util/?  Alternatively, we could
> move those two files into org/geon/util/.
> 
> The reason for this is that since we're already dividing up most of the
> source files by organization, we should just divide it all up by
> organization.  I think the reason people wanted a util/ directory is so
> that it would be a place to put code that would be useful for all
> projects.  However, this criteria is hard to determine because most of
> the code from one project could potentially be useful in the other
> projects.  So I think having a util/ directory as a subdirectory of the
> projects makes more sense.  If SPA needed to use something from GEON, we
> could import org.geon.*; or org.geon.util.* as an example.  The
> distinction here between org.sdm.spa.* and org.sdm.spa.util.* is that
> util.* contains non-actor utility code, while all the actors go into
> org.sdm.spa.*.
> 
> I hope that made sense :)
> 
> 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