We now present the results of our in-depth analysis of bloated dependencies in the Maven ecosystem.
RQ1: How Frequently do Bloated Dependencies Occur?
In this first research question, we investigate the status of all the dependency relationships of the 9,639 Maven artifacts under study.
Figure 10 shows the overall status of the 723,444 dependency relationships in our dataset. The x-axis represents the percentages, per usage type, of all the dependencies considered in the studied artifacts. The first observation is that the bloat phenomenon is massive: 543,610 (75.1%) of all dependencies are bloated, they are not needed to compile and run the code. This bloat is divided into three separate categories: 19,673 (2.7%) are bloated-direct dependency relationships (explicitly declared in the POMs); 111,649 (15.4%) are bloated-inherited dependency relationships from parent module(s); and 412,288 (57%) are bloated-transitive dependencies. Figure 10 shows that 75.1% of the relationships (edges in the dependency usage tree) are bloated dependencies. Note that this observation does not mean that 543,610 artifacts are unnecessary and can be removed from Maven Central. The same artifact can be present in several DUTs, i.e., reused by different artifacts, but be part of a bloated dependency relationship only in some of these DUTs, and part of a used relationship in the other DUTs.
Figure 11 shows the overall status of the dependencies with respect to the type of the dependency relationship (direct, inherited, and transitive). We observe that approximately 1/3 of direct dependencies are bloated (34.23%), whereas inherited and transitive dependencies have a higher percentage of bloat (61.79% and 82.5% of bloat, respectively). These results indicate that artifacts with inherited and transitive dependencies are more likely to have more bloated dependencies. They also confirm that transitive dependencies are the most susceptible to bloat.
In the following, we illustrate the three types of bloated dependency relationships with concrete examples.
We found that 2.7% of the dependencies declared in the POM file of the studied artifacts are not used at all via bytecode calls. Recall that detecting this type of bloated dependencies is good, because they are easy to remove by developers with a single change in the POM file of the project under consideration. As an example, the Apache IgniteFootnote 7 project has deployed an artifact: org.apache.ignite:ignite-zookeeper:2.4.0, which contains only one class in its bytecode: TcpDiscoveryZookeeperIpFinder, and it declares a direct dependency in the POM towards slf4j, a widely used Java logging library. However, if we analyze the bytecode of ignite-zookeeper, no call to any API member of sl4j exists, and therefore, it is a bloated-direct dependency. After a manual inspection of the commit history of the POM, we found that sl4j was extensively used across all the modules of Apache Ignite at the early stages of the project, but it was later replaced by a dedicated logger, and its declaration remained intact in the POM.
In our dataset, a total of 4,963 artifacts are part of multi-module Maven projects. Each of these artifacts declares a set of dependencies in its POM file, and also inherits a set of dependencies from a parent POM. DepClean marks those inherited dependencies are either bloated-inherited or used-inherited. Our dataset includes a total of 111,649 dependency relationships labeled as bloated-inherited, which represents 15.4% of all dependencies under study and 61.8% of the total of inherited dependencies. For example, the artifact org.apache.drill:drill-protocol:1.14.0 inherits dependencies commons-codec and commons-io from its parent POM org.apache.drill:drill-root:1.14.0, however, those dependencies are not used in this module, and therefore they are bloated-inherited dependencies.
In our dataset, bloated-transitive dependencies represent the majority of the bloated dependency relationships: 412,288 (57%). This type of bloat is a natural consequence of the Maven dependency resolution mechanism, which automatically resolves all the dependencies whether they are explicitly declared in the POM file of the project or not. Transitive dependencies are the most common type of dependency relationships, having a direct impact on the growth of the dependency trees. This type of bloat is the most common in the Maven ecosystem. For example, the artifact org.eclipse.milo:sdk-client:0.2.1 ships the transitive dependency gson in its MDT, induced from its direct dependency towards bsd-parser-core. However, the part of bsd-parser-core used by sdk-client does not call any API member of gson, and therefore it is a bloated-transitive dependency.
In the following, we discuss the dependencies that are actually used. We observe that direct dependencies represent only 3.4% of the total of dependencies in our dataset. This means that the majority of the dependencies that are necessary to build Maven artifacts are not declared explicitly in the POM files of these artifacts.
It is interesting to note that 85,975 of the dependencies used by the artifacts under study are transitive dependencies. This kind of dependency usage occurs in two different scenarios: (1) the artifact uses API members of some transitive dependencies, without declaring them in its own POM file; or (2) the transitive dependency is necessary to provide a functionality to another, actually used dependency, in the dependency tree of the artifact.
We now discuss an example of the first scenario based on the org.apache.streams:streams-filters:0.6.0 artifact from the Apache StreamsFootnote 8 project. It contains two classes: VerbDefinitionDropFilter and VerbDefinitionKeepFilter. Listing 2 shows part of the source code of the class VerbDefinitionDropFilter, which imports the class PreCondition from library guava (line 2) and uses its static method checkArgument in line 8 of method process. However, if we inspect the POM of streams-filters, we notice that there is no dependency declaration towards guava. It declares a dependency towards streams-core, which in turn depends on the streams-utils artifact that has a direct dependency towards guava. Hence, guava is a used-transitive dependency of streams-filters, called from its source code.
Let us now present an example of the second scenario. Listing 3 shows an excerpt of the class AuditTask included in the artifact org.duracloud:auditor:4.4.3, from the project DuraCloud.Footnote 9 In line 6, the method getPropsSerializer instantiates the JaxbJsonSerializer object that belongs to the direct dependency org.duracloud:common-json:4.4.3. This object, in turn, creates an ObjectMapper from the transitive dependency jackson-mapper-asl. Hence, jackson-mapper-asl is a necessary, transitive provider for org.duracloud:auditor:4.4.3.
Figure 12 shows the distributions of dependency usage types per artifact. The figure presents superimposed log-scaled box-plots and violin-plots of the number of dependency relationships corresponding to the six usage types studied. Box-plots indicate the standard statistics of the distribution (i.e., lower/upper inter-quartile range, max/min values, and outliers), while violin plots indicate the entire distribution of the data.
We observe that the distributions of the bloated-direct (bd) and bloated-transitive (bt) dependencies vary greatly. Bloated-direct dependencies are distributed between 0 and 1 (1st-Q and 3rd-Q), with a median of 0; whereas the second ranges between 2 and 41 (1st-Q and 3rd-Q), with a median of 11. These values are in line with the statistics presented in Table 2, since the number of direct and transitive dependencies in general differ approximately by one order of magnitude. Overall, from the 9,639 Maven artifacts studied, 3,472 (36%) have at least one bloated-direct dependency, while 8,305 (86.2%) have at least one bloated-transitive.
On the other hand, the inter-quartile range of bloated-direct (bd) dependencies is more compact than the used-direct (ud). In other words, the dependencies declared in the POM are mostly used. This result is expected, since developers have more control over the edition (adding/removing dependencies) of the POM file of their artifact.
The median number of used-transitive (ut) dependencies is significantly lower than the median number of bloated-transitive (bt) dependencies (2, vs. 11). This suggests that the default dependency resolution mechanism of Maven is suboptimal with respect to ensuring minimal dependency inclusion.
The number of outliers in the box-plots differs for each usage type. Notably, the bloated-direct dependencies have more outliers (in total, 25 artifacts have more than 100 bloated-direct dependencies). In particular, the artifact com.bbossgroups.pdp:pdp-system:22.214.171.124 has the maximum number of bloated-direct dependencies: 133, out of the 147 declared in its POM. The total number of artifacts with at least one bloated-direct dependency in our dataset is 2,298, which represents 23.8% of the 9,639 studied artifacts.
RQ2: How do the Reuse Practices Affect Bloated Dependencies?
In this research question, we investigate how the reuse practices that lead to these distinct types of dependency relationships are related to the bloated dependencies that emerge in Maven artifacts.
Figure 13 shows the distributions, in percentages, of the direct, inherited, and transitive dependencies for the 9,639 studied artifacts. The artifacts are sorted, from left to right, in increasing order according to their ratio of direct dependencies. The y-axis indicates the ratio of each type of dependency for a given artifact. First, we observe that 4,967 artifacts belong to multi-module projects. Among these artifacts, the extreme case (far left of the plot) is org.janusgraph:janusgraph-berkeleyje:0.4.0, which declares only 1.4% of its dependencies in its POM, while the 48.6% of its dependencies are inherited from parent POM files, and 50% are transitive. Second, we observe that the ratio of transitive dependencies is not equally distributed. On the right side of the plot, 879 (9.1%) artifacts have no transitive dependency (they have 100% direct dependencies). Meanwhile, 5,561 (57.7%) artifacts have more than 50% transitive dependencies. The extreme case is org.apereo.cas:cas-server-core-api-validation:6.1.0, with 77.6% transitive dependencies.
In summary, the plot in Fig. 13 offers a big picture of the distribution of the three types of dependency usage in our dataset. The inherited and transitive dependencies are a significant phenomenon in Maven: 8,742 (90.7%) artifacts in our dataset have transitive dependencies, and 51.5% of artifacts belong to multi-module projects. This observation confirms the results of the previous section, most of the bloated dependencies in our dataset are either transitive (57%) or inherited (15.4%).
Figure 14 plots the relation between the ratio of transitive dependencies and the ratio of bloated dependencies. Each dot represents an artifact. Dots have a higher opacity in the presence of overlaps.
The key insight in Fig. 14 is that the larger concentration of artifacts is skewed to the top right corner, indicating that artifacts with a high percentage of transitive dependencies also tend to exhibit higher percentages of bloated dependencies. Indeed, both variables are positively correlated, according to the Spearman’s rank correlation test (ρ = 0.65, p-value < 0.01).
Figure 15 shows the distribution of the ratio of transitive bloated dependencies according to the height of the dependency tree. The artifact in our dataset with the largest height is top.wboost:common-base-spring-boot-starter:3.0.RELEASE, with a height of 14. The bar plot on top of Fig. 15 indicates the number of artifacts that have the same height. We observe that most of the artifacts have a height of 4: 2,226 artifacts in total. Considering the number of dependencies, this suggests that the dependency trees tend to be wider than deep. This is direct consequence of the automatic dependency management by Maven: any dependency that already appears at a level closer to the root will be omitted by Maven if it is referred to at a deeper level.
Looking at the 58 artifacts with height ≥ 9, we notice that most of them belong to multi-module projects, and declare other modules in the same project as their direct dependencies. This is a regular practice of multi-module projects, which allows to release each module as an independent artifact. Meanwhile, this increases the complexity of dependency trees. For example, artifact org.wso2.carbon.devicemgt:org.wso2.carbon.apimgt.handlers:3.0.192 is the extreme case of this practice in our dataset, with two direct dependencies towards other modules of the same project that in turn depend on other modules of this project. As a result, this artifact has 342 bloated-transitive and 87 bloated-inherited dependencies, a dependency tree of height 11, and is part of a multi-module project with a total of 79 modules released in Maven Central.
The plot in Fig. 15 shows a clear increasing trend of bloated-transitive dependencies as the height of the dependency tree increases. Indeed, both variables are positively correlated, according to the Spearman’s rank correlation test (ρ = 0.54, p-value < 0.01). For artifacts with a dependency tree of height greater than 9, at least 28% of their transitive dependencies are bloated, while the median of the percentages of bloated-transitive dependencies for artifacts with height larger than 5 is more than 50%.
This finding confirms and complements the results of Fig. 14, showing that the height of the dependency tree is directly related to the occurrence of bloat. However, the height of the tree may not be the only factor that causes the bloat. For example, we hypothesize that number of transitive dependencies is another essential factor.
In order to validate this hypothesis, we perform a Spearman’s rank correlation test between the number of bloated-transitive dependencies and the size of the dependency tree, i.e., the number of nodes in each tree. We found that there is a significant positive correlation between both variables (ρ = 0.67, p-value < 0.01). This confirms that the actual usage of transitive dependencies decreases with the increasing complexity of the dependency tree. This result is aligned with our previous study that suggest that most of the public API members of transitive dependencies are not used by its clients (Harrand et al. 2019).
In summary, our results point to the excess of transitive dependencies as one of the fundamental causes of the existence of bloated dependencies in the Maven ecosystem.
Single-Module vs. Multi-Module
Let us investigate on the differences between single and multi-module architectures with respect to the presence of bloated dependencies. Figure 16 compares the distributions of bloated and used dependencies between multi-module and single-module artifacts in our dataset. We notice that, in general, multi-module artifacts have slightly more bloat than single-module, precisely 3.1% more (the percentage of bloat in single-module is 5.8% + 67.3% = 73.1% vs. 0.9% + 24.2% + 51.1% = 76.2% in multi-module). More interestingly, we observe that a majority of the inherited dependencies are bloated: 24.2% of the dependencies among multi-module project are bloated-inherited (bi), while only 15% are used-inherited (ui). This suggests that most of the dependencies inherited by Maven artifacts that belong to multi-module artifacts are not used by these modules.
We observe that the percentage of bloated-direct dependencies in multi-module artifacts is very small (0.9%) in comparison with single-module (5.8%). Meanwhile, the percentage of bloated-transitive dependencies in single-module (67.3%) is larger than in multi-module (51.1%). This is due to the “shift” of a part of direct and transitive dependencies into inherited dependencies when using a parent POM. Indeed, the “shift” from direct to inherited is the main motivation for having a parent POM: to have one single declaration of dependencies for many artifacts instead of letting each artifact manage their own dependencies.
This “shift” in the nature of dependencies between single and multi-module artifacts is further emphasized in Fig. 17. This plot shows superimposed log scaled box-plots and violin-plots comparing the distributions of the number of distinct dependency usage types per artifact, for single-module (top part of the figure) and multi-module (bottom part).
We observe that multi-module artifacts have less bloated-direct (1st-Q = 0, median = 0, 3rd-Q = 0) and less bloated-transitive (1st-Q = 2, median = 9, 3rd-Q = 40), compared to single-modules, as shown in Fig. 17. However, multi-module artifacts have a considerably larger number of bloated-inherited dependencies instead (1st-Q = 1, median = 5, 3rd-Q = 20). The extreme case in our dataset is the artifact co.cask.cdap:cdap-standalone:4.3.4, with 326 bloated-inherited dependencies in total.
In summary, the multi-module architecture in Maven projects contributes to limit redundant dependencies and facilitates the consistent versioning of dependencies in large projects. However, it introduces two challenges for developers. First, it leads to the emergence of bloated-inherited dependencies because of the friction of maintaining a common parent POM file: it is more difficult to remove dependencies from a parent POM than from an artifact’s own POM. Second, it is more difficult for developers to be aware of and understand the dependencies that are inherited from the parent POM. This calls for better tooling and user interfaces to help developer grasp and analyze the inherited dependencies in multi-module projects, in order to detect bloated dependencies. To our knowledge, this type of tools is absent in the current Java dependency management ecosystem.
RQ3: To what Extent are Developers Willing to Remove Bloated-Direct Dependencies?
In this research question, our goal is to see how developers react when made aware of bloated-direct dependencies in their projects. We do this by proposing the removal of bloated-direct dependencies to lead developers of mature open-source projects, as described in Section 4.2.2.
Table 4 shows the list of 19 pull requests submitted. Each pull request proposes the removal of at least one bloated-direct dependency in the POM. We received response from developers for 17 pull request. The first and second columns in the table show the name of the project and the pull request on GitHub. Columns three and four represent the number of bloated dependencies removed in the POM and the total number of dependencies removed from the dependency tree with the proposed change, including transitive ones. The last column shows the status of the pull request ( accepted, accepted with changes, rejected, or pending). The last row represent the acceptance rate calculated with respect to the projects with response, i.e., the total number of dependencies removed divided by the number of proposed removals. For example, for project undertow we proposed the removal of 6 bloated dependencies in its module benchmarks. As a result of this change, 17 transitive dependencies were removed from the dependency tree the module.
Overall, from the pull requests with responses from developers, 16/17 were accepted and merged. In total, 75 dependencies were removed from the dependency trees of the projects. This result demonstrates the relevance of handling bloated-direct dependencies for developers, and the practical usefulness of DepClean.
Let us now summarize the developer feedback. First, all developers agreed on the importance of refining the projects’ POMs. This is reflected in the positive comments received. Second, their quick responses suggest that it is easy for them to understand the issues associated with the presence of bloated-direct dependencies in their projects. In 8/17 projects, the response time was less than 24 hours, which is an evidence that developers consider this type of improvement as a priority.
Our results also provide evidence of the fact that we, as external contributors to those projects, were able to identify the problem and propose a solution using DepClean. In the following, we discuss four cases of pull requests that are particularly interesting and the feedback provided by developers.
DepClean detects that jtidy and commons-codec are bloated-direct dependencies present in the modules core and cli of jenkins. jtidy is an HTML syntax checker and pretty printer. commons-codec is an Apache library that provides an API to encode/decode from various formats such as Base64 and Hexadecimal.
Developers were reluctant to remove jtidy due to their concerns of affecting the users of jenkins, which could be potential consumers of this dependency. After further inspection, they found that the class HTMLParser of the nis-notification-lamp-pluginFootnote 10 project relies on jtidy transitively for performing HTML parsing.
Developers also pointed out the fact that there is no classloader isolation in jenkins, and hence all dependencies in its core module automatically become part of its public API. A developer also referred to issues related to past experiences removing unused dependencies. He argued that external projects have depended on that inclusion and their builds were broken by such a removal. For example, the Git client plugin of jenkins mistakenly included Java classes from certain Apache authentication library. When they removed the dependency, some downstream consumers of the library were affected, and they had to include the dependency directly.
Consequently, we received the following feedback from an experienced developer of jenkins:
We’re not precluded from removing an unused dependency, but I think that the project values compatibility more than removal of unused dependencies, so we need to be careful that removal of an unused dependency does not cause a more severe problem than it solves.
After some discussions, developers agreed with the removal of commons-codec in module cli. Our pull request was edited by the developers and merged to the master branch one month after.
DepClean identifies the direct dependency junit-jupiter-engine as bloated. This is a test scope dependency that was added to the POM of checkstyle when migrating integration tests to JUnit 5. The inclusion of this dependency was necessary due to the deprecation of junit-platform-surefire-provider in the Surefire Maven plugin. However, the report of DepClean about this bloated-direct dependency was a false positive. The reason for this output occurs because junit-jupiter-engine is commonly used through reflective calls that cannot be captured at the bytecode level.
Althoughthis pull request was rejected, developers expressed interest in DepClean, which is encouraging. They also proposed a list of features for the improvement of our tool. For example, the addition of an exclusion list in the configuration of DepClean for dependencies that are known to be used dynamically, improvements on the readability of the generated report, and the possibility of causing the build process to fail in case of detecting the presence of any bloated dependency. We implemented each of the requested functionalities in DepClean. As a result, developers opened an issue to integrate DepClean in the Continuous Integration (CI) pipeline of checkstyle, in order to automatically manage their bloated dependencies.Footnote 11
DepClean detects that the direct dependency grpc-netty, declared in the module alluxio-core-transport is bloated. Figure 18 shows that this dependency also induces a total of 10 transitive dependencies that are not used (4 of them are omitted by Maven due to their duplication in the dependency tree). Developers accepted our pull request and also manifested their interest on using DepClean for managing unused dependencies in the future.
DepClean detects a total of 6 bloated-direct dependencies in the benchmarks module of the project undertow: undertow-servlet, undertow-websockets-jsr, jboss-logging-processor, xnio-nio, jmh-generator-annprocess, and httpmime. In this case, we received a rapid positive response from the developers two days after the submission of the pull request. Removing the suggested bloated-direct dependencies has a significant impact on the size of the packaged JAR artifact of the undertow-benchmarks module. We compare the sizes of the bundled JAR before and after the removal of those dependencies: the binary size reduction represents more than 1MB. It is worth mentioning that this change also reduced the complexity of the dependency tree of the module.
RQ4: To what Extent are Developers Willing to Exclude Bloated-Transitive Dependencies?
In this research question, our goal is to see how developers react when made aware of bloated-transitive dependencies. We do this by proposing the exclusion of bloated-transitive dependencies to them, as described in Section 4.2.2.
Table 5 shows the list of 13 pull requests submitted. Each pull request proposes the exclusion of at least one transitive dependency in the POM. We received response from developers for 9 pull requests. The first and second columns show the name of the project and the pull request on GitHub. Columns three and four represent the number of bloated-transitive dependencies explicitly excluded and the total number of dependencies removed in the dependency tree as resulting from the exclusion. The last column shows the status of the pull request ( accepted, rejected, or pending). The last row represents the acceptance rate with respect to the projects with response. For example, for the project spoon we propose the exclusion of four bloated-transitive dependencies in its core module. As a result of this change, 31 transitive dependencies were removed from the dependency tree of this module.
Overall, from the pull requests with responses from developers, 5 were accepted and 4 were rejected. In total, 65 bloated dependencies were removed from the dependency trees of 5 projects. We notice that the accepted pull requests involve those projects for which the exclusion of transitive dependencies also represents the removal of a large number of other dependencies from the dependency tree. This result suggests that developers are more careful concerning this type of contribution.
As in RQ3, we obtained valuable feedback from developers about the pros and cons of excluding bloated-transitive dependencies. In the following, we provide unique qualitative insights about the most interesting cases and explain the feedback obtained from developers to the research community.
DepClean detects the bloated-transitive dependencies constant-pool-scanner and eddsa in the module core of jenkins. These bloated dependencies were induced through the direct dependencies remoting and cli, respectively. In the message of the pull request, we explain how their exclusion contributes to make the core of jenkins slimmer and its dependency tree clearer.
Although both dependencies were confirmed as unused in the core module of jenkins, developers rejected our pull request. They argue that excluding such dependencies has no valuable repercussion for the project and might actually affect its clients, which is correct. For example, constant-pool-scanner is used by external components, e.g., the class RemoteClassLoader in the remotingFootnote 12 project relies on this library to inspect the bytecode of remote dependencies.
As shown in the following quote from an experienced developer of Jenkins, there is a consensus on the usefulness of removing bloated dependencies, but developers need strong facts to support the removal of transitive dependencies:
Dependency removals and exclusions are really useful, but my recommendation would be to avoid them if there is no substantial gain.
DepClean reports on the bloated-transitive dependencies listenablefuture and auto-value-annotations in module auto-common of the Google auto project. We proposed the exclusion of these dependencies and submitted a pull request with the POM change.
Developers express several concerns related to the exclusion of these dependencies. For example, a developer believes that it is not worth maintaining exclusion lists for dependencies that cause no problem. They point out that although listenableFuture is a single class file dependency, its presence in the dependency tree is vital to the project, since it overrides the version of the guava library that have many classes. Therefore, the inclusion of this dependency is a strategy followed by guava to narrow the access to the interface ListenableFuture and not to the whole library.Footnote 13
On the other hand, developers agree that auto-value-annotations is bloated. However, they keep it, arguing that it is a test-only dependency, and they prefer to keep annotation-only dependencies and let end users exclude them when desired.
The response from developers suggests that bloated dependencies with test scope are perceived as less harmful. This is reasonable since test dependencies are only available during the test, compilation, and execution phases and are not shipped transitively in the JAR of the artifact. However, we believe that although it is a developers’ decision whether they keep this type of bloated dependency or not, the removal of testing dependencies is regularly a desirable refactoring improvement.
DepClean detects that the bloated-transitive dependency kotlin-stdlib-common is present in the dependency tree of modules moshi-kotlin, moshi-kotlin-codegen, and moshi-kotlin-tests of project moshi. This dependency is induced from a common dependency of these modules: kotlin-stdlib.
Developers rejected our pull requests, arguing that excluding such transitive dependency prevents the artifacts from participating in the proper dependency resolution of their clients. They suggest that clients interested in reducing the size of their projects can use specialized shrinking tools, such as ProGuard,Footnote 14 for this purpose.
Although the argument of developers is valid, we believe that delegating the task of bloat removal to their library clients imposes an unnecessary burden on them. On the other hand, recent studies reveal that library clients do not widely adopt the usage of dependency analysis tools for quality analysis purposes (Nguyen et al. 2020).
DepClean detects that the transitive dependencies org.eclipse.core.resources, org.eclipse.core.runtime, org.eclipse.core.filesystem, and org.eclipse.text org.eclipse.jdt.core are bloated. All of these transitive dependencies were induced by the inclusion of the direct dependency org.eclipse.jdt.core, declared in the POM of core module of the spoon library.
Table 6 shows how the exclusion of these bloated-transitive dependencies has a positive impact on the size and the number of classes of the library. As we can see, by excluding these dependencies the size of the jar-with-dependencies of the core module of spoon is trimmed from 16.2MB to 12.7MB, which represents a significant reduction in size of 27.6%. After considering this improvements, the developers confirmed the relevance of this change and merged our pull request into the master branch of the project.
DepClean detects the bloated-transitive dependencies listenablefuture, httpcore and netty in the core module of Apache accumulo. These dependencies were confirmed as bloated by the developers. However, they manifested their concerns regarding their exclusion, as expressed in the following comment:
I’m not sure I want us to take on the task of maintaining an exclusion set of transitive dependencies from all our deps POMs, because those can change over time, and we can’t always know which transitive dependencies are needed by our dependencies.
After the discussion, developers decided to accept and merge the pull request. Overall, developers considered that the proposal is a good idea. They suggest that it would be better to approach the communities of each of the direct dependencies that they use, and encourage them to mark those dependencies as optional, thus they would not be automatically inherited by their users.
DepClean detects the bloated-transitive dependency flexmark-jira-converter. This dependency is induced through the direct dependency flexmark-ext-emoji, declared in the core module of the para project. Our further investigation on the Maven dependency tree of this module revealed that this bloated dependency adds a total of 19 additional dependencies to the dependency tree of the project, of which 15 are detected as duplicated by Maven.
Because of this large number (19) of bloated-transitive dependencies removed, developers accepted the pull request and merged the change into the master branch of the project the same day of the pull request submission.