1

I'm working on a Java app with several other developers. We use maven for package management and SVN for version control.

I've recently started using Lombok, being fedup with boilerplate in so many of my classes. However, Lombok must be installed in the Eclipse environment, so my question is, will all of my teammates have to install it for Lombok code to compile? If I commit my code to the repo, and they pull it, are they not going to be able to build the project? If so, are there any ways around this? Surely other teams are using this handy library.

Trying to understand this more before simply "trying it" and incurring their wrath.

Community
  • 1
  • 1
Adam Hughes
  • 14,601
  • 12
  • 83
  • 122

2 Answers2

2

You are misreading that second link you posted.

Yes, Lombok is primarily intended to be used within your IDE.

But of course, you do not need an IDE - you can use it with maven, sbt, gradle, too --- see their documentation.

And just for the record: any sane programming language tool requires some non-IDE version to make sense. You see - in the end, any real project should be build using a build system (to allow for automation, continuous delivery, deployment, you-name-it). In other words: a key property of a reasonable built is the ability to run it on some "non-developer" backend system. If you require some developer to do do something on his local workstation in order to get out your product, chances are, that you are doing something wrong.

Edit: keep in mind - Lombok works by annotations. That means that you change your Java source code when introducing Lombok. That of course means that any person (or build process for that matter) needs to be "Lombok enabled". Thus: you are about to add a major dependency to some external, 3rd party open source toolset to your source code. You should not only understand all technical consequences, but also the legal aspects. And of course, everybody in your team who has a say ... should give his approval. Because if you would not be Lombok-enabled, you can't build any more!

You should be really convinced that using Lombok is the right thing for your team before making this step. And given the (sorry) naivety of your question/comments, I am wondering if you are really at the point of making this decision.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • Thanks GhostCat, I will checkout the docs you linked. Our project does have a maven build, but if a developer went and opened the source code in their editor, the editor would start complaining, right? So maybe simply tell devs that if they don't have lombok, they can't really edit my source code in a few modules? Or am I still misunderstanding? – Adam Hughes Dec 07 '16 at 17:37
  • Thanks for clarifying. No worries, you're right, it's not a decision for me to make for the team. – Adam Hughes Dec 07 '16 at 18:30
  • One last question, sorry. Am I at least right in understanding that to use Lombok for the project, we'd have to include it as a dependecy for maven, AND have everyone on the team install the project into their IDE? – Adam Hughes Dec 07 '16 at 18:36
  • As said: any person or process that is currently compiling / building your source code will need to be enabled for Lombok. If they are not they will be broken sooner or later. – GhostCat Dec 07 '16 at 19:07
  • Yes, you are correct that you both have to include it in your pom AND have all developers install lombok into their IDE. – Roel Spilker Dec 09 '16 at 09:18
2

  1. "will all of my teammates have to install it for Lombok code to compile?" - yes they will likely need lombok plugin installed in the ide and the dependency will have to be included in the pom as a dependency.

  2. "If I commit my code to the repo, and they pull it, are they not going to be able to build the project?" - if you update the pom, from the command line yes, from the ide it depends on how the ide is setup to work with the project.

  3. "If so, are there any ways around this?" - No, you should really bring up the idea of reducing boilerplate code with the team and come up with a shared strategy to combat. Popping a new technology on them is disruptive, non-professional and could damage your reputation. Try it locally, present it to the team showing the before and after, reviewing the pros and cons you ran into along the way along with the expected impacts.

Bob Lukens
  • 700
  • 6
  • 10