Good time for everyone to go buy a Mac :-)
Is there any version of any windows fs that is not crippled with this
limitation?
Its a real pity that we have to work around muck like this... :-(
* * *
What if the repo was not backed by a filesystem... but maybe a fast
database or something similar? Then paths could be as long as we
want, but the physical representation could be tailored for lame
operating systems.
This would mean we need more tools to get at the data and to put in
the data... but I think that would be generally a good thing anyways.
--jason
On Apr 7, 2006, at 12:25 PM, Matt Hogstrom wrote:
I'm not blaming the m2 structure. One has to acknowledge that it
accounts for more than 15% of the length (per your comment below).
15% is not insignificant but I'll concede that this is nowhere near
the whole problem. It is compunding of the length due to nesting
modules. Daytrader is a fair example of this. This example is
from a build from this morning in branches/1.1. I omitted the /
Users/hogstrom/dev/geronimo/branches/1.1/assemblies/j2ee-tomcat/
target/ prefix.
geronimo-1.1-SNAPSHOT/repository/geronimo/daytrader-derby-tomcat/
1.1-SNAPSHOT/daytrader-derby-tomcat-1.1-SNAPSHOT.car/daytrader-
web-1.1-SNAPSHOT.war/
Repeated items like derby-tomcat-1.1-SNAPSHOT doesn't help :)
BTW, Geronimo is not the only one to suffer from this issue. The
restriction is a problem on Windows I think we've been flirting
with it for sometime. It has now just bit us hard.
Dain Sundstrom wrote:
Please stop blaming the m2 repo structure for this problem. The
m2 repo structure only increased the path of our longest path by
36 characters. The true problem is that David and I moved the
unpacked configurations into the repository. We did this because
of the chunkiness of the numbered directories in the config-
store directory. The m2 repository structure makes querying the
repository for version numbers possible and it is this querying
that makes optional version numbers possible.
I think we have two issues that both must be addressed:
1) The ears we generate in our build have very long internal
paths, 154 characters. This is just bad form, and vastly reduces
the user path head room.
>
2) We need to move the unpacked ears our of the repository and
into a separate flat directory structure.
I can look at the second one later today after fixing the
redeploy command. Can someone take a look at getting our build
to jar up the classes and compiled jsps in our build. I'll fix
the generated classes in our build.
-dain
On Apr 7, 2006, at 6:50 AM, Matt Hogstrom wrote:
Thinking about this some more I believe we need to make a good
decision here as having to revisit this issue in the future will
cause users to have to change how the server works. I've been
talking to a new user that has a larger server farm and is very
interested in the Geronimo server as their new foundation.
However, they run a few thousand servers and are VERY sensitive
to changes in the behaviour of the server in terms of how it
impacts them. Changes to the repsoistory will affect their
operational experience dramatically and they do run Windows (go
Bill Gates). They are watching this thread with keen interest.
Their biggest concern is changing how their build and
distribution system works and changes in this area is highly
disruptive for them.
My view of the problem is that there are really three distinct
areas of a path. They are the user area, the server area and
the application area. Let me splain...
| 0000000000000000000000000000 |
11111111111111111111111111111111111111111 | 2222222222222222222 ...
C:\my\directory\before\geronimo\geronimo-1.1\repository
\com.apache.geronimo\console-1.1\appArtifacts
The area in the 0's are controlled by the user and we need to
leave more headroom than a few characters so they can manage
multiple deployments of Geronimo; this could include multiple
versions or multiple deployments. The users probably enjoy
flexibility in naming as much as we do. We don't have control
over this but we influence how much headroom is available.
The 1's is really the area we have control over as this is the
server proper. This includes the area from the top of the tree
to the end of where the files we create end. So, for instance,
this includes var, repository, etc. Since were currently
experiencing this problem in the respository I think we should
focus on this area.
Finally, the 2's are the area that include the application and
Maven dependent information. The Maven naming convention is
verbose. The current implementation needs to be changed, the
question is how and can the change survive several releases so
that our users are not forced to change their deployments on
each subsequent release. *One immediate thought I had was to
place applications back into the config-store (or equivalent
name). Rather than simply use a number as we did previously
perhaps the configId of the deployment would be appropriate.
Its human readable and would be shorter than the current maven
structure.* I highlighted the previous as I think this is the
best option based on what I know today.
Perhaps there some way to provide a Maven abstraction that would
map Maven dir names to an internal format for us. I expect if
we are running into this its only a matter of time befoew other
Maven users experience the same issues. For us its the nesting
of Maven articacts / configurations that is causing us the
problem. Jason, thoughts?
Whatever we decide we need to ensure that it is stable enough to
work for a period of time.
Matt
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}
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.
