On 10/30/01 10:04 AM, "Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> Sam Ruby wrote: > >> Suppose I as an end user / deployer wish to use two independent projects, A >> and B. And suppose projects A and B have a common dependency, C. But A >> only works with version 1 or 2 of C. And B only works with version 3 or >> later of C. > > sorry but I don't get the problem associated with this. If "deploy" > means run from command line, then the two projects will have different > JVM that will have different classpaths, each with the version they care > bout. > > If deploy means "war-like deployment", then the container will provide > two different classloaders that will seal classname collisions. > >> This is the situation I always found myself in when dealing >> with Cocoon version 1. In particular, the database pooling dependency on >> Turbine was deprecated, removed, and long since a memory. > > Cocoon1 is almost dead. The problem was that people were so excited > about the planned features of Cocoon2 that stopped working on Cocoon1, > add my departure, stirr and you have a bunch of issues. > >> A more current example: Tomcat 4.0.1 ships with a jar which contains a >> class with a static initializer which calls a method which was deprecated >> in log4j 1.1. This method has since been removed from cvs and therefore >> will not be present in log4j 1.2. I've complained, and even provided a >> patch using reflection. But the patch has yet to be applied, and the code >> shipped anyway. >> >> So the moral of the story is: once log4j 1.2 ships, if you put it in your >> manifest, make sure to tell your users to stay away from Tomcat 4.x (Tomcat >> 3.x is just fine). > > We use LogKit exactly to avoid those static initializers :) > > Anyway, I see your point. > >>> Why so? well, it's ok to force people to watch how their changes impact >>> on others, but this is a development thing, users don't care. users want >>> something that works and developers cannot always know that after a >>> release, the required libraries will remain the same. >> >> Actually, this is the key point. The *ONLY* way to fix the problem >> described above is to adjust developers behavior. Break out of your cocoon >> *grin*. Let go of the notion that you control your users. Accept the >> notion that your users will mix and match. If you insist on keep jars in >> cvs, then by all means keep *OLD* jars in cvs. Gump will ensure that you >> work against the latest. By testing against a range, you keep your user's >> options open. >> >> Only then will a apt-get, rpm-find, or cpan like facility ever be practical >> for anything other than delivering the complete release packages >> specifically crafted by release owners of various projects. > > I understand perfectly, but it's a catch-22 situation: without a CJAN, > people will not remove jars from CVS. And with jars in CVS, GUMP doesn't > do its job well, project interdependencies cannot be fixed and a CJAN > cannot be built. > That's not true on two counts : 1) TPFKAJJARWMGRF (The Project Formerly Know As JJAR Which Might Get Renamed 'Fetch' ) is independent of Gump. There might be some dependency sharing, of course, but they aren't related. 2) - I think you are redefining what Gump does -> If the purpose of Gump is to build HEAD against HEAD as an early warning system, then jars and versions are irrelevant because gump should and rightly does ignore such info. If gump is to be an auto build utility (i.e. Cvs checkout foo; cd build; ant ) then there might be something there, but how many times should the same release disto be rebuilt until we are convinced that it builds ? :) I think gump is infinitely more valuable doing the former. > Now, how do we remove the deadlock? I don't see it as a deadlock. geir -- Geir Magnusson Jr. [EMAIL PROTECTED] System and Software Consulting "Whoever would overthrow the liberty of a nation must begin by subduing the freeness of speech." - Benjamin Franklin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
