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]
