[evla-sw-discuss] code organization

[Bryan Butler]

in my opinion, the directory structure under the project (well, one layer deeper 
- under the trunk/tag/branch directories) is up to the developer working on it. 
  i don't think we benefit from alot of argument about it, since we're not 
really in an environment where lots and lots of people are working on lots and 
lots of different projects, so we don't need to be overly concerned about 
conformity.  i'm assuming maven2 will be flexible enough to support different 
layouts.

but i will enforce uniformity in those higher layers, however we decide is the 
best way to do it.

and we haven't really even touched on the higher level organization, which, as i 
mentioned before, is more important in my opinion.  can we get rid of the "e2e" 
that we have now?  what to do about "commons"?  etc.

	-bryan


On 10/25/06 17:35, Kevin Ryan wrote:
> I think we will find that if we do our homework in naming paths by  
> their (content's) function the rest will sort itself out so that we  
> won't have things mixed together that should not be.
> 
> In the 'gui' directories of widar, all of the sources are Java, but  
> in the low-level CMIB real-time software area they are 'C' files.   
> They naturally sorted themselves because of the way their paths were  
> named after what they do.  The deployed server-side directories have  
> a 'config' directory that contains XML files, but if we implemented  
> configuration files using something other than XML, the path name  
> would still remain the same.  If instead we called it 'xml' then we  
> would have configuration files mixed in with XML files for other  
> purposes.  And, if we decided to use something other than XML for  
> configurations, our path becomes broken.
> 
> On the other hand, some different-language files make sense to be in  
> the same directory like JNI C and Java files; or, if I'm searching  
> for a particular CGI implementation, I should not have to know if it  
> was written in C or perl or any of the many other possible ways to  
> implement CGI.  I should just be able to go to the CGI directory and  
> find it by its function.  I will discover what language it was  
> written in by its extension.
> 
> Structure this with the best interests in mind for sharing,  
> development and deployment as a system - not what tools were used to  
> implement it.  Someone outside our group should not have to stumble  
> around the paths based on how Maven or CVS or Subversion works (make  
> those things work with _our_ hierarchy not theirs); nor should they  
> have to know what scripting-language-du-Jour was used to implement a  
> specific function.  Implementation can change and when it does, we  
> don't want our hierarchy to break.
> 
> Kev
> 
> On Oct 25, 2006, at 3:34 PM, Bryan Butler wrote:
> 
>>
>> i agree with brian here.  for the webapps they also need the  
>> related assembly
>> and config stuff, and it's nice to have it separated out.
>>
>> sometimes it's nice to have everything all in one directory, but as  
>> things get
>> more complicated, it becomes impossible to find the needle in the  
>> haystack, as
>> it were.
>>
>> 	-bryan
>>
>>
>> On 10/25/06 15:31, Brian Truitt wrote:
>>> Kevin Ryan wrote:
>>>> A person searching the hierarchy for
>>>> VlaAntenna should know that it is part of the AMCS of the EVLA of
>>>> NRAO but should not have to know the name of the processor that it
>>>> might run in or the language that it was written in in order to find
>>>> it in our source repository.
>>>>
>>>> Kevin
>>>>
>>>
>>> In this case, how do we organize projects utilizing multiple  
>>> languages?
>>> We have C, perl, java, and jsp at least strewn throughout our  
>>> projects.
>>> (There's a perl script used to compile the online help used in the  
>>> PST
>>> for example). I have no interest in mixing perl scripts in with my  
>>> java
>>> packages, or my jsp and html for that matter. Where do they go  
>>> then? A
>>> concrete alternate suggestion for this scenario would be useful.
>>>
>>> I certainly find the directory structures verbose and lengthy as  
>>> well,
>>> so alternatives that handle all our use cases are welcome.
>>>
>>> Brian
>>> _______________________________________________
>>> evla-sw-discuss mailing list
>>> evla-sw-discuss at listmgr.cv.nrao.edu
>>> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>> _______________________________________________
>> evla-sw-discuss mailing list
>> evla-sw-discuss at listmgr.cv.nrao.edu
>> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
> 
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss