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 Sat, 08 Apr 2006 12:59:22 GMT
Please, stay away from config/repos in DB :D  I've seen that before and I really hated it.
I can come up with a lond detailed list why we should not go that way ;)

Cheers!
Hernan

Jason Dillon wrote:
> Good time for everyone to go buy a Mac :-)
> 
> Is there any version of any windows fs that is not crippled with this  
> limitation?
> 
> 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.
> 
> --jason
> 
> 
> 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/daytrader-derby-tomcat-1.1-SNAPSHOT.car/daytrader- 
>> 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/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