The rat plugin will probably help in preventing a release with incompatibly licensed code. I'm not going to get into a debate about licensing, though, because I'm also a free software (GPL/etc.) advocate as well (at least for non-library code).
On 25 May 2014 16:25, Gary Gregory <[email protected]> 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. > > 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? > > > -- Matt Sicker <[email protected]>
