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

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

                Author: ASF GitHub Bot
            Created on: 31/Dec/20 12:44
            Start Date: 31/Dec/20 12:44
    Worklog Time Spent: 10m 
      Work Description: sonam-vend edited a comment on pull request #12938:
URL: https://github.com/apache/beam/pull/12938#issuecomment-752949784


   > I didn't have time to go through all of this today. To be honest, I don't 
think there's any way we can merge a single PR changing the entire project at 
once. I recommend splitting this PR into separate PRs, one for each module, so 
that it's easier to review and merge safely.
   > 
   > A couple general comments:
   > 
   > * If a dependency is defined in 
[project.ext.library](https://github.com/apache/beam/blob/7eacb40ee9591b8133b6017eb72b37702a2b9417/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy#L460),
 always use that value instead of hard-coding it. For example, use 
`library.java.google_oauth_client` instead of 
`"com.google.oauth-client:google-oauth-client:1.31.0"`.
   > * This is purely cosmetic, but try to keep the dependency lists 
alphabetized. It makes them much easier to read.
   
   @ibzib , I consider it is quite large and critical change to be merged all 
at once. Responding to your suggestion of splitting this PR into multiple 
separate PR, I am thinking to split this PR into 8 sub PRs as:
   
   1. Module A | beam/example/java
   2. Module B | beam/model
   3. Module C | beam/runners/core-construction-java, runners/core-java, 
runners/direct-java, runners/extensions-java
   4. Module D | runners/flink, 
runners/google-cloud-dataflow-java,runners/google-cloud-dataflow-java, 
runners/java-fn-execution, runners/java-job-service,  runners/jet
   5. Module E | runners/local-java, runners/portability, runners/samza, 
runners/spark, runners/twister2
   6. Module F | sdks/java/bom, sdks/java/build-tools, sdks/java/container, 
sdks/java/core
   7. Module G | sdks/java/expansion-service, sdks/java/extensions, 
sdks/java/fn-execution, sdks/java/harness
   8. Module H | sdks/java/io, sdks/java/javadoc, sdks/java/maven-archetypes, 
sdks/java/testing
   
   See if this proposal looks good to you, or else I welcome your other 
suggestions.
   
   
[BEAM-10961.xlsx](https://github.com/apache/beam/files/5757268/BEAM-10961.xlsx)
   
   cc @shehzaadn-vd


----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
[email protected]


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

    Worklog Id:     (was: 529790)
    Time Spent: 30h 20m  (was: 30h 10m)

> Enable strict dependency analysis on all Java modules 
> ------------------------------------------------------
>
>                 Key: BEAM-10961
>                 URL: https://issues.apache.org/jira/browse/BEAM-10961
>             Project: Beam
>          Issue Type: Improvement
>          Components: java-fn-execution
>            Reporter: Shehzaad Nakhoda
>            Assignee: Shehzaad Nakhoda
>            Priority: P2
>          Time Spent: 30h 20m
>  Remaining Estimate: 0h
>
> This is an IWYU analysis. If the module is using its transitive deps without 
> depending on them, or if it has direct dependencies it doesn't use, the build 
> fails. The work involves adding dependencies or adding exclusion rules 
> (example: 
> https://github.com/wfhartford/gradle-dependency-analyze#configurations). Even 
> if they just add exclusions across the board, it will be a big win because it 
> will prevent new violations.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to