----- Original Message -----
From: "Niclas Hedhman" <[EMAIL PROTECTED]>
To: "'Log4J Developers List'" <log4j-dev@logging.apache.org>
Sent: Saturday, May 21, 2005 9:04 PM
Subject: Unfortunate Confusion signals to market
Gang,
Trying not to be sarchastic or disrespectful, and only giving a hint of
how I
perceive stuff at the moment.
And completely welcome.
Currently, the Log4J project is in a disarray and conflicting messages are
being sent to the users.
No doubt.
IMHO, SLF4J is a hasty conversion of UGLI and has not gotten much feedback
from the JCL camp, as was hoped for. And I seriously think that SLF4J is a
well-meant mistake.
For everything that has happened because of the whole slf4j thing (around
the 1.2.10 release), I kind of wish it had not happened. At least not in
the way it has. But it has acted as a wake-up call.
But slf4j has only been around for a month and half? Isn't it a bit early
to call it a mistake? Sounds like there needs to be some more evangelizing
of the JCL camp. Has the slf4j community grown in any way since its
inception?
Bring the "static linking" concept over to JCL instead, into a version 2
(or
3) and leverage the market that JCL in fact has. It should be much
different
than the now competing approach.
Who is working on JCL nowadays? I was under the impression that discussions
had already been under way with the JCL folks and moving out to slf4j was
something they wanted too.
Log4J should continue its current approach of being an implementation, and
hopefully get a slightly better focus on "breaking apart" the internals,
so
that it consists of;
1. a toolkit of useful parts.
2. one (or more) ready-to-deploy solution(s).
but the parts in the toolkit could be used in other deployment scenarios,
for
instance in the fields of configuration, framework integration or
minimalistic deployments.
The current affair of;
* Log4J 1.2.10 -> 1.2.11
1.2.10 should never have happened the way it did. If there had been decent
communication and process around it, we would not be where we are today.
* NLog4J
The log4j project had no control or input into the creation of this project.
I wish it had never happened. I question the wisdom of doing it. Given the
apache license, people are free to do what they want. I have suggested that
an "experimental" release of log4j would accomplish the same thing with a
lot more clarity and a lot less confusion. It got a luke warm response. At
least it was warm though. However, it is up to the slf4j project to decide
the fate of nlog4j.
* SLF4J native or facade support
We are still working through it, and there is some discussion on it. I
don't have a serious problem with a direct implementation, especially in the
experimental release.
* various flip-flopping of version numbers
That discussion has only been going on here on the dev email list, and I
don't make any apologies for that. We are allowed to hash out what we want
to do. We are going to move forward. Outside of log4j-dev, there has only
been the announcment of the 1.2.10 release (unfortunate) and the
announcement of the latest release schedule. 1.2.11 is going to happen. We
might, now with more vocal input, change the nature of the 1.3 release and
move the "current" 1.3 release to 1.4. We'll explain it as we go. But we
are going.
* introduction of new features in a 1.2.x point release.
You mean TRACE? I guess we can call it a new feature. We are discussing
the change of the version number to 1.3. But obviously this is going to
cause confusion with what we have been calling 1.3.
is bad for the market. This can't be hard.
You'd think not. There was little to no discussion previously, and little
push to seriously outline upcoming releases, so at least we are now talking
about stuff more. And I said, we will move forward and explain what we are
doing as we go. That is the best we can do. We should not be
hampered/hindered in moving forward where we think it is important.
The log4j project can only truly affect things to do with the log4j project.
We are going to move forward with things that we can affect. We are working
to support slf4j. If we need to do more to facilitate stuff with the JCL,
we should look at it. But we need to get our own house in order and get
moving on our releases. We have been working on the current cvs head for
too long without a major release.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
