Tried that, sure. After experimenting with this a bit, I’d suggest that we actually wait. There are a few issues I ran into, that could just be me not being able to get it to work but still somewhat alarming:
1. Not sure how Lombok deals with AJC. In fact, I was never able to get it to work. 2. Lombok requires JDK 6. Wouldn’t go that route. 3. The annotations that do exist are effective, but they are too few. I would want better and more options for example, when generating ctors. Otherwise we’d likely end up with classes that are half this and half that. Which would just be confusing. 4. Configuration is not all self-contained. For instance, if I wanted to create a log annotation on a class, and wanted to call the field logger that would be a bit of a challenge…I sort of expected @ThisIsLogging(loggerName=”logger”) but that’s not happening yet. From: Scott Battaglia [mailto:[email protected]] Sent: Friday, July 18, 2014 7:08 PM To: [email protected] Subject: Re: [cas-dev] Making use of Project Lombok? Would it make sense to start it out on a self-contained module such as the management web application? On Tue, Jul 15, 2014 at 8:04 AM, Misagh Moayyed <[email protected] <mailto:[email protected]> > wrote: I have been reading a fair bit about people’s experience with Lombok, and generally it has been positive. The project on github is active, with a recent release almost about a week ago and there is good plugin support for IDEA, Eclipse and JRebel (which another super cool tool I highly recommend). If at any point we decided that Lombok is no longer an answer, there is the ability to “Delombok” the code and restore it back to what it was. There may be cases where a generated setter for instance may not be enough, and if the setter requires more elaborate coding, it can certainly manually be coded. Doesn’t have to go through Lombok obviously. Debugging may be tricky. I guess we need to experiment. At least in Eclipse, in the outline view you could set a breakpoint and the debugger would halt. I imagine the same thing is true with IDEA and Structure window. What I’d propose is that we initially start out with smaller modules, ones with a few classes to see how much it can reduce clutter. Once we are confident, we can turn Lombok into a convention and a checkstyle recommendation. From: Jérôme LELEU [mailto:[email protected] <mailto:[email protected]> ] Sent: Tuesday, July 15, 2014 1:59 AM To: [email protected] <mailto:[email protected]> Subject: Re: [cas-dev] Making use of Project Lombok? Hi, I tend to think that Lombok is a fairly stable project over time as I've heard about it for years now. I already had many debattes about Lombok with my colleagues. The idea to spare getters/setters is appealing, though we need to jump into "more magic". What happens if you debug a "Lomboked" class at runtime? What source code do you have? Are the line numbers relevant if the source has been transformed? Best regards, Jérôme LELEU Founder of CAS in the cloud: www.casinthecloud.com <http://www.casinthecloud.com> | Twitter: @leleuj Chairman of CAS: www.jasig.org/cas <http://www.jasig.org/cas> | Creator of pac4j: www.pac4j.org <http://www.pac4j.org> 2014-07-14 22:34 GMT+02:00 Marvin Addison <[email protected] <mailto:[email protected]> >: > How do we feel about taking advantage of Project Lombok? > > http://projectlombok.org/index.html Wow, that looks pretty amazing. Thanks for sharing. > Seems to help with a ton of boilerplate code (setter/getter/equals, etc). > It > would be a pretty sizeable task to convert all but I think in the long > run, > it will help make things simpler to understand and code. I like the idea, but agree that it would be a fairly large change. I would be interested to know more about the history of lombok and what projects are using it. A technology like this has a lot of promise, but it's a substantial investment since it goes to the root of everything. We would need some assurance it's a stable project with a sound future. M -- You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] <mailto:[email protected]> as: [email protected] <mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
