logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: JMH for log4j microbenchmarks
Date Mon, 26 May 2014 12:31:21 GMT
On Sun, May 25, 2014 at 5:25 PM, Gary Gregory <garydgregory@gmail.com>wrote:

> Over in Commons VFS we are not adding a pom dep to a jar because it's
> license is not ASF compatible, which is ASF policy from what I understand
> and how it has been explained on the ML. Ii sounds like the same problem
> here.
>
> Gary
>
>
> -------- Original message --------
> From: Ralph Goers
> Date:05/25/2014 02:26 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: JMH for log4j microbenchmarks
>
> This is a very good idea.  You really don't have a lot to worry about. ASF
> projects can use GPL tools to build or do things like you are suggesting.
> However, we can't ship things that are under the GPL and should not commit
> them to svn. From what you are describing I don't think we would be doing
> that.
>

>From https://www.apache.org/licenses/GPL-compatibility.html

"We avoid GPLv3 software because merely linking to it is considered by the
GPLv3 authors to create a derivative work. We want to honor their license.
Unless GPLv3 licensors relax this interpretation of their own license
regarding linking, our licensing philosophies are fundamentally
incompatible. This is an identical issue for both GPLv2 and GPLv3."

So if we link to any GPLv2 or GPLv3 in our sources and we ship these
sources, we are creating a derivative work, which we are not allowed to do
because, as the ASF, "We want to honor their license".

Am I reading this wrong?

Thank you,

Gary


>

> The log4j-dist module controls what is included in the release. As I
> recall it is already excluding some things so this be easy to do. However,
> the release zips the whole source tree, so as long as there is nothing GPL
> there we are good.
>
> Fwiw, my surgery is done. I am at home and feeling ok, under the
> circumstances.  I can only see from one eye right now so please excuse
> mistakes.
>
> Sent from my iPad
>
> On May 24, 2014, at 10:42 AM, Remko Popma <remko.popma@gmail.com> wrote:
>
> I've been using JMH (http://openjdk.java.net/projects/code-tools/jmh/ )
> for performance tests recently and I'm very impressed. JMH is developed by
> the Oracle java performance team and used internally by Oracle to
> performance tune the JVM and java core libraries.
>
> I would like to use JMH to start building a suite of performance tests for
> log4j2. I would like everyone's thoughts. First, do you like this idea at
> all?
>
> Also, there is one legal and one technical aspect that I would like
> everyone's feedback on.
>
> A potential legal problem is that JMH is made available under GNU GPL v2
> with the Classpath Exception, and our Apache License v2 is not compatible
> with GPL v2 (see http://www.apache.org/foundation/license-faq.html#GPL ).
>
> To solve this, I want to avoid distributing JMH or our executable
> microbenchmarks  (which would have the JMH classes) with our log4j
> artifacts. I just want our team (and whoever checks out the log4j source)
> to be able to use JMH to genyerate and run benchmarks when they want to.
>
> I'm not a lawyer though. Does anyone have experience with this kind of
> question?
>
> The technical aspect:
> I propose adding a log4j-perf module. This is where our performance test
> code would live. JMH microbenchmarks are very simple java classes with
> org.openjdk.jmh annotations. During the build, JMH generates code and that
> generated code, together with all dependencies are zipped up in a large
> uber-jar with the maven Shade plugin. You can then use java -jar
> microbenchmarks.jar to run performance tests.
>
> To ensure that the log4j-perf artifacts are not included in the log4j2
> distribution, we could simply leave out the "<module>log4j-perf</module>"
> line from log4j2/pom.xml. The drawback is that you'd need to manually add
> that line and build again if you want to execute microbenchmarks to test
> something that only exists in your workspace. Is there a better way, to
> somehow include the log4j-perf module in the build, but exclude its
> artifacts from the log4j2 distribution?
>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
View raw message