geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: Restructuring trunk, then next steps
Date Thu, 31 Aug 2006 20:31:40 GMT
Ok ... take a deep breath.

This proposal was *not* just to work around windows.  It was to offer 
what I thought were constructive ideas and avoid exasperating a known 
problem unnecessarily.

I understand your hesitation to bundle the builders and deployers 
together (which is why I had a note there).  What do you think about the 
rest of the proposal?

-  Type based groupings in addition to functional groupings.
-  One level deep.  While I love hierarchy, I think it's overkill here.
-  Elimination of redundancy in names as much as possible.  (BTW, I know 
your post was a "crude stab" so I thought this was the type of input you 
were requesting to refine it).
-  "server" in place of "system"
-  "features" in place of "plugins"
-  Consistent naming of artifacts when the type is included in the name 
(such as with builder and deployer).

Joe



Jason Dillon wrote:
> On Aug 31, 2006, at 7:26 AM, Joe Bohn wrote:
> 
>> I'd like to propose that we keep things simple and eliminate  
>> redundancy where possible.  I'd also like to keep things as brief  as 
>> possible to prevent current or future issues with the windows  
>> pathlength issue.  I don't think the proposed changes will cause  
>> immediate problems but I'd like to prevent/reduce the possibility  of 
>> problems.
> 
> 
> <rant>
> I really, really, really don't like to be restricted by the  limitations 
> of a certain lame operating system... in fact it fills me  with rage.  
> If windows still had 8.3 file name limitations... would  we have to make 
> ever class conform to that naming system?!  Windows  is also case 
> insensitive, so should we use all UPPER CASE FILES TO  AVOID conflicting 
> files?  Windows stuff crashed all of the time... do  we add some hooks 
> to cause the server to crash just to fit in?!?
> 
> I am sorry your OS is retarded... but I see no reason to design the  
> build structure based on its limitations... especially if a different  
> layout make more sense to group logical modules together.
> </rant>
> 
> 
>> Do I understand correctly that with this proposal what is currently
>> "modules/geronimo-j2ee-builder" would become
>> "system/geronimo-j2ee/geronimo-j2ee-builder"
>> .... and what is currently
>> "modules/geronimo-j2ee" would become
>> "system/geronimo-j2ee/geronimo-j2ee"?
>> If so, then I think we are introducing some unnecessary redundancy  
>> once again.
> 
> 
> No, we would not end up with system/geronimo-j2ee/geronimo-j2ee.  As  I 
> mentioned this was a "crude stab" meaning that I did not take much  time 
> to clean up, just put out the basic high level organization  groups and 
> filled in the current modules.
> 
> 
>> BTW, do I understand correctly that you're proposing the removal of  
>> "modules" or is this presumed to be prior to each of the new names?
> 
> 
> Yes, modules is to be removed.
> 
> 
>> I wondering if it might be better to have more types and less  
>> subtypes (perhaps deciding to have only a single collection of  types 
>> with no subtypes at all).  Perhaps something like:
>>
>> builders/  (not sure yet if I like this myself :-) )
>>     geronimo-j2ee-builder
>>     geronimo-service-builder
>>     geronimo-axis-builder
>>     geronimo-tomcat-builder
>>     geronimo-jetty-builder
>>     geronimo-security-builder
>>     geronimo-service-builder
>>     geronimo-connector-builder
>>     geronimo-naming-builder
>>     geronimo-client-builder
>>     geronimo-j2ee-builder
>>     geronimo-web-builder
> 
> 
> I had thought about grouping the builders together... though I'm  still 
> drawn about if these should be closer to their code modules or  not.  
> Generally I'd like to have all of the tomcat integration code  together, 
> all the jetty code together and so on...
> 
> --jason
> 
> 
> 
>> ** Note, the way we name builders and the way we name deployers is  
>> inconsistent.  I think we need to decide if we want the descriptive  
>> type first or last in these names and use the pattern consistently.
>>
>> deployers/
>>     geronimo-deploy-core  (was geronimo-deployment) ?
>>     geronimo-deploy-config
>>     geronimo-deploy-jsr88
>>     geronimo-deploy-tool
>>     geronimo-deploy-hot  (was geronimo-hot-deploy ... just to be  
>> consistent with other deployers but see note above) ?
>>
>> framework/
>>     geronimo-testsupport
>>     geronimo-test-ddbean (not sure what this is either)
>>     geronimo-common
>>     geronimo-util
>>     geronimo-interceptor
>>     geronimo-activation
>>     geronimo-kernel
>>
>> server/
>>     geronimo-management
>>     geronimo-security
>>     geronimo-core
>>     geronimo-system
>>     geronimo-transaction
>>     geronimo-connector
>>     geronimo-jmx-remoting
>>     geronimo-naming
>>     geronimo-client
>>     geronimo-j2ee
>>     geronimo-j2ee-schema
>>
>> features/
>>     geronimo-activemq-rar (rename)
>>     geronimo-activemq-gbean
>>     geronimo-activemq-gbean-management
>>     geronimo-axis
>>     geronimo-derby
>>     geronimo-directory
>>     geronimo-tomcat
>>     geronimo-jetty
>>     geronimo-mail
>>     geronimo-timer
>>     geronimo-webservices
>>
>> tools/
>>     geronimo-upgrade
>>     geronimo-converter
>>
>>
>> Joe
>>
>>
>> Jason Dillon wrote:
>>
>>> So, I've mentioned a few times before that we should start  thinking  
>>> about how to split up modules in trunk into a few  smaller chunks.  
>>> I  took a few minutes and took a crude stab at  what that might look  
>>> like.  This is just an example of how it  might work... I did not do  
>>> any extensive research into  dependencies...
>>> Basically, I split things up into 5 main trees:
>>>  * framework - common stuff, not really the server, but supports  
>>> the  server, modules here should have minimal deps
>>>  * system - the major components which make up the server's  system  
>>> (should be the bits to start up a server shell)
>>>  * tools - bits that support the system
>>>  * plugins - components which plugin to the system
>>>  * testsuite - placeholder for modules which will be aded soon  that  
>>> use the itest plugin to perform integration tests
>>> I'm not sure if this is the best split, but it kinda comes closer  
>>> to  what I hope we can get to.  Below is how the modules that  exists 
>>> fit  into these sections.
>>> ----
>>> framework/
>>>     geronimo-testsupport (may need to be in other tree? so can   
>>> include in all modules by default)
>>>     geronimo-common
>>>     geronimo-util
>>>     geronimo-interceptor
>>>     geronimo-activation
>>>     geronimo-kernel
>>> system/
>>>     geronimo-management
>>>     geronimo-security
>>>     geronimo-security-builder
>>>     geronimo-service-builder
>>>     geronimo-core
>>>     geronimo-system
>>>     geronimo-transaction
>>>     geronimo-connector
>>>     geronimo-connector-builder
>>>     geronimo-jmx-remoting
>>>     geronimo-naming
>>>     geronimo-naming-builder
>>>     geronimo-test-ddbean (wtf is this for?)
>>>     geronimo-deployment/
>>>         geronimo-deployment (rename to -core) ?
>>>         geronimo-deploy-config
>>>         geronimo-deploy-jsr88
>>>         geronimo-deploy-tool
>>>         geronimo-hot-deploy
>>>     geronimo-client
>>>     geronimo-client-builder
>>>     geronimo-j2ee/
>>>         geronimo-j2ee
>>>         geronimo-j2ee-builder
>>>         geronimo-j2ee-schema
>>>     geronimo-web-builder
>>> plugins/
>>>     geronimo-activemq/
>>>         ge-activemq-rar (rename)
>>>         geronimo-activemq-gbean
>>>         geronimo-activemq-gbean-management
>>>     geronimo-axis
>>>     geronimo-axis-builder
>>>     geronimo-derby
>>>     geronimo-directory
>>>     geronimo-tomcat
>>>     geronimo-tomcat-builder
>>>     geronimo-jetty
>>>     geronimo-jetty-builder
>>>     geronimo-mail
>>>     geronimo-timer
>>>     geronimo-webservices
>>> tools/
>>>     geronimo-upgrade
>>>     geronimo-converter
>>> testsuite/
>>>     TODO, home for itest usage
>>> ----
>>> Anyways, I wanted to post what I am thinking.  I think that we  are  
>>> really close to the point where we will want to implement  this sort  
>>> of split up.
>>> Comments?
>>> --jason
> 
> 
> 
> 
> 
> 

Mime
View raw message