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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
