[
https://issues.apache.org/jira/browse/RATIS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16615343#comment-16615343
]
Josh Elser commented on RATIS-316:
----------------------------------
{quote}what is the new way to compile everything? {{mvn clean package
-DskipTests}} just fails.
{quote}
Do a {{pushd ratis-thirdparty && mvn install && popd}} first. Then you can
build normally.
> 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)
