Yeah, we may want to create another name at the same level as adapters and move web there too.
Ralph On Mar 25, 2013, at 3:04 PM, Nick Williams wrote: > Should this new artifact be a member of groupId org.apache.logging.log4j or > org.apache.logging.log4j.adapters? log4j-web is in adapters (not sure that > makes sense, but it is). log4j-tablib isn't really an adapter ... it's closer > to an extension of the API to support JSP tags. That says to me > "org.apache.logging.log4j." But it's up to y'all. > > Nick > > On Mar 25, 2013, at 10:49 AM, Ralph Goers wrote: > >> You are on the right track. >> >> Sent from my iPad >> >> On Mar 25, 2013, at 7:29 AM, Nick Williams <[email protected]> >> wrote: >> >>> I'm a little new to Maven (5-6 months), but I thought I understood >>> multi-module projects correctly. I could certainly be confused about >>> something. >>> >>> In /log4j/log4j2/trunk/pom.xml, log4j is a multi-module Maven project: >>> >>> <modules> >>> <module>api</module> >>> <module>core</module> >>> <module>log4j12-api</module> >>> <module>slf4j-impl</module> >>> <module>log4j-to-slf4j</module> >>> <module>jcl-bridge</module> >>> <module>flume-ng</module> >>> <module>web</module> >>> <module>samples</module> >>> </modules> >>> >>> So by "module" I mean <module>taglib</module> (which, by extension, is a >>> new artifact under the same groupId org.apache.logging.log4j). I do not >>> mean a separate project (new groupId), no. >>> >>> I definitely agree that it should be a new artifact/module, but I wanted to >>> make sure nobody had a convincing reason that it should be part of the >>> log4j-web artifact/module before I started writing. >>> >>> Nick >>> >>> On Mar 25, 2013, at 9:16 AM, Paul Benedict wrote: >>> >>>> If by module you mean a Maven module (another hierarchy of projects), then >>>> no. But definitely a new Maven artifact. >>>> >>>> Paul >>>> >>>> On Mon, Mar 25, 2013 at 8:06 AM, Gary Gregory <[email protected]> >>>> wrote: >>>> On Mon, Mar 25, 2013 at 8:58 AM, Nick Williams >>>> <[email protected]> wrote: >>>> Excellent! I figured as much, regarding SVN and patches. I'll get to work >>>> on it this week. >>>> >>>> One important question before I get started that I think only the >>>> community should answer: What should its Maven artifact and module names >>>> be? I'm thinking "log4j-taglib" and "Log4j Tag Library". >>>> >>>> Another possible option would be to simply make this part of the log4j-web >>>> module instead of making it its own module. I could certainly understand >>>> going that route. On the one hand, fewer modules can sometimes be less >>>> confusing. On the other hand, for some users (like me) they'll need the >>>> functionality of the log4j-taglib module but not the log4j-web module, or >>>> vice versa. I don't necessarily like the idea of putting this in >>>> log4j-web, but it might be a discussion worth having. Thoughts? >>>> >>>> >>>> For me, the fewer modules, the better. >>>> >>>> Gary >>>> >>>> Well Jakarta Log Taglib and SLF4J Taglib are both under Apache 2.0 >>>> License, so there won't be a problem there. Jakarta is an ASF project (and >>>> it's retired) so I don't believe I'll need permission there. I'll get on >>>> the SLF4J dev list and inquire for permission. SLF4J says it's based on >>>> Jakarta Log Taglib. Don't know if that makes a difference. >>>> >>>> Nick >>>> >>>> On Mar 24, 2013, at 11:51 PM, Ralph Goers wrote: >>>> >>>>> Thanks for the interest! Yes, I think having a tag library would be a >>>>> great addition. Since we are still using subversion I'm afraid the only >>>>> way to do this is for you to create a patch and attach it to a Jira. >>>>> Remko has recently done the same. I'd encourage you to create a separate >>>>> maven subproject and then you could just attach a zip of it. >>>>> >>>>> There are two basic rules at the ASF. 1) All code must be contributed >>>>> under the Apache License. You cannot copy code that is under an >>>>> incompatible license. 2) All code contributions must be voluntary - you >>>>> cannot contribute code that someone else wrote without their permission. >>>>> As a general rule you can copy code from other ASF projects but you would >>>>> need to get permission from projects hosted elsewhere. >>>>> >>>>> Ralph >>>>> >>>>> >>>>> On Mar 24, 2013, at 8:54 PM, Nick Williams wrote: >>>>> >>>>>> First, and introduction, since I'm new to this list: >>>>>> >>>>>> My name is Nick Williams, I'm a Software Engineer with UL (Underwriters' >>>>>> Laboratories) and an active member of the Open Source community. I've >>>>>> contributed to the Tomcat Project (most recently quite a bit, I've >>>>>> helped with the WebSockets implementation in Tomcat [1], though only has >>>>>> a contributor, not a committer) and worked on various other projects. >>>>>> Currently, I'm working on an improvement on Spring Security's Session >>>>>> Fixation Protection [2] and a new FasterXML (Mapping Jackson) module to >>>>>> support JSR310 (Java 8 Date & Time API) data types. I'm also author of >>>>>> the upcoming Wrox book Professional Java for Web Applications [3, the >>>>>> first public listing of the book I've seen online yet]. Now, with that >>>>>> said... >>>>>> >>>>>> The Jakarta Taglibs project used to have a logging tag library [4], but >>>>>> that project was retired years ago. SLF4J has a tag library sub-project >>>>>> [5], but it (obviously) uses the SLF4J API. It would be nice if the new >>>>>> Log4j 2 project had a tag library available when it releases (hopefully) >>>>>> later this year. >>>>>> >>>>>> The tag library is a very simple module. Eight or nine classes and a TLD >>>>>> are all that are needed. Jakarta Log Taglib and SLF4J Taglib (both >>>>>> Apache 2.0) have already done much of the hard work for us. I would be >>>>>> more than happy to spearhead the development effort to get this done. >>>>>> So, questions: >>>>>> >>>>>> 1) Is there interest in having this Log4j 2 module? I think it would be >>>>>> a great addition to the project. >>>>>> 2) What steps do I need to take? I'm used to submitted patches for >>>>>> Tomcat, but that could be very challenging for an entire module of the >>>>>> project (as small as that module might be). Still, it's doable. >>>>>> 3) I see no reason not to re-use viable code in Jakarta/SLF4J. In all my >>>>>> years working in Open Source, I've never actually ported/forked code >>>>>> like this. What are the "best practices," so not as to "steal" or offend? >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> [1] >>>>>> http://svn.apache.org/repos/asf/tomcat/trunk/webapps/docs/changelog.xml >>>>>> [2] https://jira.springsource.org/browse/SEC-2135 >>>>>> [3] http://109.107.134.101/wbook/bookdet.php?seq=840283 >>>>>> [4] http://jakarta.apache.org/taglibs/log/ >>>>>> [5] http://www.slf4j.org/taglib/ >>>> >>>> >>>> >>>> >>>> -- >>>> E-Mail: [email protected] | [email protected] >>>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0 >>>> Spring Batch in Action: http://bit.ly/bqpbCK >>>> Blog: http://garygregory.wordpress.com >>>> Home: http://garygregory.com/ >>>> Tweet! http://twitter.com/GaryGregory >>> >>> >>> --------------------------------------------------------------------- >>> 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] >> > > > --------------------------------------------------------------------- > 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]
