assert-kth / depclean Goto Github PK

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

It turns out that the parameters used in the command line read differently than in the readme.

Example:

It would be better to unify them, eg. all camel case.

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>

The JSON file produced by DepClean doesn't show the size of the root node, ie. the analyzed project.

The current github-pages of DepClean needs to be updated/reimplemented completely.

This is what we want:

• A simple and beautiful Jekyll based landing page that:
  • Describe DepClean
  • Present some statistics regarding the number of dependencies analyzed + number of pull request accepted thanks to DepClean (see the companion paper)
  • Show some nice D3 visualization (see the related project)

@cesarsotovalero thank you for the flag
It's super useful!

How about naming the file depclean-results.json (instead of results.json) ?

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

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:

1. Configure the maven-processor-plugin to use the mapstruct annotation

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

2. Add required mapstruct dependencies

    <dependency>
      <groupId>org.mapstruct</groupId>
      <artifactId>mapstruct</artifactId>
    </dependency>
    <dependency>
      <groupId>org.mapstruct</groupId>
      <artifactId>mapstruct-processor</artifactId>
      <scope>provided</scope>
    </dependency>

3. Run depclean with debloated-pom generation

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

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:

1. Go to '\depclean\depclean-maven-plugin\target\checkstyle-checker.xml'
2. See line no. 63
3. Run mvn checkstyle:checkstyle
4. Go to '\depclean\depclean-maven-plugin\target\site\checkstyle.html'
5. Open this file with your browser and read the first line.

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.

Screenshots

Additional context
It might also happen that the report is correct but the comment which is showing that google_checks are adopted is wrong.

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

The class JarUtils in depclean-maven-plugin is not tested.

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.

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.

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.

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.

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:

1. Use Lombok (for instance @Data annotation) with its dependency
2. Run depclean

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

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.

It is useful to have a JSON file with the classes used per dependency.

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;

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

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

Some dependencies cannot be fetched from external repositories. Thus, these dependencies cannot be analyzed.

There is a lack of documentation for various packages, classes, interfaces, and methods.

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.

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:

1. Add custom filter in 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>

2. Run depclean

Expected behavior
Web filters declared in the web.xml are added to the Dependency Usage Analysis

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

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.

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:

1. jenv local 15 at project root
2. 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)

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.

We want to know the ratio of classes that are used per dependency. Add two fields to the JSON file:

1. nb_classes
2. nb_classes_used

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?

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

1. Clone project : https://github.com/mtorres10/DepCleanDebug
2. Make sure you are using JDK 11 for this project.
3. Compile using maven
4. Run depclean goal using maven
5. See error

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

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.

Similar to the jacoco plugin which can fail the build if there is some code that is not covered.

WDYT?

Proposal

We want to implement DepClean as a software Bot running on top of GitHub, in the same spirit of Renovate or Dependabot.

Specs

• DepClean will execute as requested by the user (e.g. calling it from a commit message)
• DepClean will produce a report about the dependency usage status

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
Classes configured in spring's bean.xml files are not kept as mandatory dependencies.

To Reproduce
Steps to reproduce the behavior:

1. Create a Spring project with XML configuration
2. Add rightful maven dependencies
3. Run depclean

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]

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

The problem about the checkstyle that I mention in this issue #42 still exists.

See report generated:

In code too:

But this time I also got the cause for it.
In the project's pom file it is clearly mentioned that Google_checks are adopted.

See this

It is true that in the parent checkstyle module, the configuration is of google checks.
See

But the module that is configured in both depclean core and maven plugin is of sun_checks.
See this

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.

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.

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.

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

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": []
}

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:

• The direct, transitive, and inherited dependencies as nodes
• The status of those dependencies (used or bloated) as colored edges

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

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,

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