Let me see if I understand. We could for the interim switch to a different logging framework like slf4j or logback that is widely used, mature, performant, etc in large part to avoid these problems mazz and others have hit. At some point in the future though, we once again revert back. Why? > On Feb 4, 2015, at 3:20 PM, Heiko W.Rupp <hrupp(a)redhat.com&gt; wrote: > > Perhaps interim. But not for medium or long term. > >> Am 22.02.2015 um 20:08 schrieb John Sanda <jsanda(a)redhat.com&gt;: >> >> At the risk of sounding like I have come unhinged, what about a fourth >> option? Use a simpler, yet performant solution like slf4j or logback. >> >>> On Feb 4, 2015, at 1:53 PM, John Mazzitelli <mazz(a)redhat.com&gt; wrote: >>> >>> Well, that didn't take long. As predicted by John "Trelawney" Sanda, in >>> only took a few days after integrating with jboss logging that we've hit >>> a pretty nasty javac bug. >>> >>> Peter and I have investigated a little and found the following that look >>> related: >>> >>> https://jira.codehaus.org/browse/MCOMPILER-236 >>> >>> https://bugs.openjdk.java.net/browse/JDK-8067747 >>> >>> There are several workarounds that we've discovered: >>> >>> 1) Always do a mvn clean before building. If you "mvn clean install" >>> things work. If you later to "mvn install" you will fail to build. This >>> is "less than optimal" because it requires everyone to always clean >>> before building thus forcing the entire project code to be recompiled >>> each and every time. >>> >>> 2) Move the bsc plugin version down from 2.2.4 to 2.0.2. Though the bus >>> modules build successfully with this, Peter says this causes other >>> things to fail to build (IIRC, alerts was one of them). >>> >>> 3) Set the bsc plugin configuration setting "addCompileSourceRoots" to >>> false (which is the default if not specified, but it is specified today >>> and set to "true" in parent-pom). I am not sure exactly what >>> addCompileSourceRoots does, but I think it adds generated source to the >>> list of source directories that get processed by the annotation >>> processor. I doubt (though I don't know for sure) that our other >>> generated code (like antlr) actually use the jboss logging annotations, >>> so I therefore doubt we actually need this setting to be "true." >>> >>> I have found either of those three work around the issue. I think #3 is >>> probably the best, unless someone knows for sure that we need that >>> setting to be true. >>> >>> FWIW: You can read about the bsc plugin options here: >>> http://bsc-documentation-repo.googlecode.com/svn/trunk/maven-annotation-p... >>> - perhaps there are other settings we can set to workaround the issue? >>> _______________________________________________ >>> hawkular-dev mailing list >>> hawkular-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hawkular-dev >> >> >> _______________________________________________ >> hawkular-dev mailing list >> hawkular-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hawkular-dev > > -- > Reg. Adresse: Red Hat GmbH, Technopark II, Haus C, > Werner-von-Siemens-Ring 14, D-85630 Grasbrunn > Handelsregister: Amtsgericht München HRB 153243 > Geschäftsführer: Charles Cachera, Michael Cunningham, Paul Hickey, Charlie > Peters > _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev