cbalci commented on code in PR #10490:
URL: https://github.com/apache/pinot/pull/10490#discussion_r1151223365
##########
pinot-connectors/pinot-spark-2-connector/pom.xml:
##########
@@ -119,6 +120,47 @@
<build>
<plugins>
<!-- scala build -->
+ <plugin>
+ <groupId>org.xolstice.maven.plugins</groupId>
+ <artifactId>protobuf-maven-plugin</artifactId>
+ <version>0.6.1</version>
+ <configuration>
+
<protocArtifact>com.google.protobuf:protoc:3.19.2:exe:${os.detected.classifier}</protocArtifact>
+ <pluginId>grpc-java</pluginId>
+
<pluginArtifact>io.grpc:protoc-gen-grpc-java:1.44.1:exe:${os.detected.classifier}</pluginArtifact>
+ </configuration>
+ <executions>
+ <execution>
+ <goals>
+ <goal>compile</goal>
+ <goal>compile-custom</goal>
+ </goals>
+ </execution>
+ </executions>
+ </plugin>
+ <plugin>
+ <artifactId>maven-shade-plugin</artifactId>
Review Comment:
OK, after some testing, I think the best approach is to shade at the final
(concrete) package level for two reasons:
- Even if we shade at the common package level and add dependency with
`<classifier>shaded</classifier>`, `mvn` will try to bring unshaded versions of
those libraries. We need to exclude them specifically.
- Shading at the 'common' package level creates an unnecessary encapsulation
at the internal boundary between two Pinot packages
I moved the protoc call to the common package and shading logic to concrete
packages. Let me know what you think
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@pinot.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@pinot.apache.org
For additional commands, e-mail: commits-h...@pinot.apache.org
