expose annotation processor and remove hider enclosing class #973

Open
rmannibucau opened this Issue Nov 20, 2015 · 16 comments

Projects

None yet

10 participants

@rmannibucau

When mixing annotation processors it is super important to be able to control their execution order, today it is almost impossible to do it properly with lombok cause of the hider class.

Is it possible to try to make it more open?

Side note: here is one conflicting annotation processor for instance mapstruct/mapstruct#510

@rzwitserloot
Owner

It's not really hidden, it's just been renamed. You're looking for:

lombok.launch.AnnotationProcessorHider$AnnotationProcessor

If this is something more involved, then... we can't do much without more info on how @dave-lo fixed this issue. I don't even know what the issue is :/

parked for closing on January 1st 2016 without more feedback.

@rzwitserloot rzwitserloot added the parked label Nov 22, 2015
@rmannibucau

Well goal is to be able to order procs using -proc of javac. AnnotationProcessorHider doesnt allow it ATM AFAIK

@lsamayoa

I am hitting with this issue too. The problem for me is that a corporate parent pom has the compiler plugin configured with <proc>none</proc> and adding a compile goal to the generate-source phase with <proc>only</proc> has not been an option.

@rspilker
Collaborator
rspilker commented Dec 6, 2015

Can you tell us the platform you're using and the exact version of javac?

On linux you need to make sure the $ isn't interpreted. I could compile using

javac -processor 'lombok.launch.AnnotationProcessorHider$AnnotationProcessor' -cp lombok.jar Test.java
@rmannibucau

1.8u45 and u60

@rspilker
Collaborator
rspilker commented Dec 6, 2015

Windows, Linux, Mac. javac directly, Ant, Maven, Gradle?

Did you try my suggestion?

@rmannibucau

Linux or mac, mvn. Tried but never got a good ordering with other processors.

edit: mvn doesnt quote the processors names so can be the issue: https://issues.apache.org/jira/browse/MCOMPILER-256

@rspilker
Collaborator
rspilker commented Dec 8, 2015

Could it be that Maven interpret the $ sign as a property? Try using the following:

lombok.launch.AnnotationProcessorHider&#36;AnnotationProcessor
@gunnarmorling

Hi, as you know, I am working on MapStruct, an annotation processor for generating type-safe bean mappings. Users have been reporting issues when working with MapStruct and Lombok together in one project. These issues stem from the fact that MapStruct does not "see" the property accessors generated by Lombok, causing the MapStruct-generated mappers to be incomplete.

In general, MapStruct needs to be prepared for the fact that other processors may add property accessors by generating super-classes of the processed types (that's a pattern foreseen in the JSR 269 architecture). At the moment we don't support that yet, but we can do so by examining the super-type mirror(s) of processed types and if those have type kind ERROR, defer processing of the sub-types to a future round, by which the missing super-types will have been generated.

I hoped to do the same with Lombok-processed entities, but atm. I am lacking a way to decide whether a type has been fully amended or not (so MapStruct needs to defer its handling). So basically I am after something similar to checking the type kind of super-types as described above. I don't know how this could look like, but maybe you guys have any idea?

@rspilker
Collaborator

I have an idea on how to fix this in general.

  1. Instead of using the processor discovery mechanism, the users need to specify the lombok annotation processor explicitly
  2. The user can instruct the lombok processor to invoke other processors. These are normal annotation processors.
  3. Lombok will steal the round and keeps running until all work is done
  4. Lombok invokes the other processors with all files
  5. If a processor generates new files, Lombok processes them first. Goto 3.

Possibly we can omit step 1 and 2 by using reflection to read and modify javac's internal structure. That would be the best for all users, but the Lombok processor should probably be invoked first, unless we can some serious hacking at class loading time.

What do you think? Might/would this work?

@5im5im
5im5im commented Mar 13, 2016

Will there be a solution in the near future for this bug? Would be great if lombok would work with MapStruct out of the box. :-)

@wenerme
wenerme commented May 26, 2016 edited

Any progress here, lombok + mapstruct is a wonderful integration for Spring Boot.Like jhipster use mapstruct for dto, and spring boot suggest use lombok for entity and data model.Due to this issue, we can not use lombok + mapstruct, that'a awful.So, please.

@fitzyjoe

I've been working around this issue by making a separate module for my lombok classes and compiling that module first. This stinks. I wish lombok and mapstruct were compatible with each other. After so long with no resolution, my team is trying to decide whether to rip out lombok or mapstruct so that we can consolidate the code.

@alexpetroaica

Any updates on this? I really like both MapStruct and Lombok but will have to drop one of them as splitting the project into multiple modules is not an option...

@jchen9shc

I am running similar issue when using lombok and Selma, Selma can't see the getter/setter lombok generates using @Data. Don't like the idea splitting the project into separate modules to make this work. Querydsl and lombok have similar issue, the solution is to set processors including lombok and querydsl annotation processors. Similar solution should be possible for lombok and Selma. Here is the link for Querydsl and lombok issue: ewerk/gradle-plugins#59

@rzwitserloot
Owner

Most of the chat and implementation talk on this problem has been held on issue mapstruct/mapstruct#510. We've got a solution in place and will release it soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment