If I run mvn -P apache-release install, the build fails, and I get: [INFO] --- maven-gpg-plugin:1.1:sign (default) @ log4j --- gpg: keyring "C:/Users/remko/AppData/Roaming/gnupg/secring.gpg" created gpg: keyring "C:/Users/remko/AppData/Roaming/gnupg/pubring.gpg" created gpg: no default secret key: No secret key gpg: signing failed: No secret key
I could rename the module to log4j2-perf, but I'd like to see that this is necessary (that is, I'd like to confirm that it gets included in the distribution with the current name even after adding <dependencySet><excludes><exclude>org.apache.logging.log4j:log4j-perf</exclude></excludes> to log4j-distribution/src/assembly/bin.xml.) On Mon, May 26, 2014 at 12:41 AM, Ralph Goers <[email protected]> wrote: > Also, could you move SimplePerfTest there and run it under JMH? > > Sent from my iPad > > On May 25, 2014, at 8:35 AM, Ralph Goers <[email protected]> wrote: > > OK - in the parent pom you will see there is a profile for apache-release. > That profile is automatically set by the parent ASF pom during the release > plugin. But if you manually set the profile with -p or -P then it will > include the distribution module in the build. In the bin assembly you will > need to exclude the perf module. You may need to rename it as I have had > problems excluding modules that match the includes pattern. Actually, if > it doesn't match the includes pattern it won't be included in the binary > distribution anyway. > > Sent from my iPad > > On May 25, 2014, at 7:43 AM, Remko Popma <[email protected]> wrote: > > Wow, great! Take care and again, don't overdo it! > Any time is fine. > > I tried running mvn -P release install. > The build ran successfully, but ended in: > [WARNING] The requested profile "release" could not be activated because > it does not exist. > > I checked my local <user>/.m2/repository, and it looks like a log4j-perf > module is created there. > It contains log4j-perf-2.0-rc2-SNAPSHOT.jar, which is not the Shade-ed > microbenchmarks.jar, but still contains JMH-generated code so we probably > don't want to include this file in the distribution. (Not sure if any files > here would be included in the distribution.) > > > > On Sun, May 25, 2014 at 10:49 PM, Ralph Goers > <[email protected]>wrote: > >> I am surprised too. I only can see in one eye and I have to keep my head >> facing the ground most of the time but I can still use my iPad and phone. >> >> Mvn site does not build the distribution. I am actually at the dr to get >> my bandage off but I will check when I get home what you need to run but I >> think it might be mvn -P release install >> >> Sent from my iPhone >> >> On May 25, 2014, at 6:43 AM, Remko Popma <[email protected]> wrote: >> >> Ralph, thank you for your feedback. >> (I am actually surprised to hear from you, I thought you'd be out of >> commission for a while. Glad you're feeling well so quickly, but be careful >> not to overdo it.) >> >> I've added the log4j-perf module. Initially this has just one >> microbenchmark test. >> >> How do I verify that the microbenchmarks.jar does not get included in the >> distribution? >> Just run "mvn site"? >> >> >> >> On Sun, May 25, 2014 at 3:26 PM, Ralph Goers <[email protected]> wrote: >> >>> 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? >>> >>> >>> >> >
