Pretty much all of these require that your ide compiles with their jar in the classpath as a provided dep. Some IDEs also require explicit enabling of annotation processing. Maven integration is pretty tight wrt this in IDEs I've used.
When you change a source file, it is processed with auto or whatever, and either incidental source is produced and compiled, or the bytecode is altered directly, availing the new fields etc. Often, there is some concern about output directories for generated source or compiled files. -A On Nov 15, 2013 12:08 PM, "Zack Shoylev" <zack.shoy...@rackspace.com> wrote: > I didn't check - how's the IDE situation with auto? I might find the time > to add it in some refactorings I have to do anyways. > ________________________________________ > From: Adrian Cole [adrian.f.c...@gmail.com] > Sent: Friday, November 15, 2013 11:58 AM > To: dev@jclouds.apache.org > Subject: Re: Project Lombok - Builders (and other annotations) > > FWIW, I plan to help with auto anyway. If you have problems trying it out, > cc me on the github issue. > > -A > On Nov 14, 2013 10:42 PM, "Andrew Gaul" <g...@apache.org> wrote: > > > On Mon, Nov 11, 2013 at 11:11:35AM -0800, Andrew Gaul wrote: > > > On Mon, Nov 11, 2013 at 10:36:26AM -0800, Jeremy Daggett wrote: > > > > Hi devs, > > > > > > > > Has anyone in the community ever looked at using Project Lombok[1] to > > help > > > > simplify our source code? I stumbled across this a couple of years > > back > > > > and thought it was pretty useful. Just never had a chance to use it > > with > > > > anything... > > > > > > > > I think that the @Builder [2], @EqualsHashCode, and other annotations > > could > > > > make many of our classes much simpler. We might be able to get rid of > > all > > > > of that boilerplate code! ;) > > > > > > > > WDYT? > > > > > > > > [1] http://projectlombok.org/ > > > > [2] > > > > > > > https://github.com/rzwitserloot/lombok/blob/master/src/core/lombok/experimental/Builder.java > > > > > > -1, I find that the Java annotation magic libraries tend to create more > > > problems than they solve. Specifically, they make debugging more > > > difficult and introduce performance problems like JCLOUDS-358. Further > > > these dialects make code hard to approach for casual developers. > > > > Still not in favor of magic, but Google recently released AutoValue, a > > less invasive annotation approach to value types, including getters: > > > > https://github.com/google/auto > > http://goo.gl/Ter394 > > > > Auto has some issues but holds promise; we should keep an eye on it. > > > > -- > > Andrew Gaul > > http://gaul.org/ > > >
