assert-kth / depclean Goto Github PK
View Code? Open in Web Editor NEWDepClean automatically detects and removes unused dependencies in Maven projects (https://dx.doi.org/10.1007/s10664-020-09914-8)
License: MIT License
DepClean automatically detects and removes unused dependencies in Maven projects (https://dx.doi.org/10.1007/s10664-020-09914-8)
License: MIT License
I've built the plugin from source and when I run mvn se.kth.castor:depclean-maven-plugin:1.1.0:depclean
, I receive this error. I should be getting the analysis but I don't.
[INFO] Scanning for projects...
[INFO]
[INFO] -----------------< com.gmail.bschoe322:DiscordVerify >------------------
[INFO] Building DiscordVerify 1.0.0
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- depclean-maven-plugin:1.1.0:depclean (default-cli) @ DiscordVerify ---
-------------------------------------------------------
[INFO] Starting DepClean dependency analysis
[ERROR] Unable resolve all the dependencies.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.634 s
[INFO] Finished at: 2020-09-03T13:29:10-04:00
[INFO] ------------------------------------------------------------------------
Similar to the jacoco plugin which can fail the build if there is some code that is not covered.
WDYT?
Hi,
DepClean is part of Google Summer of Code, as a subproject of the CASTOR Software Research Centre.
If you'd like to be a DepClean contributor as part of GSoC, drop a comment on this issue.
Best,
César
Describe the bug
Execution default-cli of goal se.kth.castor:depclean-maven-plugin:2.0.2-SNAPSHOT:depclean failed: Unsupported class file major version 59 -> [Help 1]
To Reproduce
Steps to reproduce the behavior:
mvn clean compile compiler:testCompile se.kth.castor:depclean-maven-plugin:2.0.2-SNAPSHOT:depclean
Expected behavior
depclean
ends without error
Additional context
I'm using depclean on a multi-module maven project. Everything is compiled using Java 15 by the same maven command that execute depclean.
I suspect the integrated ASM version is not compatible with Java 15 yet, I'll do some testings
Here's the full stacktrace :
[ERROR] Failed to execute goal se.kth.castor:depclean-maven-plugin:2.0.2-SNAPSHOT:depclean (default-cli) on project entity-rh: Execution default-cli of goal se.kth.castor:depclean-maven-plugin:2.0.2-SNAPSHOT:depclean failed: Unsupported class file major version 59 -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal se.kth.castor:depclean-maven-plugin:2.0.2-SNAPSHOT:depclean (default-cli) on project entity-rh: Execution default-cli of goal se.kth.castor:depclean-maven-plugin:2.0.2-SNAPSHOT:depclean failed: Unsupported class file major version 59
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:64)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal se.kth.castor:depclean-maven-plugin:2.0.2-SNAPSHOT:depclean failed: Unsupported class file major version 59
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:64)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: java.lang.IllegalArgumentException: Unsupported class file major version 59
at org.objectweb.asm.ClassReader.<init> (ClassReader.java:195)
at org.objectweb.asm.ClassReader.<init> (ClassReader.java:176)
at org.objectweb.asm.ClassReader.<init> (ClassReader.java:162)
at org.objectweb.asm.ClassReader.<init> (ClassReader.java:283)
at se.kth.depclean.core.analysis.asm.DependencyClassFileVisitor.visitClass (DependencyClassFileVisitor.java:53)
at se.kth.depclean.core.analysis.ClassFileVisitorUtils.visitClass (ClassFileVisitorUtils.java:138)
at se.kth.depclean.core.analysis.ClassFileVisitorUtils.acceptDirectory (ClassFileVisitorUtils.java:120)
at se.kth.depclean.core.analysis.ClassFileVisitorUtils.accept (ClassFileVisitorUtils.java:65)
at se.kth.depclean.core.analysis.asm.ASMDependencyAnalyzer.analyze (ASMDependencyAnalyzer.java:45)
at se.kth.depclean.core.analysis.DefaultProjectDependencyAnalyzer.collectDependencyClasses (DefaultProjectDependencyAnalyzer.java:230)
at se.kth.depclean.core.analysis.DefaultProjectDependencyAnalyzer.buildProjectDependencyClasses (DefaultProjectDependencyAnalyzer.java:164)
at se.kth.depclean.core.analysis.DefaultProjectDependencyAnalyzer.analyze (DefaultProjectDependencyAnalyzer.java:93)
at se.kth.depclean.DepCleanMojo.execute (DepCleanMojo.java:417)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:64)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Is your feature request related to a problem? Please describe.
On large project, depclean takes a very long time to execute, most of the time is spent on excluding dependencies.
Here are some details. Given this analysis result:
USED DIRECT DEPENDENCIES [37]
USED INHERITED DEPENDENCIES [0]:
USED TRANSITIVE DEPENDENCIES [218]:
POTENTIALLY UNUSED DIRECT DEPENDENCIES [18]:
POTENTIALLY UNUSED INHERITED DEPENDENCIES [0]:
POTENTIALLY UNUSED TRANSITIVE DEPENDENCIES [225]:
It took 5h29min to complete depclean debloated-pom generation.
I have no timestamps, but I'd say it was between 20/30 min to analyse the dependencies, then the rest to exclude them and generate the debloated pom
Describe the solution you'd like
Better perfs, so this can be included in some regular CI jobs
Describe alternatives you've considered
None ATM
Describe the bug
When a dependency has both a folder and a file named the same at the same level depclean throws a file not found exception (java.io.FileNotFoundException).
When both folder and file are named the same, depclean extracts the file correctly but does not create the folder. If folder has child items, depclean tries to extract those items to the folder (as it should), but since it was not created in the filesystem a file not found exception is raised.
Extraction of subsequent files for that jar seems to be halted.
Update: This seems to be caused due in class jarUtils link to line here
new File(filePath).getParentFile().mkdirs();
as mkdirs() will not create the folder because a file named the same as the folder already exists
Side by side comparison of jar content vs extracted files
Steps To Reproduce
Expected behavior
All dependencies should be extracted correctly
Actual behavior
Using the current version available in maven "2.0.0" user only gets a message stating :
[ERROR] Problem decompressing jar file.
Using version "2.0.1-Snapshot" user gets a message with a bit more details:
[WARNING] Problem decompressing jar file: path\to\dependency\dep.jar
Screenshots
v 2.0.0
v 2.0.1-Snapshot
When trying to download and build the source code, there is a problem because core version 1.0.0 is broken (can't find parent POM).
Changing the plugin version solved the issue.
Same way, the documentation (README) still refers 1.0.0 version, which results in an error when trying to run the plugin in other projects.
Hi Team,
When I am running the mvn se.kth.castor:depclean-maven-plugin:1.1.2-SNAPSHOT:depclean -Dcreate.pom.debloated=true -Dcreate.result.json=true I am getting :
Failed to execute goal se.kth.castor:depclean-maven-plugin:1.1.2-SNAPSHOT:depclean (default-cli) on project req-lineitem-srv: Execution default-cli of goal se.kth.castor:depclean-maven-plugin:1.1.2-SNAPSHOT:depclean failed.: IllegalArgumentException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal se.kth.castor:depclean-maven-plugin:1.1.2-SNAPSHOT:depclean (default-cli) on project req-lineitem-srv: Execution default-cli of goal se.kth.castor:depclean-maven-plugin:1.1.2-SNAPSHOT:depclean failed.
My Configuration are:
[DEBUG] Configuring mojo 'se.kth.castor:depclean-maven-plugin:1.1.2-SNAPSHOT:depclean' with basic configurator -->
[DEBUG] (f) createPomDebloated = true
[DEBUG] (f) createResultJson = true
[DEBUG] (f) failIfUnusedDirect = false
[DEBUG] (f) failIfUnusedInherited = false
[DEBUG] (f) failIfUnusedTransitive = false
[DEBUG] (f) ignoreDependencies = []
[DEBUG] (f) ignoreScopes = []
[DEBUG] (f) project = MavenProject: com.sap.requisitioning:req-lineitem-srv:0.0.1 @ C:\Requistion-Workspace\RequisitionLineItem\srv\pom.xml
[DEBUG] (f) session = org.apache.maven.execution.MavenSession@4cc7d00d
[DEBUG] (f) skipDepClean = false
[DEBUG] -- end configuration --
Thanks
Sagar Gupta
It would be useful to implement a web graph tool for DepClean, in the same spirit of https://github.com/ExpediaGroup/jarviz/tree/master/jarviz-graph.
The web interface must show the dependency analysis results for an uploaded project. The tool will show the results as a DAG with the following information:
Tests are the best way to make sure that our program is working fine and will work fine in the future too and if somehow our program didn't work fine then the tests warn us before the program fails.
So, currently, there only a few tests in the whole depclean project and writing more tests for the project will definitely an upper hand on unintentional program failures.
It turns out that the parameters used in the command line read differently than in the readme.
Example:
In the README | In the command line |
failIfUnusedDirect | fail.if.unused.direct |
It would be better to unify them, eg. all camel case.
Hey! @cesarsotovalero,
As mentioned in the CASTOR's GSoC idealist for DepClean project that there is a need for the support of analysis of the multi-module projects.
I want to ask that can you describe this feature a little bit more?
As there is no existing issue or PR regarding this feature so I am unable to getting what is the current situation of this issue (feature) and what is needs to be implemented.
Thank you
It is useful to have a JSON file with the classes used per dependency.
Describe the bug
When I am trying to run either mvn se.kth.castor:depclean-maven-plugin:2.0.1:depclean -DcreatePomDebloated=true
or mvn se.kth.castor:depclean-maven-plugin:2.0.1:depclean -DcreatePomDebloated=true -DcreateResultJson=true
then either of these is not producing a debloated-pom.xml
in the root of the project (The later one is only producing a .json and .csv file but not .xml file) .
See the results of mvn se.kth.castor:depclean-maven-plugin:2.0.1:depclean -DcreatePomDebloated=true
here
and result of mvn se.kth.castor:depclean-maven-plugin:2.0.1:depclean -DcreatePomDebloated=true -DcreateResultJson=true
here
Expected behavior
A debloated-pom.xml file should be created in the root of the project.
I am unable to get what I am doing wrong? But if the problem is from my side only, then please guide me through this.
Thank you
Abhay
Describe the bug
After depclean completes, and given mapstruct processor is used, the mapstruct-processor
direct dependency is not longer present on the debloated pom.xml
To Reproduce
Steps to reproduce the behavior:
<plugin>
<groupId>org.bsc.maven</groupId>
<artifactId>maven-processor-plugin</artifactId>
<executions>
<execution>
<id>process</id>
<goals>
<goal>process</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<processors>
<processor>org.mapstruct.ap.MappingProcessor</processor>
</processors>
</configuration>
</execution>
</executions>
</plugin>
<dependency>
<groupId>org.mapstruct</groupId>
<artifactId>mapstruct</artifactId>
</dependency>
<dependency>
<groupId>org.mapstruct</groupId>
<artifactId>mapstruct-processor</artifactId>
<scope>provided</scope>
</dependency>
Expected behavior
mapstruct-processor
dependency is conserved
Additional context
Mapstruct generates code during the generated-sources
phase, but do not keep mapstruct-processor
imports in the generated classes. This may be why it is eventually removed from the debloated-pom.
One could manually list this dependency into the ignoreDependencies
configuration, but it may be better to consider annotation processor classes to be rightful provided
dependencies
The JSON file with the information of the dependencies of the projects generated by DepClean includes the size of the JARs of each dependency. However, it doesn't include the size of the project itself (the root of the JSON tree). This information is relevant to compare the size of the project concerning the size of all its dependencies.
We are getting this issue:
[ERROR] Plugin se.kth.castor:depclean-maven-plugin:1.0.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for se.kth.castor:depclean-maven-plugin:jar:1.0.0: Could not find artifact se.kth.castor:depclean-parent-pom:pom:1.0.0 in central (https://repo.maven.apache.org/maven2) ->
We have added the plugin and goal under build section of pom.xml as specified in the ReadMe.
So it can be fixed either by mentioning that sun_checks are adopted in parent pom file or replace the checkstyle with this one in both depclean core as well as in maven plugin.
I can fix this issue but please suggest to me the correct way (mentioned above) of fixing this issue.
Hi,
First of all, thanks for coming up with such a great idea of a Maven plugin. Love it!
Running the plugin as described in the Readme.md with versions 1.1.0 and 1.1.2 leads always to the error message
[Error] Unable to resolve all the dependencies.
Running Maven in debug mode with -X did not really help ... any idea what could be wrong? I tried to declare the plugin in the pom but also just ran the plugin directly from the command line with all the params in the CLI.
Btw. we develop the apps in an enterprise setup where we have proxies, self-signed certs and so on.
Best,
Patrick
We want to implement DepClean as a software Bot running on top of GitHub, in the same spirit of Renovate or Dependabot.
This folder includes small Maven projects to be used for testing Depclean with Maven:
https://github.com/castor-software/depclean/tree/master/depclean-maven-plugin/src/test/resources-its/
@ABHAY0O7, can you add build.gradle files for each of these projects, so you can use them to test the Depclean gradle plugin?
The JSON file produced by DepClean doesn't show the size of the root node, ie. the analyzed project.
In StackOverflow, please create the tag [depclean] to post any question on the usage of DepClean.
The tag is not available at the moment, and you need at least 1500 reputation points to create the tag.
Once the tag is created, all the questions should appear in https://stackoverflow.com/questions/tagged/depclean
In the Depclean Github Deployed Page the image URL is expired. Please change the URL, by setting the project locally and changing the link to this link.
Here is the sample screenshot, that I wanted to attach with this issue. So, that the issue can be confirmed.
Description of the bug
In the pom.xml file of the maven plugin, it is mentioned that google style is adopted for the checkstyle plugin but after running
mvn checkstyle:checkstyle
the report generated in checkstyle.html is for sun checks.
To Reproduce
Steps to reproduce the behavior:
mvn checkstyle:checkstyle
Expected behavior
The first line you read above should contain google_checks.xml instead of sun_checks.xml and the whole report should show errors of google_checks instead of sun_checks.
Additional context
It might also happen that the report is correct but the comment which is showing that google_checks are adopted is wrong.
Describe the bug
Dependencies with module-info appear as bloated, but it is indeed used.
To Reproduce
For example in Spork's visualization the direct dependency junit-jupiter appears as bloated. See also Spoon's visualization
Expected behavior
Dependencies with module-info should appear as used.
Some dependencies cannot be fetched from external repositories. Thus, these dependencies cannot be analyzed.
@cesarsotovalero thank you for the flag
It's super useful!
How about naming the file depclean-results.json (instead of results.json) ?
Is your feature request related to a problem? Please describe.
When analyzing for some dependencies, for example selenium (see #46) due an odd jar structure depclean does not fully extract jar contents, so not all classes are analized
Describe the solution you'd like
Allow the extraction of files to continue, and print a warning of which file caused an issue.
Describe the bug
If you have custom filters in your web.xml
, they do not count as project dependencies, and their jar is removed i the debloated pom.xml
To Reproduce
Steps to reproduce the behavior:
web.xml
, like this: <filter>
<filter-name>sitemesh</filter-name>
<filter-class>org.sitemesh.config.ConfigurableSiteMeshFilter</filter-class>
<init-param>
<param-name>configFile</param-name>
<param-value>/WEB-INF/classes/sitemesh3.xml</param-value>
</init-param>
</filter>
Expected behavior
Web filters declared in the web.xml are added to the Dependency Usage Analysis
The plugin is built on Java 11, so not possible to use with a project using jdk 8.
Throws exception,
[ERROR] Failed to execute goal se.kth.castor:depclean-maven-plugin:1.1.0:depclean (default) on project idsk-commons-media: Execution default of goal se.kth.castor:depclean-maven-plugin:1.1.0:depclean failed: An API incompatibility was encountered while executing se.kth.castor:depclean-maven-plugin:1.1.0:depclean: java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer;
Currently, the DepClean codebase lacks proper code style conventions. This makes the codebase messy and is overall bad for maintainability. The best way to mitigate this is by enforcing the use of strict code style rules.
Checkstyle is currently one of the best tools for this purpose. Configuring Checkstyle in DepClean will help newcomers to have a more clean codebase to work with.
DepClean fails to fill in the information regarding the status
and type
of dependencies in the JSON when the version is not explicit in the POM.
For example, the following dependency is not reported correctly:
<dependency>
<groupId>org.apache.flink</groupId>
<artifactId>flink-annotations</artifactId>
<version>${project.version}</version>
</dependency>
DepClean should display the size (in Mb) of each dependency in the dependency tree of the analyzed project. The dependencies in the report should be displayed in decreasing order according to this value. This will allow developers to prioritize the dependencies that they want to remove.
Hey! @cesarsotovalero,
I am really sorry to open this issue but I am facing some problems in communicating with you, please reply to this issue #37 conversation. I have asked a question there.
Thank you
Abhay
We want to know the ratio of classes that are used per dependency. Add two fields to the JSON file:
nb_classes
nb_classes_used
Describe the bug
After depclean completes, and given lombok is used, the lombok direct dependency is not longer present on the debloated pom.xml
To Reproduce
Steps to reproduce the behavior:
@Data
annotation) with its dependencyExpected behavior
Lombok is kept in the debloated pom
Additional context
Lombok does bytecode modification, removing all traces of itself while generating plumber code. That is why it is not present in the analyzed bytecode. It is visible in the source code, though.
There is a lack of documentation for various packages, classes, interfaces, and methods.
The current github-pages of DepClean needs to be updated/reimplemented completely.
This is what we want:
DepClean computes the size of the dependencies based on the dependency jars downloads from Maven central using the mvn dependency:copy-dependencies
plugin. If the name of the JAR does not match the name of the dependencies as obtained from the mvn dependency:tree
, then the size of the JAR is not obtained and the sorting crashes triggering a NullPointException
.
Hello @cesarsotovalero.
I was thinking of an idea to implement depclean-gradle-plugin and I have one for it.
The logic will be the same as what we used in the depclean-maven-plugin but in a Gradle project, we have to just convert the build.gradle file into its corresponding pom-default.xml and then we can use the gradle-maven plugin to analyze the dependencies and the project or we can just use it's code to analyze the dependencies in the name of gradle-plugin.
It is just an idea for now but I am thinking that sharing it with others either may improve it or may warn me that it has so many consequences.
So, anyone who sees this issue, please share your views on it.
Thank you
Abhay.
The class JarUtils
in depclean-maven-plugin
is not tested.
At this moment, DepClean analyzes the project's bytecode located in target/classes
and target/test-classes
. It is desirable to have a parameter that allows to not analyze bytecode classes used for testing in the project. This way, the dependencies that are only used for testing will be considered unused.
This parameter is useful to detect dependencies that have a compile
scope but are only used for testing. Hence, these dependencies should have a test
scope.
Great idea, thank you (again).
It would be very helpful to see the scope of unused dependencies, or maybe exclude certain scopes from the analysis. IMO, debloating is particularly useful for those scopes needed at runtime.
When a dependency has no types, a division by zero occurs, causing the usageRatio
in depclean-results.json
to be NaN
.
Example:
{
"id": "com.google.guava:listenablefuture:jar:9999.0-empty-to-avoid-conflict-with-guava:test",
"coordinates": "com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava",
"groupId": "com.google.guava",
"artifactId": "listenablefuture",
"version": "9999.0-empty-to-avoid-conflict-with-guava",
"scope": "test",
"packaging": "jar",
"omitted": false,
"size": 2199,
"type": "transitive",
"status": "bloated",
"parent": "com.google.guava:guava:jar:30.1-jre:test",
"allTypes": [],
"usedTypes": [],
"usageRatio": NaN,
"children": []
}
In some enterprise development contexts, the project uses dependencies from other repositories than Maven Central. In this case, DepClean could do a partial analysis of the dependencies: analyzing the dependencies that it can download and reporting the ones that it couldn't.
See #28 (comment).
Describe the bug
Classes configured in spring's bean.xml
files are not kept as mandatory dependencies.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
All spring beans declared in the XML configuration count as rightful dependencies
Additional context
It may be the same with Java Config textual declaration inside annotations (but I don't have a use case in mind ATM)
It fails too for XML namespace imports:
[ERROR] myTest Time elapsed: 0 s <<< ERROR!
java.lang.IllegalStateException: Failed to load ApplicationContext
Caused by: org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/data/jpa]
Offending resource: class path resource [my-beans.xml]
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.