Which is why GUMP should allow projects to specify dependencies on SPECIFIC versions of other products....
-----Original Message----- From: Noel J. Bergman [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 2:42 PM To: Jakarta Commons Developers List Subject: RE: [logging][PROPOSAL] a solution to incompatibility between log4j versions > I wish projects had stopped using deprecated stuff a year ago, heck > ... or two. "If it ain't broke, don't fix it." Stable projects do not like making change for changes sake. Have you noticed that although Sun deprecates methods, they rarely remove them unless there is a real security concern? 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. 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). 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. No answers. Just observations. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
