[
https://issues.apache.org/jira/browse/TINKERPOP-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187949#comment-17187949
]
Stephen Mallette commented on TINKERPOP-2411:
---------------------------------------------
Interesting analysis - thank you. I was thinking about some module
restructuring for 3.5.0 when we could take a breaking change like this .so
perhaps this one could be added to the list for that release.
> Move GremlinDslProcessor to its own artifact
> --------------------------------------------
>
> Key: TINKERPOP-2411
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2411
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.4.8
> Reporter: Olivier Michallat
> Priority: Minor
>
> Currently {{GremlinDslProcessor}} is located directly in the {{gremlin-core}}
> artifact. This has a few downsides:
> * it pulls a runtime dependency to JavaPoet
> * annotation processing is always on. The compiler will have to scan the
> classpath to check if {{GremlinDsl}} is used anywhere. I believe this is an
> additional step that would not happen if no processor was present.
> It's a good practice to place annotation processors in their own artifact.
> Then users can opt in, in one of two ways:
> * place the JAR in their compile classpath, but not the runtime one (e.g.
> "provided" scope in Maven)
> * or use the special {{-processorpath}} of javac
> ({{<annotationProcessorPaths>}} in the Maven compiler plugin config).
> Either way this provides a cleaner separation, the dependencies that are
> specific to the processing / code generation part are not retained at runtime.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
