[sakai2-tcc] Discuss: should we be using lombok in Sakai?

Tue Aug 13 13:10:40 PDT 2013

If someone can coach me on how to set up whatever tools the cool kids are using, I would be glad to update a couple of pages in Confluence and announce.

This amounts to testing/updating section 16, right?

https://confluence.sakaiproject.org/display/BOOT/Development+Environment+Setup+Walkthrough

Agreed on kernel. Indifferent elsewhere.

Thanks,
-Noah

On Aug 13, 2013, at 3:23 PM, Aaron Zeckoski wrote:

> None of the frontend frameworks cause the IDE to report that code is broken.
> 
> That said, I take it Matt or Noah are volunteering to update the docs
> to document the "easiest" process then which I think is excellent.
> Please do also send out a note to the dev list with the updated docs
> so that at least current dev list people are aware of this. Imagine
> yourself as a new dev who does not even know what lombok is and all
> they see is code which does not compile. Document from that approach
> and I think things will be fine.
> 
> We should not use this in kernel until it hits at least a 1.0 release
> though. I am happy to spend the time generating the getters and
> setters for anyone who cannot be bothered to do it. Please just let me
> know when there is a case in kernel where generating a getter or
> setter is too much effort and I will jump in and take care of it.
> 
> -AZ
> 
> 
> On Tue, Aug 13, 2013 at 3:11 PM, Matthew Jones <matthew at longsight.com> wrote:
>> I would agree with Noah, the variety of frameworks used in Sakai all require
>> special eclipse configuration. Velocity, JSF, Wicket, RSF don't work out of
>> the box and we don't have great documentation on how to develop with them
>> for Sakai. Getting Lombok integrated into eclipse (on Ubuntu) only takes
>> running "sudo java -jar lombok.jar", easiest I've ever seen.
>> 
>> I understand what's happening and happier setting less code. I don't think
>> we should go adding it in a bunch of places or taking it out either, but I
>> think it will cause a lot less confusion than ClassCastExceptions with
>> duplicate jars (which I've seen way to many of already today).
>> 
>> I also agree with Noah that I *usually* use vim over an IDE anyway for quick
>> fixes, so anything that requires less code is for sure easier to deal with
>> even if it is a right click in the IDE to add a bunch of junk.
>> 
>> 
>> On Tue, Aug 13, 2013 at 3:00 PM, Noah Botimer <botimer at umich.edu> wrote:
>>> 
>>> I personally don't think we should outlaw it any more than we should
>>> outlaw JSF, for example.
>>> 
>>> There is a case to be made for consistency, but there is also a case for
>>> free agency.
>>> 
>>> I have not taken to Lombok for my own code [1], and we should not add it
>>> to a bunch of existing areas for the sake of adding it [2], but I find it
>>> totally acceptable that new areas try it out so we can compare and decide
>>> within the community what our taste for it is.
>>> 
>>> Lombok may cause some confusion, but as exhibit A of somewhat confusing
>>> stuff you get over quickly, I offer our "components" and cross-app Spring
>>> context and dependency injection. I just don't think it's a big deal either
>>> way.
>>> 
>>> I will not argue strenuously in any direction except against a new,
>>> required practice.
>>> 
>>> Thanks,
>>> -Noah
>>> 
>>> 
>>> [1] I primarily use Vim over perpetually wrangling IDE project files, so
>>> magical annotations don't usually help or hurt me much. It's just that the
>>> base use case of avoiding getters and setters comprises approximately 0% of
>>> my life, so it hasn't been something I have prioritized.
>>> 
>>> [2] Respect the house of those who came before; refactor, but focus on
>>> quality and simplicity over brevity and preference.
>>> 
>>> On Aug 13, 2013, at 9:09 AM, Aaron Zeckoski wrote:
>>> 
>>>> lombok was released in 2009 and is not even at a 0.2 yet. Also, there
>>>> is clearly debate about it in the java community:
>>>> 
>>>> http://stackoverflow.com/questions/3852091/is-it-safe-to-use-project-lombok
>>>> 
>>>> http://stackoverflow.com/questions/2866084/is-project-lombok-suitable-for-large-java-projects
>>>> 
>>>> Should we be using this in Sakai?
>>>> I have seen multiple new developers to Sakai confused by it. I
>>>> understand using eclipse to generated getters takes a few clicks and
>>>> makes the code a little longer but I don't think that is all that
>>>> hard.
>>>> Lombok saves a few lines of code but at the expense of requiring
>>>> special eclipse (or other IDE) configuration, extra maven build, and
>>>> special developer knowledge of what is happening (so they know why
>>>> they don't see any get and set methods like... 99% of java projects.
>>>> It also completely breaks compile time code scanning (around anything
>>>> it affects anyway) but
>>>> that is a lesser concern.
>>>> If we decide to use it broadly as a community, I think it needs to be
>>>> clearly documented and indicated as a requirement. If not, I think we
>>>> should delombok the current handful of places it is used.
>>>> 
>>>> I added this to the CLE team call as a discussion point for this week:
>>>> http://etherpad.ctools.org/rmmt-2013-08-15
>>>> 
>>>> -AZ
>>>> 
>>>> 
>>>> --
>>>> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>>> _______________________________________________
>>>> sakai2-tcc mailing list
>>>> sakai2-tcc at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>>> 
>>> _______________________________________________
>>> sakai2-tcc mailing list
>>> sakai2-tcc at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
>> 
>> 
> 
> 
> 
> -- 
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130813/6de2cdc0/attachment.html 