Peter Donald wrote:
>
> At 06:36 2/5/01 -0700, Berin Loritsch wrote:
> >Forgive me, I am not at my regular computer so I can't
> >post this to the list.
> >
> >Anyway, I just thought of one last change we need to
> >apply before code freeze: Avalon LogKit needs to be
> >migrated to org.apache.avalon.log package. If we wait
> >to do it, then it will cause incompatibilities with
> >any class that implements Loggable.
> >
> >If you feel strongly that we shouldn't migrate LogKit
> >at this time, please forward this message to the list
> >and we can vote on it (or I can ;-).
>
> I would prefer not to migrate for one simple reason - a lot of people and a
> lot of my code already relies on it sitting exactly where it is now. While
> most of these people have moved to log4j I still have large proportions of
> code that would be a PITA for me to migrate. If there is no everiding
> reason to move it I would prefer it if we don't ;)
The only point I will make is if we don't do it now, we don't do it.
As Avalon Framework gains users, and by extension so does LogKit, the
cost of changing the name space only goes up by an order of magnitude.
We could do an official release of LogKit with the new name space (your
code would simply be using an old jar).
I am not adamant about LogKit and Testlet being in org.apache.avalon.*.
I am adamant about once we release, we maintain a stable API. Because
a portion of the Framework (the Loggable interface) is dependent on an
outside jar, we have a potential sore spot if that jar migrates its
name space later. Granted, this is minimized if people use the
AbstractLoggable class--but you can't use AbstractLoggable from static
methods...
VOTE
----
I am presenting the vote as an issue we need to clarify officially for
Beta 1 release (API stability):
**Do we migrate org.apache.log to org.apache.avalon.log?
I am +0.
Peter is obviously -1.
If no one else has strong convictions on this, I suggest using the "no"
course of action below.
COURSE OF ACTION
----------------
Yes) We do the migration by Friday May 4 and release LogKit 2.0b1(?)
along
with Avalon Framework/Excalibur 4.0b1
No) We do NOT migrate LogKit for a LONG while (at least two full
release
cycles for Framework). In any event, LogKit (version number?)
should
be marked Beta1 along with Framework/Excalibur
REASONING
---------
LogKit, Framework, and Excalibur are projects that are used directly by
developers. It is critical that the API be stable. There really hasn't
been much change to the LogKit API in a while--mostly just feature
enhancements and bug fixes. The critical API used in clients is the
Logger interface (which hasn't changed almost since the beginning) and
the LogKit static class. The rest of it can continue to change as needs
arise.
Testlet, while used by Excalibur, is not directly used by clients, so it
is not critical to be migrated to the org.apache.avalon.testlet package
nor is it critical that the API remain the same.
When I say the API must be stable, I am referring to the Interfaces that
clients directly interact with. The process of setting up a log target
can change more often than the process of calling the logger because the
cost of change is much lower (a few lines vs. a few hundred lines).
Even
then, the decision to change the set up logic should be done carefully.
After all we don't want to piss people off just because we can.
I will note, that Log4J Category and LogKit Logger interfaces are almost
identical--so migration is not too difficult.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
