we could use it in tests, as long as it was not exported as a downstream dependency. Including it in tarballs is probably a blocker on ozone releases
On Wed, 15 Apr 2020 at 12:41, Wei-Chiu Chuang <weic...@apache.org> wrote: > Want to raise awareness of this issue. IMO this is a blocker. > > mvn dependency:tree > ... > [INFO] ----------------< org.apache.hadoop:hadoop-ozone-tools > >---------------- > [INFO] Building Apache Hadoop Ozone Tools 0.4.0.7.1.1.0-SNAPSHOT > [19/33] > [INFO] --------------------------------[ jar > ]--------------------------------- > [INFO] > ... > [INFO] +- org.openjdk.jmh:jmh-core:jar:1.19:compile > [INFO] | +- net.sf.jopt-simple:jopt-simple:jar:4.6:compile > [INFO] | \- org.apache.commons:commons-math3:jar:3.1.1:compile > [INFO] +- org.openjdk.jmh:jmh-generator-annprocess:jar:1.19:compile > ... > > We can't use jmh because they are GPL 2 w/ Classpath Exception. > https://www.apache.org/legal/resolved.html > > We also include jmh artifacts in test scope in other modules. > > > Looking at how other projects deal with this situation, there are a few > solutions to it: > 1. Make a profile such that the jar is not included in the release / > optional https://issues.apache.org/jira/browse/RYA-373 (Apache Rya) > 2. Replace the GPL w/ Classpath Exception with something Apache licensed. > https://issues.apache.org/jira/browse/LEGAL-396 (Apache Lucene) > 3. It was also suggested to declare jmh in provided scope so we don't ship > it. (not sure if this is possible. Does JDK runtime provide jmh?) > https://issues.apache.org/jira/browse/LEGAL-399 Apache Calcite > > What should we do? Is there any way we can ship JMH? Otherwise I fear we > would end up making an emergency release just to exclude it. >
