[FR] Zero dependencies like Hickory

[agentgt]

I was kind of hoping this library might be a drop in replacement for the beloved Hickory and it is indeed very similar but it appears downstream APT now need the gems api jar.

Sadly that was my favorite part of Hickory: it generated all the code and does not actually require anything hickory aka prism in the downstream annotation processor.

Yes there is always Maven shade but that has its own can of worms.

I realize the convenience of having the Gem interface but perhaps tools-gem can just generate a that interface (in the downstream APT project) along with the gems. This should be fairly simple of just changing the package name to the project wanting the gem generation.

[filiphr]

I understand your point @agentgt. Even we are shading this gem dependency in MapStruct.

I do not remember why we went with having an explicit dependency. Do you remember @sjaakd?

In any case, I think that what @agentgt is proposing with generating the interface in the downstream APT project is a better alternative. What do you think @sjaakd?

---

@agentgt since you have tried this already. How do you feel about the fact that we are returning a GemValue instead of the actual object?

[agentgt]

@filiphr Sorry for the late reply.

@agentgt since you have tried this already. How do you feel about the fact that we are returning a GemValue instead of the actual object?

I'll have to relook again but I think what I thought was useful is because of the generated builder one could combine package annotations and then override them with class annotations which is a typical use case (let me know if that needs more explanation). I guess that is sort of independent of GemValue though.

On the other hand hickory is so damn simple. I even like how it returns null and the only change I would probably make to hickory is have it generate some configurable @Nullable annotation (of the consumers choosing).

[sjaakd]

I do not remember why we went with having an explicit dependency. Do you remember @sjaakd?

No.. I can't. But perhaps I'm failing to see the issue. The only dependencies are api's.. Right? Not altogether different from MapStruct itself. We don't pull in the processor. So: what happens if we do not shade in MapStruct.. (I'm pretty sure I'm missing the point here, but please enlighten me 😄 )

On the other hand hickory is so damn simple. I even like how it returns null and the only change I would probably make to hickory is have it generate some configurable @Nullable annotation (of the consumers choosing).

If I remember correctly: we inherit properties in MapStruct. So @Mapping could override @Mapper. We wanted to make a distinction between the case were you explicitly define a default (e.g. in @Mapping ) overriding a non default in @Mapper. Thus I guess we made those cases explicit in the Gem interface (default overridden, default because not set). But.. its a long time ago...

[agentgt]

No.. I can't. But perhaps I'm failing to see the issue. The only dependencies are api's.. Right? Not altogether different from MapStruct itself

Well in this particularly use case I was trying to use gem-tools in a separate library. I can see it being fine in the context of MapStruct since you guys own the lib.

My particularly issue with it was having to Maven Shade and then dealing with module-info.java and various other issues.

I suppose I could just make my own fork of Hickory similar to what you guys did.

BTW I'm a big fan of MapStruct.

Cheers.

[sjaakd]

Well in this particularly use case I was trying to use gem-tools in a separate library. I can see it being fine in the context of MapStruct since you guys own the lib.

Well, if there's something we can do here. The intention was to make Gem a replacement for hickory. Also for others to use.. I'll have a chat with @filiphr

[gunnarmorling]

FWIW, I'm +1 on generating 100% self-contained code with Hickory, it shouldn't impose any additional runtime dependencies to annotation processors which use it.