geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Prasad Kashyap" <goyathlay.geron...@gmail.com>
Subject Re: Cannot build 1.1 on Windows - long file paths
Date Fri, 07 Apr 2006 03:24:46 GMT
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