geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Cannot build 1.1 on Windows - long file paths
Date Fri, 07 Apr 2006 19:25:41 GMT
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