[jira] [Work logged] (BEAM-13504) Remove provided/compileOnly deps not intended for external use

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/BEAM-13504?focusedWorklogId=708022&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-708022 ]

ASF GitHub Bot logged work on BEAM-13504:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 13/Jan/22 02:28
            Start Date: 13/Jan/22 02:28
    Worklog Time Spent: 10m 
      Work Description: aaltay commented on pull request #16399:
URL: https://github.com/apache/beam/pull/16399#issuecomment-1011693282


   Is this PR still needed based on the dev list discussion?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: github-unsubscribe@beam.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

            Worklog Id:     (was: 708022)
    Remaining Estimate: 0h
            Time Spent: 10m

> Remove provided/compileOnly deps not intended for external use
> --------------------------------------------------------------
>
>                 Key: BEAM-13504
>                 URL: https://issues.apache.org/jira/browse/BEAM-13504
>             Project: Beam
>          Issue Type: Sub-task
>          Components: build-system
>            Reporter: Daniel Collins
>            Priority: P1
>             Fix For: 2.36.0
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> There are a lot of compileOnly deps in place to make certain libraries lighter. In many cases, these don't actually reduce the size of the resulting binary, and are a result of an overriding strategy where the types of the implementation are needed in the loading library.
> In the short term, these can all be replaced by `implementation`, with the downside that jars will have extra explicit dependencies, and the upside that users will not experience runtime errors due to missing dependencies. In the longer term, we should restructure these libraries (sql being the worst offender) to use serviceLoaders or other strategies that do not require naming the types of the overriders within the same package that the interface is declared.
> The one exception to this is libraries that we intend to use whatever version the user puts on the classpath at runtime without expressing a version preference, such as hadoop or kafka. We should still consider if this has value though, as users are still free to explicitly override the dependency version we choose, even if we declare an `implementation` dependency on it.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)