[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)