Quoting Yoav Shapira <[EMAIL PROTECTED]>: > Hi, > > > So, is the only concern the brand name "JCL"? It seems to be. > > Yup.
We for me, the brand name "JCL" carries a lot of baggage with it and if JCL 2.0 is supposed to be the new official logging API, it will take some time get over my nauseous aversion to the name even if it finally works properly. So far from the name being an advantage, to someone like me, it is a severe disadvantage. But I suppose I'm in the minority. > > > If the > > code is > > going to be completely different and not backwards compatible with the > > existing > > "JCL" it isn't really "JCL", so why call it "JCL"? > > Because the brand name is powerful and will lead to rapid adoption. > Powerfully revolting, but I digress... > > Why not call it > > "UGLI"? And > > Because that's an ugly acronym (pun intended) and an unfamiliar one, leading > to "yet another logging interface" discussions. > I actually like the UGLI name. I find pleasure in the idea of producing a product that is so good, people just need to use it despite the fact that they may choke a bit on the name :-) As for "yet another logging interface" (YALI), JCL 2.0, if it ever comes to fruition (remember, UGLI actually exists and works!), being backward incompatible, is essentially a new logging interface. So whether we talk about UGLI or JCL 2.0, we are definitely talking about YALI. However, I suspect that you agree with me on this and are just saying that people will percieve UGLI to be YALI and not JCL 2.0, even though both are. Am I right? > > if it has to do with logging, why should it be a Jakarta project when > > there > > exists an official Apache logging services project? > > It can be moved to a Logging Services project, doesn't have to stay within > Jakarta. > And then no longer be called JCL "Jakarta Commons Logging", thereby ruining the brand? > > It seems to me that > > UGLI > > has already solved the problems that the proposed JCL 2.0 is supposed to > > solve. > > UGLI hasn't solved anything in practice, because there's no one using it. > If you take UGLI and call it JCL 2.0 (having obtained consensus from the JCL > team), then you have a point. > Until I see this happen, I have serious doubts that the JCL (1.x or 2.x) team will accept this. Make me a believer! > > And if UGLI hasn't completely addressed all logging API issues, then why > > doesn't the JCL 2.0 team accept that there has already been work done to > > There's no such thing as a JCL 2.0 team at this time. There's also no > argument about whether UGLI has addressed all the issues: if UGLI hasn't > done so already, it surely will shortly. > Which is why I have a hard time even understanding why such a team is proposed when UGLI already exists. The first question should have been "can UGLI be utilized to solve our issue"? If the major concern is branding, then the fact that UGLI wasn't the first option tells me that there is a conscious effort to eschew UGLI from consideration. I certainly haven't seen such a proposal from the JCL people on the Log4j mailing list. Is such a proposal on its way? > > I don't mean for this to be flamebait. > > It's not, or at least I'm not taking it as such. The questions are good. > > > I'm just really perplexed as to > > why JCL > > 2.0 is needed now that UGLI exists? > > Because I don't think anyone will adopt UGLI quickly. It's "yet another > logging interface" to most people. > Same question, above, applies. > > The fact > > that > > there still exists a group in Apache developing a logging API that > > continues to > > work outside the official logging services project is awefully strange as > > well. > > I can understand this between completely separate open source entities, > > but not > > within the same (Apache) organization. Very strange. > > Top-level projects within the ASF are almost entirely separate > organizations. A good argument could be made that Logging Services should > have taken JCL with it when moving Log4j out of Jakarta. A good argument > can be made that the same applies now: we should move JCL out of Jakarta and > into Logging Services. > > In addition, two other small points: there's not much active development on > JCL at the moment. And lack of coordination between organizational entities > is not at all a strange phenomenon: it's a sub-optimal and sometimes even > bad one, but it's common unfortunately. We need to proactively work on > better coordination. > As soon as I see a willingness on the part of the JCL team to do this, I will believe that it is possible. > This is not a discussion of technical merits for the most part. I don't > doubt UGLI is much better. I do doubt people will be eager to adapt it > without a massive and prolonged marketing campaign. That campaign could be > made much easier and shorter if we called it JCL 2.0. > Again, I have yet to see the proposal from the JCL team. It should have been the first question to come up, and it should have come up a long time ago. Maybe I'm watching the wrong lists? But if they want to work proactively with Log4j, which currently develops UGLI, then it would behoove them to contact the Log4j list, in which case I would most definitely see it. Jake > Yoav > > > --------------------------------------------------------------------- > 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]
