You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/05/03 06:16:51 UTC
[VOTE] Re: Avalon LogKit
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] Re: Avalon LogKit
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
>
> At 12:16 3/5/01 -0400, Berin Loritsch wrote:
> >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
>
> Would you mind waiting to the 5th - then I could update Logkit the way I
> wanted to and that should remain stable.
Nope. Don't mind a bit.
> >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)
>
> I don't think it has changed in any non-backwards incopmatible way at all ;)
That's cool. But the time to change is upon us. Might as well sneak a few
cool features in as well.... :)
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE] Re: Avalon LogKit
Posted by Peter Donald <do...@apache.org>.
At 12:16 3/5/01 -0400, Berin Loritsch wrote:
>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
Would you mind waiting to the 5th - then I could update Logkit the way I
wanted to and that should remain stable.
>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)
I don't think it has changed in any non-backwards incopmatible way at all ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [VOTE] Re: Avalon LogKit
Posted by Stephen McConnell <mc...@osm.net>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, 03 May, 2001 06:17
> To: Avalon Development
> Subject: [VOTE] Re: Avalon LogKit
>
>
> 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.
Ummm, mixed convictions ... +0.
(meaning support for the "No" couse of action detailed below).
Cheers, Steve.
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org