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.
Now, how do we remove the deadlock?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
