geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Colasurdo <>
Subject Re: Cannot build 1.1 on Windows - long file paths
Date Fri, 07 Apr 2006 13:24:23 GMT
I believe it's important to keep the CARs expanded as I suspect users 
(in development mode) would want the ability to easily update JSPs and 
classes without redeploying.  I also think Dain's suggestion to shrink 
the path length is the right approach..  Other comments below..


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/$$EnhancerByCGLIB$$36344d29.class

> (264)
> geronimo-1.1-SNAPSHOT/repository/geronimo/webconsole-jetty/1.1-SNAPSHOT/$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}
Are you suggesting removing the RepositoryPath from the actual directory 
structure?  If this is technically possible, I like the approach as I 
think it keeps with the idea of "providing an intuitive structure that 
users would expect" as opposed to an "obfuscated structure that is 
dictated by the technology".

As has been suggested by others.. perhaps we have two unique directory 


sys-apps - would contain all of the geronimo internal apps and 
configurations (uddi, webconsole, activemq, etc.)

apps - would contain the welcome app, samples and end user applications

> There are several problems with this.  I think users will confuse the 
> hot-deploy directory "deploy" with the "apps" directory [1].  Then 

We can rename the deploy directory to hot-deploy for clarity..

> 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

Users can freely undeploy any of the apps in the apps directory.. This 
would be documented as a common thing to do.

Undeploying apps in the sys-apps directory is less common and while it 
is supported we document that this should only be done when users really 
know what they are doing.

> 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