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:34:38 GMT
Good time for everyone to go buy a Mac :-)

Is there any version of any windows fs that is not crippled with this  

Its a real pity that we have to work around muck like this... :-(

  * * *

What if the repo was not backed by a filesystem... but maybe a fast  
database or something similar?  Then paths could be as long as we  
want, but the physical representation could be tailored for lame  
operating systems.

This would mean we need more tools to get at the data and to put in  
the data... but I think that would be generally a good thing anyways.


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