Hi, > So, is the only concern the brand name "JCL"? It seems to be.
Yup. > 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. > 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. > 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. > 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. > 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. > 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. > 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. 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. Yoav --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
