Lombok dependency should not be transitive

[reckart]

Issue Description

According to projectlombok/lombok#1629 (comment) the lombok dependency should not be leaked out as a transitive dependency to code which makes use of DL4J.

The presence of lombok as a regular dependency exposes the lombok annotation processor to downstream builds which currently causes problems with Java 10. However, as stated in the comment linked above, the problem is more likely a misconfigured lombok dependency in DL4J than an true Java 10 problem.

Version Information

Please indicate relevant versions, including, if relevant:

• Deeplearning4j version: 0.9.1

[agibsonccc]

We can fix this with the release this week. @saudet thoughts here?

[AlexDBlack]

Yeah, that seems reasonable to me. There's an apparent fix at the link @reckart provided, so hopefully this should be pretty quick to implement.

[saudet]

@reckart We just need to specify <optional>true</optional> on the dependency, right? If that's the only thing, that sounds good to me.

[reckart]

@saudet according to @victorwss yes

I guess it should do the trick, although https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html says that optional is not the best solution. The "provided" scope could be an alternative.

My understanding is that the lombok JAR provides some annotations that you need during the build process but not afterwards. It also includes the annotation processor. This annotation processor is causing problems for downstream code which inherits it as a transitive dependency via DL4J.

I assume the annotations probably are not retained at runtime? And the annotation processor should also not be needed at runtime, So if this is the case, then the dependency should not be transitive. "optional" and "provided" should both be means of achieving this.

[victorwss]

@reckart Lombok removes its annotations at the compile time. The produced JAR/WAR/EAR/whatever should not leave any trace that it used lombok as part of its compilation. Lombok's idea is to just generate boilerplate code that is too boring and error-prone to be manually written down by the user. So, lombok should not pollute the runtime classpath with any unwanted dependency, including itself. The resulting JAR/WAR/EAR/whatever should be the same as if you wrote down all the boilerplate code manually yourself.

About provided vs optional, I'm not a maven specialist. So, it is possible that provided works better.

Note that I'm not a lombok developer. I'm just a lombok user that happened to be lurking into the issues' list.

[saudet]

Looks like the authors are recommending to use "provided" so I've changed it that way:
https://projectlombok.org/mavenrepo/index.html
Thanks for the tip guys! Hopefully, we'll be able to support Java 10 :)

[reckart]

You're welcome! Thanks for the fix!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.