Annotation processing is a standard feature of the JDK compiler. I don't know about Eclipse's compiler, but I'd imagine that should support them, too.
On 1 June 2014 08:12, Gary Gregory <[email protected]> wrote: > Or have eclipse call our annotation processor on demand or on a compile... > There must be a way to do that... > > Gary > > > -------- Original message -------- > From: Remko Popma > Date:06/01/2014 03:00 (GMT-05:00) > To: Log4J Developers List > Subject: Re: NPE in RandomAccessFileAppenderTests > > 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 >>>>>> <http://www.manning.com/bauer3/> >>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>>>>> Spring Batch in Action <http://www.manning.com/templier/> >>>>>> 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 >>> <http://www.manning.com/bauer3/> >>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >>> Spring Batch in Action <http://www.manning.com/templier/> >>> 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 >> <http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> >> > -- Matt Sicker <[email protected]>
