[
https://issues.apache.org/jira/browse/HADOOP-18487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759245#comment-17759245
]
ASF GitHub Bot commented on HADOOP-18487:
-----------------------------------------
steveloughran commented on PR #4996:
URL: https://github.com/apache/hadoop/pull/4996#issuecomment-1694332645
> Do you want to keep providing scope optional or should we wrap this up
under a profile?
1. the scope in this PR doesn't actually change protobuf 2.5 being exported
2. i had a goal of a followup pr which did that, something isolated so easy
to revert
3. but yes, a protobuf-2.5.scope variable would let people switch from
provided to compile on the command line.
now, if we make it a switch, should i do it in this pr or that followup I
was thinking about
> protobuf-2.5.0 dependencies => provided
> ---------------------------------------
>
> Key: HADOOP-18487
> URL: https://issues.apache.org/jira/browse/HADOOP-18487
> Project: Hadoop Common
> Issue Type: Improvement
> Components: build, ipc
> Affects Versions: 3.3.4
> Reporter: Steve Loughran
> Priority: Major
> Labels: pull-request-available
>
> uses of protobuf 2.5 and RpcEnginej have been deprecated since 3.3.0 in
> HADOOP-17046
> while still keeping those files around (for a long time...), how about we
> make the protobuf 2.5.0 export off hadoop common and hadoop-hdfs *provided*,
> rather than *compile*
> that way, if apps want it for their own apis, they have to explicitly ask for
> it, but at least our own scans don't break.
> i have no idea what will happen to the rest of the stack at this point, it
> will be "interesting" to see
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
