[
https://issues.apache.org/jira/browse/RATIS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615432#comment-16615432
]
Tsz Wo Nicholas Sze commented on RATIS-316:
-------------------------------------------
Thanks, [~elserj]. The idea is great.
- The following files should be renamed to org.apache.ratis.thirdparty.*.
{code}
renamed:
ratis-proto-shaded/src/main/resources/META-INF/services/org.apache.ratis.shaded.io.grpc.ManagedChannelProvider
->
ratis-thirdparty/src/main/resources/META-INF/services/org.apache.ratis.shaded.io.grpc.ManagedChannelProvider
renamed:
ratis-proto-shaded/src/main/resources/META-INF/services/org.apache.ratis.shaded.io.grpc.NameResolverProvider
->
ratis-thirdparty/src/main/resources/META-INF/services/org.apache.ratis.shaded.io.grpc.NameResolverProvider
renamed:
ratis-proto-shaded/src/main/resources/META-INF/services/org.apache.ratis.shaded.io.grpc.ServerProvider
->
ratis-thirdparty/src/main/resources/META-INF/services/org.apache.ratis.shaded.io.grpc.ServerProvider
{code}
- How to make Jenkens work?
> ... we also can make the decision whether we keep this as sub-directory in
> ratis.git ...
If a future patch changes some dependencies, it probably needs to update the
code at the same time. So it seems good to keep it as a subdirectory.
> Centralize shaded thirdparty dependencies in a single artifact
> --------------------------------------------------------------
>
> Key: RATIS-316
> URL: https://issues.apache.org/jira/browse/RATIS-316
> Project: Ratis
> Issue Type: Improvement
> Components: build
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Major
> Attachments: RATIS-316.001.patch
>
>
> After the changes in RATIS-288, developers may find that their IDEs are
> complaining about dependencies that we bundle in ratis-proto-shaded as not
> being "found".
> This is understandable because IDEs typically aren't smart enough to follow
> the maven-shade-plugin and unravel the relocation that's happening.
> The easiest solution for this is to make an artifact for our "thirdparty"
> dependencies that has its own release schedule. The "core" of Ratis can then
> depend on this artifact and the relocated dependencies in the well-known
> location (fix the IDE errors). Additionally, this will give us a bit more
> flexibility in upgrading to newer versions of these dependencies without
> having to re-release Ratis (e.g. if there is a CVE on Netty, we can make a
> new release of ratis-thirdparty without re-releasing Ratis just for that
> change).
> We could move this to a separate git repo, but it's easy enough to just leave
> this is a sub-directory of ratis.git. I don't have strong feelings either way.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
