geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hernan Cunico <hcun...@gmail.com>
Subject Re: Cannot build 1.1 on Windows - long file paths
Date Fri, 07 Apr 2006 16:55:47 GMT
Hi All,
I agree with Matt, we need to find a common ground, something in between the very short, number

based structure (and BTW not too meaningful) we had in the config-store and the "unnecessary"
long 
directory structure and file names that we are having now.

Independently of the Windows limitation for handling long names, I personally think that having
a 
structure as long (that potentially will keep growing) is unnecessary. What is the benefit
of such a 
'very' verbose naming?  Sooner or later is going to become unpractical to browse through such
a 
complex structure no matter what OS you are using.

Matt's alternative going back to the config-store sounds good (I would also suggest to limit
the 
configId to a max number of chars) but we will still be facing the application naming area
(222...). 
This is the are we have less control and, IMHO, where we should focus on.

Cheers!
Hernan

Matt Hogstrom wrote:
> Thinking about this some more I believe we need to make a good decision 
> here as having to revisit this issue in the future will cause users to 
> have to change how the server works.  I've been talking to a new user 
> that has a larger server farm and is very interested in the Geronimo 
> server as their new foundation.  However, they run a few thousand 
> servers and are VERY sensitive to changes in the behaviour of the server 
> in terms of how it impacts them.  Changes to the repsoistory will affect 
> their operational experience dramatically and they do run Windows (go 
> Bill Gates).  They are watching this thread with keen interest.  Their 
> biggest concern is changing how their build and distribution system 
> works and changes in this area is highly disruptive for them.
> 
> My view of the problem is that there are really three distinct areas of 
> a path.  They are the user area, the server area and the application 
> area.  Let me splain...
> 
> | 0000000000000000000000000000 | 
> 11111111111111111111111111111111111111111 | 2222222222222222222 ...
> C:\my\directory\before\geronimo\geronimo-1.1\repository\com.apache.geronimo\console-1.1\appArtifacts

> 
> 
> The area in the 0's are controlled by the user and we need to leave more 
> headroom than a few characters so they can manage multiple deployments 
> of Geronimo; this could include multiple versions or multiple 
> deployments.  The users probably enjoy flexibility in naming as much as 
> we do.  We don't have control over this but we influence how much 
> headroom is available.
> 
> The 1's is really the area we have control over as this is the server 
> proper.  This includes the area from the top of the tree to the end of 
> where the files we create end.  So, for instance, this includes var, 
> repository, etc.  Since were currently experiencing this problem in the 
> respository I think we should focus on this area.
> 
> Finally, the 2's are the area that include the application and Maven 
> dependent information.  The Maven naming convention is verbose.  The 
> current implementation needs to be changed, the question is how and can 
> the change survive several releases so that our users are not forced to 
> change their deployments on each subsequent release.  *One immediate 
> thought I had was to place applications back into the config-store (or 
> equivalent name).  Rather than simply use a number as we did previously 
> perhaps the configId of the deployment would be appropriate.  Its human 
> readable and would be shorter than the current maven structure.*  I 
> highlighted the previous as I think this is the best option based on 
> what I know today.
> 
> Perhaps there some way to provide a Maven abstraction that would map 
> Maven dir names to an internal format for us.  I expect if we are 
> running into this its only a matter of time befoew other Maven users 
> experience the same issues.  For us its the nesting of Maven articacts / 
> configurations that is causing us the problem.  Jason, thoughts?
> 
> Whatever we decide we need to ensure that it is stable enough to work 
> for a period of time.
> 
> Matt
> 
> 
> Dain Sundstrom wrote:
> 
>> Man I hate Windows....
>>
>> Anyway, if you have a real OS and list the files in an assembly, you  
>> will see that the problem is caused by the combination of two  
>> changes: we now keep configurations in the repository and we unpack  
>> them. If you look closer you will see that the big offenders are  
>> unpacked ears and wars.
>>
>> I believe the following are the longest paths in the server:
>>
>> (270)
>> geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-jetty/1.1- 
>> SNAPSHOT/daytrader-derby-jetty-1.1-SNAPSHOT.car/daytrader-web-1.1- 
>> SNAPSHOT.war/META-INF/geronimo-generated/org/apache/geronimo/axis/ 
>> client/GenericServiceEndpointWrapper$$EnhancerByCGLIB$$36344d29.class
>> (264)
>> geronimo-1.1-SNAPSHOT/repository/geronimo/webconsole-jetty/1.1- 
>> SNAPSHOT/webconsole-jetty-1.1-SNAPSHOT.car/geronimo-console- 
>> standard-1.1-SNAPSHOT.war/WEB-INF/classes/org/apache/geronimo/console/ 
>> databasemanager/wizard/DatabasePoolPortlet$ResourceAdapterParams.class
>>
>>
>> One thing to note here is that the longest paths are all classes  
>> generated by Geronimo, nested classes in wars or compiled JSP pages.   
>> Someone should look into makeing maven jar the latter two and  
>> Geronimo should be creating jars when generating classes (actually we  
>> should stop generating classes a head of time but that is another  
>> story).
>>
>>
>>
>> Breaking down the longest path, we have:
>>
>> GeronimoName (22)
>>   geronimo-1.1-SNAPSHOT
>> RepositoryPath (55)
>>   repository/geronimo/daytrader-derby-jetty/1.1-SNAPSHOT
>> FileName (39)
>>   daytrader-derby-jetty-1.1-SNAPSHOT.car
>> NestedPath (154)
>>   daytrader-web-1.1-SNAPSHOT.war/META-INF/geronimo-generated/org/ 
>> apache/geronimo/axis/client/GenericServiceEndpointWrapper$ 
>> $EnhancerByCGLIB$$36344d29.class
>>
>>
>>
>> The first thing to note is if we simply replace "SNAPSHOT" with "0",  
>> we drop 28 characters which makes the longest path 242; not enough  
>> head room.  Of course, when we switch our groupId to the maven  
>> standard org.apache.geronimo we eat up 20 more characters.  If we are  
>> going to unpack war files there is very little we can do about the  
>> NestedPath, so we have very few choices left.  If we simply combine  
>> combine ${GeronimoName}/${FileName}/${NestedPath} we are up to 115  
>> characters leaving only 41 characters for anything else, but when you  
>> add back the 28 from "SNAPSHOT", you get to a more comfortable level.
>>
>> I think if we combine this problem with Sachin's request for a  
>> separate directory for applications, we could do something like this:
>>
>> ${GeronimoName}/apps/${FileName}/${NestedPath}
>>
>> There are several problems with this.  I think users will confuse the  
>> hot-deploy directory "deploy" with the "apps" directory [1].  Then  
>> again, if you look at the problem configurations they are all apps  
>> the users may want to remove (sample apps and the console), so may be  
>> we should just put these in the hot-deploy directory.  Another  
>> problem is that it will be much more difficult to query a repository  
>> without a directory structure.  The server will basically have to  
>> read the configuration from these apps on startup to determine what  
>> they are, so again we may just want to use the hot-deploy directory.   
>> I'm not a fan of the hot-deploy directory, but I'm not sure there is  
>> a better solution.
>>
>> Again I renew my hate of Windows...
>> /me shakes his fist at Bill Gates
>>
>> -dain
>>
>>
>> [1] As a side issue, I prefer the name "apps" because it will be most  
>> familiar to tomcat users.
>>
>>
>>
>>
>>
> 

Mime
View raw message