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

[Matthew Jones]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130813/f7b7cbf7/attachment-0001.html