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

[Aaron Zeckoski]

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