On 11/1/01 7:57 AM, "Sam Ruby" <[EMAIL PROTECTED]> wrote: > Geir Magnusson Jr. wrote: >> >> I believe that the dependency chain is 'self cleaning' as it's version >> specific (notation A:X -> package:version ). With something simple : >> >> A:X depends on B:Y and C:Z >> >> Now, I assume that since the developer states the above as true, it was >> tested, and any implied dependency chains extending from B:Y and C:Z also >> work together, else the above statement about A, B and C isn't true. (Or it >> wasn't tested as such.) >> >> I know that this appears to be trivial - however, I think it isn't. Lots of >> problems get solved by recognizing this. Not all, but lots. > > If you hadn't noticed, the release manager for "A" probably created a > simple download that contains A:X, B:Y, C:Z, and the recursive closure of > the dependencies. A single download, and unpack, and I'm likely up and > running - as long a "A" is all that I need.
Clearly. > > Life gets interesting when you ask questions like "will Tomcat 4.0 work > with Cocoon 2.0". Neither package contains the other. The release maanger > for Tomcat 4.0 includes a recent, released version of crimson.jar. The > release manager for Cocoon 2.0 includes a recent, released version of > xerces.jar. Boom. All of Criag's efforts, and he could not get the > isolation that a web app is supposed to provide to reconcile this > situation. > I thought Tomcat shipped special modified jars to avoid a sealing exception... > Tomcat 4.0.1 ships Xerces. I understand this - this is the problem that Gump is going after, as I understand it. This is not an issue that relates to getting a set of released dependencies for a released package. Because if I will never claim my project needs both Tomcat 4.0.1 and Cocoon 2.0. Because they don't work together, as you claim. (I don't know if that is true - I take your word for it.) Therefore, my JJAR enabled project won't require JJAR to get tomcat and cocoon because they don't work together. See where I am coming from? I see where you are coming from - that GUMP can help find these collisions before developers try to meld these components together into new applications (or other components - like Velocity is dep on a few other components...) and find the problems themselves. However, it's not a problem JJAR faces, because the dependency clashes are worked out ahead of time by the human who declares that their project WOOGIE requires FOO and BAR. By definition, FOO and BAR have to work together. If they don't, then claiming the dependency relationships is an error. There is no warranty expressed or implied that WOOGIE works with anything else, but there is no information to support that anyway, and not a local requirement for the person who wants to just fetch WOOGIE and its dependencies. > = = = = > > Velocity depends on commons-collections. Tomcat-4.0 does too. Velocity > does not depend on Tomcat. Tomcat does not depend on Velocity. User often > want to run them both together. (btw, I think you now need to add commons-collections specifically to the classpath for the gump Velocity test case, as our default jar now doesn't contain anything... More on that from the vel list...) So? I use JJAR to get tomcat, and it fetches all stated dependencies, including the collections dependency (and all implied dependencies...). I use JJAR to get velocity, and it gets the dependencies. JJAR's mission is complete. So far, no one has claimed anything other than JJAR will get the package and dependencies required for it, and it does that just fine for each. Now - when the user tries to combine, *then* there may be problems. JJAR can't predict how the user will put things together, nor should it try. GUMP really can't either "Thou shalt not...", but can explore the parameter space of combinations, and then make statements of "Thou can not..." That would be an interesting thing - a webapp that uses everything and anything, and GUMP can have a testcase to see if the thing can play together every night, because right now you are testing builds, fundamentally static interdependencies (via import...) but dynamic interdependencies are transparent at the moment... geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting You're going to end up getting pissed at your software anyway, so you might as well not pay for it. Try Open Source. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
