You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "Olivier Michallat (Jira)" <ji...@apache.org> on 2020/08/31 18:34:00 UTC

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

Olivier Michallat created TINKERPOP-2411:
--------------------------------------------

             Summary: 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


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)