geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Cannot build 1.1 on Windows - long file paths
Date Thu, 06 Apr 2006 23:51:32 GMT
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:


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  

Breaking down the longest path, we have:

GeronimoName (22)
RepositoryPath (55)
FileName (39)
NestedPath (154)

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:


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


[1] As a side issue, I prefer the name "apps" because it will be most  
familiar to tomcat users.

View raw message