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?
> 

Reply via email to