[
https://issues.apache.org/jira/browse/RATIS-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16567032#comment-16567032
]
Josh Elser commented on RATIS-288:
----------------------------------
Thanks, [~elek]! That's what I'm playing around with locally – I think I can
just tweak how Yetus runs compilation to work around this.
I think the long-term solution would be to move the shaded thirdparty
dependencies out to its own build:
# They don't change often and we don't need to spend time rebuilding them often
# Works around this exact issue in Maven/Yetus
I don't think I want to take that up now, so maybe something for the future.
> Pom cleanup/simplification
> --------------------------
>
> Key: RATIS-288
> URL: https://issues.apache.org/jira/browse/RATIS-288
> Project: Ratis
> Issue Type: Improvement
> Components: build
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Minor
> Attachments: RATIS-288.001.patch, RATIS-288.002.patch
>
>
> I'm noticing quite a bit of over-complication in the build, mostly around
> ratis-proto-shaded. From what I can tell in the git history, this is holdover
> from quite some time ago (when the module itself was introduced).
> Some weird things I see:
> * Everything being marked as optional
> * Explicit scope=compile being listed (this is the default)
> * Inheriting all configuration from the netty-all pom (not sure why we'd
> want this)
> * Recompilation of source files included in ratis-proto-shaded (shade-plugin
> can do this already)
> My only guess is that some of this was to support the {{skipShade}} option. I
> think I can halve the amount of time for the ratis-proto-shaded model, and
> still support a workflow that will let folks skip re-compilation if they
> haven't changed the protobufs
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
