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

Wed Apr 7 09:54:25 PDT 2004

>>>>> "IA" == Ilkay Altintas <altintas at sdsc.edu> writes:
IA> 
IA> Hey Xiaowen,
IA> 
IA> I agree with Efrat's idea of jarring th e3rd party source under 
IA> lib. I think that's how it should have done. 

ok

IA> 
IA> For the rest of the util files, I am not against having project 
IA> related util folders like seek does. That is the reason of the 
IA> util folder under spa in my dir. hierarchy sketch, too. 

But didn't you just argue that having a shared util folder was easier?
ok, that's why we need to listen to the actual developers. If it's
easier for you that way, then we should probably do it.

IA> Putting 
IA> joint actors in one project's folder also makes sense. 

As mentioned before I see a problem with this. If I understand it
right, the purpose of project oriented folders (as opposed to
functional ones) was to indicated "ownership" or at least to delineate 
what different projects have contributed. Note that this is mainly a
concern to SPA but not to the other Kepler projects as far as I know.

Thus, if the project-oriented folder structure is meant to reflect
delineation/ownership I find it quite illogical to associate a truly
shared development with any single project. I don't see how that can
be resolved, but through a place called "shared" or something... 

IA> My concern is about the generic util files like xslt.
IA> They are not actor code at all and also not project specific.
IA> When we use each others code, we don't directly include the actor code.
IA> But as long as something becomes useful for another person, the 
IA> core of the code (i.e. spa/XSLTActor<-->util/XSLT) was be moved to a 
IA> generic util folder.
IA> 
IA> But either way, it doesn't matter for me where the util folder is.
IA> I use Kepler as the main development hierarchy and can reach all 
IA> the folders when I develop. I was just concerned that this will 
IA> make the sync harder as it won't be clear if somebody used a util 
IA> file from a util folder other than spa. The generic util folder would 
IA> solve this. 

right

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

I'm also taking a break on this topic ;-)

Bertram

IA> 
IA> Ilkay
IA> 
IA> -----Original Message-----
IA> From: kepler-dev-admin at ecoinformatics.org
IA> [mailto:kepler-dev-admin at ecoinformatics.org]On Behalf Of Xiaowen Xin
IA> Sent: Wednesday, April 07, 2004 7:40 AM
IA> To: Ilkay Altintas
IA> Cc: sdm-dev at sdsc.edu; kepler-dev at ecoinformatics.org
IA> Subject: RE: [SDM-SPA] Re: [kepler-dev] moving edu.ncsu to org.sdm.spa
IA> 
IA> 
IA> Hi Ilkay,
IA> 
IA> 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?
IA> 
IA> That's why I suggested we could put them into org.geon.util, rather than
IA> org.geon.  But even if we did just put it in org.geon, I don't think the
IA> script that synchronizes SPA's CVS with Kepler's needs to copy the rest
IA> of GEON over, does it?
IA> 
>> 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.)
IA> 
IA> 1) I looked at UUIDGen.java as you suggested, and I agree that it
IA> doesn't seem to belong in org.sdm.spa.util.  I liked Efrat's suggestion
IA> of jar'ing it up; we could call it thirdparty.jar.  For now, it would
IA> seem silly since there's just one file in this jar, but in the future,
IA> if we get more files like this one, we could put them all together in
IA> thirdparty.jar.  We already have a lot of third party jar files in lib/,
IA> so I think this would be a nice mechanism for collecting all third party
IA> software in one place.  What do you think?
IA> 
IA> 2) If you look at seek, there already is a
IA> org.ecoinformatics.seek.util.  It presumably contains files that could
IA> be useful to several aspects of seek.  But how do we know it can't
IA> eventually be useful to SPA or GEON in the future as well?  When someone
IA> first writes a utility file for SPA (for example), s/he may be doing it
IA> for the specific purpose of implementing something useful for SPA, but
IA> it could be useful later on to GEON, or SEEK as well.  Where should that
IA> developer put this code?
IA> 
IA> I think in the end, most things currently in org.sdm.spa could
IA> potentially be useful for the other projects, just as their code could
IA> potentially be useful for us.  So it doesn't make sense to me to divide
IA> up code based on which projects may potentially use it.
IA> 
IA> 3) We have one naming scheme for the packages, i.e. we put classes in
IA> packages according to which project originates it.  I think it
IA> complicates it when we introduce a second naming scheme and say put all
IA> generic utility files in a different folder.
IA> 
IA> What do you think?
IA> 
IA> Xiaowen
IA> 
>> 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
>> 
IA> 
IA> _______________________________________________
IA> kepler-dev mailing list
IA> kepler-dev at ecoinformatics.org
IA> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
IA> 
IA> _______________________________________________
IA> kepler-dev mailing list
IA> kepler-dev at ecoinformatics.org
IA> http://www.ecoinformatics.org/mailman/listinfo/kepler-dev