Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of goyathlay.geronimo@gmail.com
 designates 64.233.166.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=QScA1YNu2Xy5M8KODsX1aAybA1jukYjYm3IXh9j7GZB0Pk8olI0f3Tfadf+scPTBRQUXhBNsuqfJVQkgmNxW+eJqSFrXT/TIttg2IGik53VmRLLZhN7egJuWBwm/CeK3mx514T3V2daxhOe4/03DxcyQlmSqFLUUwOTo4VPvjHY=
Message-ID: <c278ac970604062024v4b017460n96e8d2a68e139526@mail.gmail.com>
Date: Thu, 6 Apr 2006 23:24:46 -0400
From: "Prasad Kashyap" <goyathlay.geronimo@gmail.com>
To: dev@geronimo.apache.org
Subject: Re: Cannot build 1.1 on Windows - long file paths
In-Reply-To: <74e15baa0604061831o177aae4bt6f32833a65d63b69@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <4432830E.6070102@gmail.com> <44328A50.8020904@earthlink.net>
	 <443574F7.6050100@earthlink.net>
	 <541C09A0-5874-40D1-AB9C-FAD105DC41EB@iq80.com>
	 <4435797C.9060001@gmail.com> <44357D47.4000201@hogstrom.org>
	 <188FBA86-9867-48A1-AD91-0B5DC8E5811C@iq80.com>
	 <74e15baa0604061831o177aae4bt6f32833a65d63b69@mail.gmail.com>

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.artifac=
t-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.
> >
> >
> >
>