commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@apache.org>
Subject Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
Date Wed, 19 May 2004 19:12:59 GMT
You guys stopped me in my tracks for a mo, and I am (in my time) trying to
get towards Gump w/ specific versions, but for here and now ...

> "If it ain't broke, don't fix it."

I can understand that for larger projects, but not for
infrastructure/wrappers like C-L. C-L, by it's nature, is sitting in an
environment fed to it by others, is impacted by the decisions of others
(above and below). I'm not knocking C-L, please, this is for discussion
only...

> GUMP acts as an early warning sign, but if a project doesn't care to
update
> dependency X because there is no reason to change, but does care about
> tracking important dependencies, that needs to be accomodated.

Understood. Recall, we can do that with Gump today (if not as cheaply as
packaged releases) and we even do for log4j -- we have log4j-12 as well as
log4j (HEAD). What occured though was that (as you gave in an example) AXIS
got it's log4j from another place than C-L and failed to run. This is trying
to alligh projects, and requires inter-project communication.

> For the sake of argument, let us say that a project doesn't care about
> tracking Log4J, but does care about DBCP and Avalon.  It could have an
> indirect dependency on Log4J via two paths (hypothetically, for
> illustration, via Avalon and Commons Logging).

Yup, this is jar hell. :-) I don't have an answer, but it is why I work on
this (in what spare time I find, which it little):

    http://incubator.apache.org/depot/version/
    http://incubator.apache.org/depot/version/jar-hell.html
    http://incubator.apache.org/depot/version/overview.html

I'm going at a snails pace [and need to get to fix that site], and kinda
expecting Sun to fix it before I get anywhere useful, but hey, no harm in
trying...

> This is the mixed issue with GUMP.  It acts as an early warning sign, but
it
> also pushes projects to accept leading edge changes in order for GUMP
builds
> to work, which may push them into using unstable code.

Yeah, there are risk to staying up to the minute, and risks to falling too
far behind (and not being able to catch up). Of the two, I'd rather lean
towards the former (because of Jar-Hell, and becase [as I was told on this
list] one get's better OSS support with new releases). That said, I think
there is a balance, and Gump needs to allow/support it.

> No answers.  Just observations.

Same here.

regards

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message