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..
-Dave-
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/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}
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
paths:
${GeronimoName}/sys-apps/${FileName}/${NestedPath}
${GeronimoName}/apps/${FileName}/${NestedPath}
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.
