Hi all
I'm going to try to summarize some of what has been said in this thread here and try to put things into perspective.
Deprecated API:s
This is a great way to enable smooth transitions between different versions. We all agree on this. To try and find out what has gone wrong I have just built commons-logging (1.0.4 RC1) with log4j 1.2.8 and I get no deprecation warnings at all. There seems to be two reasons for this:
1) commons-logging has deprecation=false in the javac-task. This makes it rather difficult to see any warnings.
2) log4j hasn't put @deprecated on the things that commons-logging uses. Even if 1 is fixed we still don't get any warnings from javac.
Version numbers
Together with deprecations this makes it easy (well sort of) to see which piece of software that is a drop-in replacement and which will require changes to your own code. In my book upgrading from 1.0.1 to 1.0.2 should be a walk in the park, but upgrading from 1.0 to 2.0 propably means I have to work late. If log4j decides to drop the Category class (which is their decision to make) I feel that would make it log4j 2.0 rather than 1.3. If commons-logging were to drop support for log4j 1.1 I think that would have to be commons-logging 1.1 rather than 1.0.4. Isn't there a document about this somewhere at Apache?
Supporting different versions of log4j in commons-logging
Today (well last week anyway) this is not a problem. With the upcoming release of log4j we are at the crossroads and have to make a decision. Several ideas on how to retain backwards compatibility has been to forward on this list. Personally I feel that Robert's suggestion of putting some reflection magic into the Factory is the way to go.
-- Dennis Lundberg
Shapira, Yoav wrote:
Hi, What about the option of having commons-logging 1.0.3 and earlier work with log4j 1.2.8 and earlier, and commons-logging 1.0.4 and later do whatever it feels like (since that's now possible with Ceki's recent changes)? I'm not gung ho about bending over backwards in order to not remove an API that's been deprecated for two years: that's the purpose of deprecation, to give people a warning that the deprecated item will be gone.
Yoav Shapira Millennium Research Informatics
-----Original Message----- From: Adam R. B. Jack [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 1:08 PM To: Jakarta Commons Developers List Cc: Apache Gump Subject: Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
On the log4j we are making a very serious effort to keep everyone happy.
And that is greatly appreciated. :)
I really wish you weren't having to go through this, I can hardly
imagine
how frustrating it must be to maintain an old interface for two years, attempting a clean deprecation, only run into such a gotcha. I do feel
for
you, and think users appreciate anything you can do to help.
Tell us specifically what fails and we will do our best to fix it. Rolling back everything is not specific enough.
Then can I say, whatever "changed in the public API"? ;-) Seriously
though,
I'd mentioned them previous in thread. That said, this thread has
morphed,
moved over 4 list, etc, so here again:
Best I can tell from here:
http://lsd.student.utwente.nl/gump/project_todos.html
These two are the Priority deprecation:
http://lsd.student.utwente.nl/gump/jakarta-commons/commons- logging/index.html http://lsd.student.utwente.nl/gump/jakarta-velocity/jakarta- velocity/index.html
You already reverted this one, thanks (it was RootCategory, I think):
http://lsd.student.utwente.nl/gump/avalon-excalibur/excalibur- logger/index.html
Again, these are only the ones I can tell from within Apacge/Gump.
External
users who've not moved from Priority, are probably the same.
Moreover, we have provided very clear set of instructions that safely address the c-l compilation problems. I think log4j is the wrong tree to bark at.
I noticed that <http://gump.covalent.net/log/bootstrap-ant.html>bootstrap-ant no
longer
builds. Is it a related problem?
Hmm, good question. Seems possible, but odd that it works here: http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/index.html
http://lsd.student.utwente.nl/gump/ant/bootstrap- ant/gump_work/buildscript_ant_bootstrap-ant.html
(although here it assumes no log4j).
The check does look for :
<available property="log4j.present" classname="org.apache.log4j.Category" classpathref="classpath"/>
Did that change?
I'll ask a Gumpmeister (who has access to that box) to take a closer
look,
and get back to you.
regards,
Adam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
--------------------------------------------------------------------- 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]
