Or have eclipse call our annotation processor on demand or on a compile... There must be a way to do that...
Gary <div>-------- Original message --------</div><div>From: Remko Popma <[email protected]> </div><div>Date:06/01/2014 03:00 (GMT-05:00) </div><div>To: Log4J Developers List <[email protected]> </div><div>Subject: Re: NPE in RandomAccessFileAppenderTests </div><div> </div>I've just set up a recent version of Eclipse and if you make a project a Maven project it is possible to run the Maven build from Eclipse. I haven't explored this in depth yet. By default Eclipse just compiles the modified classes when you save them and does not run a full build, maven or otherwise. It is possible of course to use remote debugging which has the benefit of giving you an environment that is closer to what end users see. I also see Gary's point of wanting the convenience of being able to quickly run JUnit tests from the IDE without going through an 5-8 minute build for every minor code change... I still think configuring the "packages" attribute in the test config files gives you the best of both worlds... On Sun, Jun 1, 2014 at 3:37 PM, Ralph Goers <[email protected]> wrote: I'm confused. I thought the changes made to use an annotation processor at compile time meant that the plugins.dat file would be generated then, so the file should be available on the classpath. Unless, of course, Eclipse is not actually using maven to compile. To be honest I have no idea if this problem exists in IntelliJ as I always compile and test from the command line and use remote debugging. As far as I am concerned that is the only supported configuration. Ralph Sent from my iPad On May 31, 2014, at 9:57 PM, Remko Popma <[email protected]> wrote: But isn't that the trade off that was made with the plugin mechanism? Log4j2 will search for plugins in plugins.dat or in configured packages, but for performance reasons it won't search the entire classpath. The plugins.dat file is generated automatically during the build, so when run from the IDE there is no plugins.dat file yet. I see three options (there may be more): 1. We can change the plugin mechanism to facilitate testing from IDEs. No ideas on how, though. (Whatever change we make obviously shouldn't impact external users.) 2. We can manually maintain a plugins.dat file (for the tests?) 3. We can specify "packages" in the test configs. I don't think that last option is that unreasonable, actually. Sent from my iPhone On 2014/06/01, at 12:01, Gary Gregory <[email protected]> wrote: Updating all configuration files to fix IDE development seems wrong. It feels like we have a bug in our test infrastructure. Gary -------- Original message -------- From: Remko Popma Date:05/31/2014 21:40 (GMT-05:00) To: Log4J Developers List Subject: Re: NPE in RandomAccessFileAppenderTests Specifying "packages" in config will work in both maven and Eclipse, I think (unless I'm missing something). Sent from my iPhone On 2014/06/01, at 8:33, Gary Gregory <[email protected]> wrote: No, but the test should run from Eclipse and Maven just the same. So... now what? Gary On Sat, May 31, 2014 at 7:16 PM, Remko Popma <[email protected]> wrote: Have you tried specifying "packages" in the config file of the test? Then no plugins.dat is necessary. Sent from my iPhone On 2014/06/01, at 2:44, Gary Gregory <[email protected]> wrote: So Eclipse cannot find the plugin dat file then? Adding the jar is not going to help if what I am doing is developing plugins... :-( I think there is some odd ball case where Maven copies the plugin dat file some place and then you do a refresh in Eclipse to pick it up. I've not found a reliable way to get this to work though. This is frustrating... Gary On Sat, May 31, 2014 at 1:01 PM, Remko Popma <[email protected]> wrote: I see the NullPointerException also when I run the test in Eclipse. If I revert back to the previous version of RandomAccessFileAppenderTest (before conversion to RuleChains) I don't see these NPEs. (However in the previous version the test still fails: [0], [1] and [3] cannot find the resulting log file, [2] finds a different log file). This last issue has to do with plugins not being found when running JUnit tests from Eclipse. A simple hack to fix this is to temporarily add log4j-core-2.0-rc2-SNAPSHOT.jar to the (end of the) classpath. This allows Eclipse to find the plugins and the tests pass. On Sat, May 31, 2014 at 11:31 PM, Gary Gregory <[email protected]> wrote: I said from eclipse: right click on the class, run as, junit test. Gary -------- Original message -------- From: Remko Popma Date:05/31/2014 09:30 (GMT-05:00) To: Log4J Developers List Subject: Re: NPE in RandomAccessFileAppenderTests I just updated and ran mvn eclipse package and I did not have any issues. Build success. On Sat, May 31, 2014 at 4:37 PM, Remko Popma <[email protected]> wrote: I'll take a look later today. Sent from my iPhone On 2014/05/31, at 15:40, Gary Gregory <[email protected]> wrote: When I run RandomAccessFileAppenderTests from Eclipse, I get an NPE. Does anyone else see this? Thank you, Gary -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition JUnit in Action, Second Edition Spring Batch in Action Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
