Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mario.ruebsam@googlemail.com
 designates 64.233.182.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from;
        b=X+LxC8tcfldus2uB8OMJzzhv3W15vQ4qZTmG/fDAa/kso8uJLs41jKPksh2HPkof5/iBB0wpOGS7gEfXW2Asr7caG3aFWHZKP/GAo6FgUn4BphnxX3CWvW4TclmLDmXAqXi/fBpyKxF4MdHvwDZ9/RTR7Rtg+NZTvttYQNHLyeU=
Message-ID: <44F7466C.5020400@gmail.com>
Date: Thu, 31 Aug 2006 22:28:28 +0200
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Restructuring trunk, then next steps
References: <90F6BA89-E7C1-4DBD-8806-67071C2FBB4F@planet57.com>
 <44F6F1A9.2020509@earthlink.net>
 <F01A9FC7-847E-4A06-857E-A4EB6AA0DC70@planet57.com>
In-Reply-To: <F01A9FC7-847E-4A06-857E-A4EB6AA0DC70@planet57.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Mario Ruebsam <mario.ruebsam@googlemail.com>

wow, nice rant ;)

To be correct it is an API problem in windows that path names are restricted
to 254 or 260 chars (Win2k), it's not an NTFS problem.
You can create pathes with more characters when using UNC names. The limitation
should be 32767 chars.
If you have already a base path for the sources, you can share this path
e.g. d:\home\tweety\wrk\java\geronimo as windows share and map it as drive
p: for example. Now change to the mapped drive and do what you want with
the path until he is 254 chars long. With that path example you save about
30 characters.

Thanks,
Mario

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
> 
> 
> 
>