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.
>
>
>
>
>
|