[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
({{}} 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)
[jira] [Created] (TINKERPOP-2347) Remove invalid service descriptors from gremlin-shaded
Olivier Michallat created TINKERPOP-2347:
Summary: Remove invalid service descriptors from gremlin-shaded
Key: TINKERPOP-2347
URL: https://issues.apache.org/jira/browse/TINKERPOP-2347
Project: TinkerPop
Issue Type: Bug
Components: build-release
Affects Versions: 3.4.5
Reporter: Olivier Michallat
{{gremlin-shaded.jar}} contains a couple of service descriptors inherited from
Jackson:
{code}
META-INF/services/com.fasterxml.jackson.core.JsonFactory
META-INF/services/com.fasterxml.jackson.core.ObjectCodec
{code}
They still reference unshaded classes, for example in the first one:
{code}
com.fasterxml.jackson.core.JsonFactory
{code}
This creates a problem if the JAR is used as an automatic module in a JPMS
application. The module system tries to convert the files into {{provides}}
directives in the dynamically generated module descriptor, but it checks for
the existence of the types in the process:
{code}
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for
/path/to/gremlin-shaded-3.4.5.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class
com.fasterxml.jackson.core.JsonFactory not in module
{code}
I didn't find a way to work around this error without modifying the JAR.
I think the best approach would be to filter out those files during the shading
process. They were wrong anyway, so it's unlikely that anyone will miss them.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
