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

<div>-------- Original message --------</div><div>From: Ralph Goers 
<[email protected]> </div><div>Date:05/25/2014  02:26  (GMT-05:00) 
</div><div>To: Log4J Developers List <[email protected]> 
</div><div>Subject: Re: JMH for log4j microbenchmarks </div><div>
</div>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. 

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 <[email protected]> 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?


Reply via email to