[ https://issues.apache.org/jira/browse/RATIS-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566967#comment-16566967 ]
Josh Elser commented on RATIS-288: ---------------------------------- This broke because of the (IMO) weird workflow that Yetus does. maven-shade-plugin is bound to package, but because Yetus is only issuing a test-compile, we don't get the sources. Seems like this was a reason for the runaround on unpacking sources in the first place. Let me see if I can also muddle with Yetus to make it happier. We don't need to have this complicated of a build. > 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)