geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Cannot build 1.1 on Windows - long file paths
Date Sat, 08 Apr 2006 01:36:34 GMT
Um, I'm guessing this is one of the reasons why the windows registry  
isn't just a set of simple xml files too... no way that muck could be  
represented in their whacko filesystem.


On Apr 7, 2006, at 12:25 PM, Matt Hogstrom wrote:

> I'm not blaming the m2 structure.  One has to acknowledge that it  
> accounts for more than 15% of the length (per your comment below).   
> 15% is not insignificant but I'll concede that this is nowhere near  
> the whole problem.  It is compunding of the length due to nesting  
> modules.  Daytrader is a fair example of this.  This example is  
> from a build from this morning in branches/1.1.  I omitted the / 
> Users/hogstrom/dev/geronimo/branches/1.1/assemblies/j2ee-tomcat/ 
> target/ prefix.
> geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-tomcat/ 
> 1.1-SNAPSHOT/ 
> web-1.1-SNAPSHOT.war/
> Repeated items like derby-tomcat-1.1-SNAPSHOT doesn't help :)
> BTW, Geronimo is not the only one to suffer from this issue.  The  
> restriction is a problem on Windows I think we've been flirting  
> with it for sometime.  It has now just bit us hard.
> Dain Sundstrom wrote:
>> Please stop blaming the m2 repo structure for this problem.  The  
>> m2  repo structure only increased the path of our longest path by  
>> 36  characters.  The true problem is that David and I moved the  
>> unpacked  configurations into the repository.  We did this because  
>> of the  chunkiness of the numbered directories in the config- 
>> store  directory.  The m2 repository structure makes querying the  
>> repository  for version numbers possible and it is this querying  
>> that makes  optional version numbers possible.
>> I think we have two issues that both must be addressed:
>> 1) The ears we generate in our build have very long internal  
>> paths,  154 characters.  This is just bad form, and vastly reduces  
>> the user  path head room.
> >
>> 2) We need to move the unpacked ears our of the repository and  
>> into a  separate flat directory structure.
>> I can look at the second one later today after fixing the  
>> redeploy  command.  Can someone take a look at getting our build  
>> to jar up the  classes and compiled jsps in our build.  I'll fix  
>> the generated  classes in our build.
>> -dain
>> On Apr 7, 2006, at 6:50 AM, 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/  
>>>> 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/   
>>>> 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)
>>>> 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.

View raw message