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 13:07:55 GMT
I think this is a band-aid and addresses the current bhaviour and not the underlying problem.

Perhaps this should be added to help people out.

Prasad Kashyap wrote:
> Now I have my project root at c:\apache and that was too deep for the
> files in the target dir to be deleted.
> 
> How about, IF the clean:clean goal fails, moving the dir to be deleted
> to say c:\tmp and then delete it from there ?
> 
> 
> Cheers
> Prasad.
> 
> 
> On 4/6/06, Aaron Mulder <ammulder@alumni.princeton.edu> wrote:
> 
>>I think we should be able to JAR up our generated stuff and that
>>should get around the problem for now.  There will be some limit for
>>user path lengths, but they don't have to use archive names like
>>org.apache.geronimo/artifact/1.0-SNAPSHOT.ear/org.apache.geronimo.artifact-1.0-SNAPSHOT.war/...
>>
>>Thanks,
>>    Aaron
>>
>>On 4/6/06, Dain Sundstrom <dain@iq80.com> 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