It is failing trying to sign the distribution. You need to create a code signing certificate. The directions are on the ASF web site.
Sent from my iPhone > On May 25, 2014, at 9:29 AM, Remko Popma <[email protected]> wrote: > > 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? >
