[jira] [Closed] (TINKERPOP-2411) Move GremlinDslProcessor to its own artifact

["Stephen Mallette (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TINKERPOP-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stephen Mallette closed TINKERPOP-2411.
---------------------------------------
    Fix Version/s: 3.6.0
       Resolution: Done

> 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
>            Assignee: Stephen Mallette
>            Priority: Minor
>              Labels: breaking
>             Fix For: 3.6.0
>
>
> 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)