search

ASSERT-KTH / depclean

DepClean automatically detects and removes unused dependencies in Maven projects (https://dx.doi.org/10.1007/s10664-020-09914-8)
MIT License
252 stars 28 forks source link

Testing the gradle plugin #92

Closed bbaudry closed 2 years ago

bbaudry commented 3 years ago

@ABHAY0O7 can you implement a test harness for the gralde plugin, using the small gradle projects that you initiated with issue #91?

ABHAY0O7 commented 3 years ago

@ABHAY0O7 can you implement a test harness for the gralde plugin, using the small gradle projects that you initiated with issue #91?

@bbaudry @tdurieux Yes, I can implement this. But, there are few things that I want to convey to you :

Also, if you allow me, then I want to update my timeline here ie. I will start working on the Gradle plugin from now and only after successfully completing this task, I will discuss with you my approach to the next GSoC task.

So this is my documented plan for the plugin task (as I mentioned in my proposal). If require any amendments, then I welcome you otherwise I can start my work.

Thank you. Abhay

tdurieux commented 3 years ago

Hello, could you try to explain by message first? I am a busy week I am not sure that we will find a time for a meeting.

ABHAY0O7 commented 3 years ago

Hello, could you try to explain by message first? I am a busy week I am not sure that we will find a time for a meeting.

Ok, no problem, I will mention my issue in this thread by tomorrow.

ABHAY0O7 commented 3 years ago

Hello @bbaudry @tdurieux Earlier I was facing 3 problems, but now, I have solved two of them. I am currently working on the third problem and I may solve this one too. If I solve this one, then I will push these commits on my current open PR, and if not then I will convey it to you.(max 2 days)

Thank you

tdurieux commented 3 years ago

Perfect!

ABHAY0O7 commented 3 years ago

Hello @bbaudry @tdurieux These are the things that I have done in my recent commits on #93 What new :

Problem:

What I tried to solve this problem:

If you got the problem then please suggest to me some solutions regarding this. If you not then I can only explain it in a meet via screen sharing.

NOTE: To test the plugin results again use the method that I mentioned in my PR #93

Thank you

tdurieux commented 3 years ago

From what I understand copyDependenciesLocally take the classpath and copy all the jar into a specific folder. It does not seem to be something that is hard to recreate. You can already get the classpath and then you can just copy everything that is in the classpath into a specific folder.

Is there a reason why you could not do this?

ABHAY0O7 commented 3 years ago

Is there a reason why you could not do this?

The only reason behind this was, I didn't know that it takes classpath. But, thanks for your valuable help, now the plugin is executing correctly. I have implemented the proposed way of copy dependencies, I will push my recent commits with some tests in a day or two. And then I will proceed to make it highly configurable.

Thank you

ABHAY0O7 commented 3 years ago

Hello, @tdurieux @bbaudry, For the last two days, my laptop's battery got damaged, so I was unable to work on the project. I don't even have a phone, so I was unable to inform you as my ID is only open on my laptop. But, now everything is OK, and soon I will push my recent work on the open PR.

Thank you

tdurieux commented 3 years ago

No worry, I hope that the damage was not too big. Ping me when you think that your PR is ready.

ABHAY0O7 commented 3 years ago

Hello @tdurieux I have recently pushed a commit on the open PR What new:

I think up to now the plugin is working fine and I think now I should move forward to make it configurable. Waiting for your feedback...

Thank you

ABHAY0O7 commented 3 years ago

Hello @tdurieux @bbaudry I need some help... Currently, I am stuck, I am not getting a way so that I can make the plugin configurable. I know what to do but I am not getting a way of doing it correctly. I have searched on the internet about it, but I am unable to find anything solid. Could you please help me in getting out of this situation by referencing some blogs or articles or anything else that can demonstrate how to add extra parameters to a task using Gradle API?

Thank you

tdurieux commented 3 years ago

Are you trying to do be able to add optional properties to the plugin, like: https://github.com/riiid/gradle-github-plugin/tree/63be285ea8de3be6d65d86462c5e1ed09ea1a1e1?

This project is relatively simple you can follow what they are doing, the properties are registered here: https://github.com/riiid/gradle-github-plugin/blob/63be285ea8de3be6d65d86462c5e1ed09ea1a1e1/src/main/groovy/co/riiid/gradle/GithubPlugin.groovy#L11 and defined here: https://github.com/riiid/gradle-github-plugin/blob/63be285ea8de3be6d65d86462c5e1ed09ea1a1e1/src/main/groovy/co/riiid/gradle/GithubExtension.groovy

Does it help you?

Side note: when I am struggling with a specific task that I expect someone already did, I look on github for projects or API usage. Generally, it helps me to solve my problem.

ABHAY0O7 commented 3 years ago

Side note: when I am struggling with a specific task that I expect someone already did, I look on GitHub for projects or API usage. Generally, it helps me to solve my problem.

This side note helps me a lot. I looked over some other projects on GitHub, watched some video tutorials on YouTube, and finally found the correct solution to my problem. Currently, I have successfully configured the isIgnoreTest parameter. Now I am moving to add some more parameters. Soon, I will update my work with some new tests.

Thank you Abhay

ABHAY0O7 commented 3 years ago

Hii @tdurieux @bbaudry In the previous comment, I claimed that I have successfully configured the parameter isIgnoreTest, but that was a misconception from my side. When I was using that parameter to test the plugin, I commented out all the existing test code written for the project, and in the result, the plugin shows all the direct test dependency as UNUSED DIRECT and I thought that it is because of the parameter isIgnoreTest, but these dependencies are actually not used in our project. So, that's was a very poor misconception from me and I really apologize for that.

But, now I have tried so many different different ways to add parameters, but nothing has worked as I expected. Also, I tried the way that followed in your reference, but I think here groovy and java is making some difference i.e. the code which is written in the reference can not be written in java.

So, please suggest to me something that I can do here.

Thank you

tdurieux commented 3 years ago

I am not sure to understand what is exactly the problem:

if you setup your class depcleanGradleTask like this:

package se.kth.depclean;

import java.util.Locale;

import org.gradle.api.Action;
import org.gradle.api.DefaultTask;
import org.gradle.api.Project;
import org.gradle.api.tasks.TaskAction;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class depcleanGradleTask extends DefaultTask {

    public static final Logger log = LoggerFactory.getLogger(depcleanGradleTask.class);

    boolean isIgnoreTest = false;

    @TaskAction
    public void printDependencies() {
        System.out.println("isIgnoreTest: " + isIgnoreTest);
        log.info("Debloating starts...".toUpperCase(Locale.ROOT));

        Action<Project> defaultAction = new depcleanGradleAction();
        getProject().allprojects(defaultAction);

        log.info("Debloating ends.".toUpperCase(Locale.ROOT));
    }

}

and in depclean-gradle-plugin/src/Test/resources/all_dependencies_unused/build.gradle you have 

buildscript{
  repositories {
      mavenLocal()
      repositories { flatDir name: 'libs', dirs: "../../../../build/libs" }
      dependencies{
        classpath 'se.kth.castor:depclean-gradle-plugin:1.0-SNAPSHOT'
      }
  }
}

plugins {
    id 'java'
    id 'maven-publish'
}
apply plugin: 'se.kth.castor.depclean-gradle-plugin'
debloat.isIgnoreTest = true

repositories {
    mavenCentral()
    mavenLocal()
    jcenter()
}

dependencies {
    implementation 'com.fasterxml.jackson.core:jackson-databind:2.12.2'
}

group = 'org.foo.bar'
version = '1.0.0-SNAPSHOT'
description = 'foobar'
//java.sourceCompatibility = JavaVersion.VERSION_1_8

tasks.withType(JavaCompile) {
    options.encoding = 'UTF-8'
}

and you execute the debloat plugin on depclean-gradle-plugin/src/Test/resources/all_dependencies_unused you will see that isIgnoreTest: trueis printed.

Does it help you?

ABHAY0O7 commented 3 years ago

Hii @tdurieux I got the concept you explained above. Previously I was using @Input & @Optional annotations which was creating some kind of unstability. But now, I also found a way of adding extra configuration to the task. 1) I created a class named DepcleanGradlePluginExtension to add extra configuration directly to the project.

package se.kth.depclean;

public class DepcleanGradlePluginExtension {

    public boolean isIgnoreTest = false;

    public boolean isIgnoreTest() {
        return isIgnoreTest;
    }

    public boolean skipDepclean = false;

    public boolean isSkipDepclean() {
        return skipDepclean;
    }

}

2) Add it to the project's configuration.

package se.kth.depclean;

import org.gradle.api.Plugin;
import org.gradle.api.Project;
import org.jetbrains.annotations.NotNull;

public class depcleanGradlePlugin implements Plugin<Project> {

    String taskName = "debloat";

    @Override
    public void apply(@NotNull Project project) {

        project.getExtensions().create("depclean", DepcleanGradlePluginExtension.class);
        createTask(project);
    }

    public void createTask(Project project) {
        depcleanGradleTask task = project.getTasks().create(taskName, depcleanGradleTask.class);
        task.setGroup("group");
        task.setDescription("Print outcome.");
    }
}

3) Using it in the depcleanGradleAction by creating an extension object. Just add these lines of code at the beginning of the execute() method of depcleanGradleAction.

        DepcleanGradlePluginExtension extension = project.getExtensions().getByType(DepcleanGradlePluginExtension.class);
        boolean isIgnoreTest = extension.isIgnoreTest();
        boolean skipDepClean = extension.isSkipDepclean();

        if (skipDepClean) {
            printString("Skipping DepClean plugin execution");
            return;
        }

4) Now use it from your build.gradle directly. i.e. just include this extra section in your build.gradle

depclean {
    skipDepclean = true
}

And this is the result exactly as I expected.


> Task :debloat
Skipping DepClean plugin execution

BUILD SUCCESSFUL in 2s
1 actionable task: 1 executed

I have seen some projects on Github which use both ways. Now, please can you suggest to me which method I should prefer? Also, it will be helpful for me if you can also elaborate that what is the exact difference between these two methods? 😄

Thank you Abhay

tdurieux commented 3 years ago

It looks perfectly fine to me to use the way you described.

ABHAY0O7 commented 3 years ago

Hello @tdurieux @bbaudry I have recently pushed a commit that marks the completion of 95% of the plugin deployment. What's new

Also since I am heading towards the end of this task, I want to end it professionally, so please suggest to me the default task name that I should use for the plugin like in maven we use this long command se.kth.castor:depclean-maven-plugin:2.0.2-SNAPSHOT:depclean, Also when you will be reviewing then I will be glad if you suggest me some changes in the plugin, classes, method or field names.

One more thing, I have not implemented some extra configuration similar to createPomDebloated or createResultJson, the reason behind this is that if we include these parameters in our configuration then the plugin will take lots of time to generate them. See a report here #79, it shows all. So, a developer will rarely like to generate a new debloated file by giving a lot of time, rather than this he will prefer manual removing of debloated dependencies which takes a little bit of time after analyzing the report. I also want your and the community's feedback regarding this.

PR #93 is completely open for review. Please update me soon with some feedback or suggestions. Until then I will continue with some documentation and refactoring.

Thank you Abhay

tdurieux commented 3 years ago

creating the pom should be extremely fast, I don't see a reason why it would be slow, for the JSON, it depends of the size of the project. it can potentially take a lot of time for big projects.

tdurieux commented 3 years ago

Yes please add a parameter for debloat the Gradle build file and one to generate the Json file.

On Jul 10, 2021 07:45, ABHAY SINGH @.***> wrote:

Then for now should I add a parameter for debloated-build.gradle or not? And also for .json?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/castor-software/depclean/issues/92#issuecomment-877573120, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABKRWYCSY7V3OFKLR2SEABTTW7M6VANCNFSM45RS6PPQ.

ABHAY0O7 commented 3 years ago

Hii @tdurieux Sorry for not responsive for the last 4 days, I was a little bit busy in my college vivas and also was trying to configure out how can I implement the createDebloatedBuild parameter. I searched over the internet for how to use model and any Writer object in Gradle to write a new build.gradle file, and sadly I didn't find anything that could help me. But now I have an idea for this which is: We know that the difference between the debloated build.gradle and the existing build.gradle file is only inside the dependencies portion i.e. 

dependencies {
       // project's dependencies
}

So what we can do is that instead of creating a whole new build.gradle file, we can just create a debloated-dependencies.gradle file using BufferedWriter & Reader and if one wants to use it then (s)he can specify this file in its original build.gradle file to apply the project's dependencies.

Example: https://github.com/yoomoney-gradle-plugins/check-dependencies-plugin/blob/d2186b1244d2ffbecf19f2a45ecfe8ff50bd4601/build.gradle#L7

Also, its generation will be very fast as we will be dealing only with the dependencies section of the project. I am not sure that whether this will gonna work, because there are some problems regarding this like, Recently, in Gradle 7.0.0 and above there are some configurations (scopes) removed by Gradle (See here) but when we use the getConfiguration method on any artifact then it may return those removed configurations, so I have to deal with them i.e. mentioning the dependencies in its right configuration.

If I will able to conquer all the problems then this way of creating this parameter will definitely work. Also, I want to know your thoughts about this too. If there are any mistakes or any other way of doing this in a more perfect way then please guide me through it.

Thank you Abhay

ABHAY0O7 commented 3 years ago

Hii @tdurieux @bbaudry, I have now successfully implemented the createBuildDebloated parameter and wrote a proper functional test that ensures its proper working. I used BufferWriter & PrintWriter to write debloated-dependencies.gradle file with some new programming logic, which if anyone wants can directly use from his build.gradle file as I mentioned earlier in the previous comment. Now, you can review it and if there are any problems then let me know. Also after your review, if all goes well, then I want to discuss the remaining parameter and tasks.

Thank you

ABHAY0O7 commented 3 years ago

Hello, @tdurieux @bbaudry, As I am a little bit behind as compare to my timeline, I thought that I should continue. I want to say that, for the last parameter to be implemented, the problem that I am facing is to get the output of the task gradle dependency to a file, but for now there seems to be no method to do that. But, I am trying to find a solution for that and I will also request to you, please help me with this. But if I didn't found any way soon, then I will implement that parameter later(Postpone), and for now, I have to move to my second task.

Waiting for your fast response... Best Abhay

tdurieux commented 3 years ago

What are you trying to achieve with gradle dependency since you already get the list of dependencies programmatically?

ABHAY0O7 commented 3 years ago

What are you trying to achieve with gradle dependency since you already get the list of dependencies programmatically?

I want to generate the complete dependency tree of the project which can be done using the cmd gradle dependencies and also want the result of this task to a file because later It will be used in getting nodes from the tree.

ABHAY0O7 commented 3 years ago

Hello @tdurieux @bbaudry I apologize for this delay in the completion of this task, this week was quite busy for me. I was learning about Github Actions, was giving my end semester exams, and was also finding a correct way to add the test to Github Actions, but since the project is now a multi-build project so, it was quite hard to set up continuous integration to a module instead of project.

But finally, with the help of one of my friends, we found a way to add module tests to CI. But now, when I set up the stable CI, Github actions are failing the tests. 😞 This is because there was a bug in my already written tests, the bug is quite difficult to explain in the comments, but I am finding a way to debug them. So, it will take around 1 more day.

Also, I want to update you that my final semester exams are over (22 - 25) and I am getting a 10 day leave from college, so I will be providing as maximum as possible hours to the project. 😄 👍🏽

Best Abhay

ABHAY0O7 commented 3 years ago

Hii @tdurieux @bbaudry I have successfully debugged the test and they are working fine now. I have also included the Gradle build in the CI, but I excluded the test for now as they are failing on Github actions but they are running successfully on the local system. This is because I implemented functional tests using Gradle runner, which is not supported by Github actions, see here. This is a bug that is still open to be debugged, so we have to wait to add tests to CI until Gradle doesn't get rid of this bug.

You can review the modified tests and workflow files. Thank you

ABHAY0O7 commented 3 years ago

Hii @bbaudry @tdurieux It's been a long time since I made the last PR, but the debugging was very difficult for me this time. As you advised that these files can be very useful sometimes in data analysis, so finally, I found a way to generate a proper JSON and CSV file. 😄 Also, the time in producing these files is not that much which I thought, it is approx one minute. 🚀 I also added a test for the JSON parameter, now you can review the PR (#100) and can merge all the PRs according to their numbers. Also, while merging there may be some merge conflicts, so just ping me if there are any.

Until then I will be carrying on with some more debugging and testing. 😃 Best, Abhay

Amishakumari544 commented 3 years ago

Hello everyone , I am Amisha pursuing Btech in computer Science I am looking to work on this project can anyone tell me how to start ? @ABHAY0O7 can you please guide me?

ABHAY0O7 commented 3 years ago

Hello @tdurieux @bbaudry I hope you are having a nice time. As my first task of creating depclean-gradle-plugin is already completed, so I moved to the second one, and I had implemented support for multi-module-analysis. It is not so perfect but still, it will prevent the failure of building the project. What I have implemented :

  1. Suppose this maven-based java project to be the targeted one (link), it has three modules in which module-3 depends on module-2.
  2. Now the thing is that the dependencies commons-codec:commons-codec:1.15 & com.jcabi:jcabi-manifests:1.1 are declared in module-2 but are not used in module-2, so depclean (old version) report these dependencies bloated.
  3. But in module module-3 which depends on module-2 uses its dependencies commons-codec:commons-codec:1.15 & com.jcabi:jcabi-manifests:1.1 and the depclean (old version) will report these two dependencies as debloated.
  4. See this whole report generated by depclean for this project. 
    
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO] 
[INFO] abhayPlugin                                                        [pom]
[INFO] abhay-module-1                                                     [jar]
[INFO] abhay-module-2                                                     [jar]
[INFO] abhay-module-3                                                     [jar]
[INFO] 
[INFO] -----------------------< org.abhay:abhayPlugin >------------------------
[INFO] Building abhayPlugin 1.0-SNAPSHOT                                  [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO] 
[INFO] --- depclean-maven-plugin:2.0.2-SNAPSHOT:depclean (default-cli) @ abhayPlugin ---
-------------------------------------------------------
[INFO] Starting DepClean dependency analysis
[INFO] Skipping because packaging type pom.
[INFO] 
[INFO] ----------------------< org.abhay:abhay-module-1 >----------------------
[INFO] Building abhay-module-1 1.0-SNAPSHOT                               [2/4]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- depclean-maven-plugin:2.0.2-SNAPSHOT:depclean (default-cli) @ abhay-module-1 ---
-------------------------------------------------------
[INFO] Starting DepClean dependency analysis
[WARNING] Dependencies were not copied locally
-------------------------------------------------------
D E P C L E A N   A N A L Y S I S   R E S U L T S
-------------------------------------------------------
USED DIRECT DEPENDENCIES [0]: 
USED INHERITED DEPENDENCIES [0]: 
USED TRANSITIVE DEPENDENCIES [0]: 
POTENTIALLY UNUSED DIRECT DEPENDENCIES [0]: 
POTENTIALLY UNUSED INHERITED DEPENDENCIES [0]: 
POTENTIALLY UNUSED TRANSITIVE DEPENDENCIES [0]: 
[INFO] 
[INFO] ----------------------< org.abhay:abhay-module-2 >----------------------
[INFO] Building abhay-module-2 1.0-SNAPSHOT                               [3/4]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- depclean-maven-plugin:2.0.2-SNAPSHOT:depclean (default-cli) @ abhay-module-2 ---
-------------------------------------------------------
[INFO] Starting DepClean dependency analysis
[WARNING] Dependencies were not copied locally
-------------------------------------------------------
D E P C L E A N   A N A L Y S I S   R E S U L T S
-------------------------------------------------------
USED DIRECT DEPENDENCIES [1]: 
com.fasterxml.jackson.core:jackson-core:2.12.2:compile (size unknown)
USED INHERITED DEPENDENCIES [0]: 
USED TRANSITIVE DEPENDENCIES [0]: 
POTENTIALLY UNUSED DIRECT DEPENDENCIES [3]: 
commons-codec:commons-codec:1.15:compile (size unknown)
com.jcabi:jcabi-manifests:1.1:compile (size unknown)
commons-io:commons-io:2.8.0:compile (size unknown)
POTENTIALLY UNUSED INHERITED DEPENDENCIES [0]: 
POTENTIALLY UNUSED TRANSITIVE DEPENDENCIES [2]: 
org.slf4j:slf4j-api:1.7.5:compile (size unknown)
com.jcabi:jcabi-log:0.14:compile (size unknown)
[INFO] 
[INFO] ----------------------< org.abhay:abhay-module-3 >----------------------
[INFO] Building abhay-module-3 1.0-SNAPSHOT                               [4/4]
[INFO] --------------------------------[ jar ]---------------------------------
[WARNING] Could not transfer metadata org.abhay:abhay-module-2:1.0-SNAPSHOT/maven-metadata.xml from/to example-repo (C:\Users\ABHAY SINGH/.m2/repository): Cannot access C:\Users\ABHAY SINGH/.m2/repository with type default using the available connector factories: BasicRepositoryConnectorFactory
[WARNING] Failure to transfer org.abhay:abhay-module-2:1.0-SNAPSHOT/maven-metadata.xml from C:\Users\ABHAY SINGH/.m2/repository was cached in the local repository, resolution will not be reattempted until the update interval of example-repo has elapsed or updates are forced. Original error: Could not transfer metadata org.abhay:abhay-module-2:1.0-SNAPSHOT/maven-metadata.xml from/to example-repo (C:\Users\ABHAY SINGH/.m2/repository): Cannot access C:\Users\ABHAY SINGH/.m2/repository with type default using the available connector factories: BasicRepositoryConnectorFactory
[INFO] 
[INFO] --- depclean-maven-plugin:2.0.2-SNAPSHOT:depclean (default-cli) @ abhay-module-3 ---
-------------------------------------------------------
[INFO] Starting DepClean dependency analysis
[WARNING] Dependencies were not copied locally
-------------------------------------------------------
D E P C L E A N   A N A L Y S I S   R E S U L T S
-------------------------------------------------------
USED DIRECT DEPENDENCIES [1]: 
org.abhay:abhay-module-2:1.0-SNAPSHOT:compile (size unknown)
USED INHERITED DEPENDENCIES [0]: 
USED TRANSITIVE DEPENDENCIES [3]: 
commons-codec:commons-codec:1.15:compile (size unknown)
com.fasterxml.jackson.core:jackson-core:2.12.2:compile (size unknown)
com.jcabi:jcabi-manifests:1.1:compile (size unknown)
POTENTIALLY UNUSED DIRECT DEPENDENCIES [0]: 
POTENTIALLY UNUSED INHERITED DEPENDENCIES [0]: 
POTENTIALLY UNUSED TRANSITIVE DEPENDENCIES [3]: 
org.slf4j:slf4j-api:1.7.5:compile (size unknown)
com.jcabi:jcabi-log:0.14:compile (size unknown)
commons-io:commons-io:2.8.0:compile (size unknown)
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for abhayPlugin 1.0-SNAPSHOT:
[INFO] 
[INFO] abhayPlugin ........................................ SUCCESS [  0.878 s]
[INFO] abhay-module-1 ..................................... SUCCESS [  1.306 s]
[INFO] abhay-module-2 ..................................... SUCCESS [  1.285 s]
[INFO] abhay-module-3 ..................................... SUCCESS [  1.249 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  4.841 s
[INFO] Finished at: 2021-08-12T17:17:08+05:30
[INFO] ------------------------------------------------------------------------
5. Now what will happen, after seeing that the dependencies  `commons-codec:commons-codec:1.15` & `com.jcabi:jcabi-manifests:1.1` are not used in module-2, so he will remove them from it which will result in project builds failure as module-3 which requires these two dependencies, will not find these dependencies in module-2.
6. So, I propose (implemented) an extra section for these kinds of dependencies whose debloat status depends on other modules.  Look in this report, how I implemented that.
7. Depclean report (new version)
```java
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO] 
[INFO] abhayPlugin                                                        [pom]
[INFO] abhay-module-1                                                     [jar]
[INFO] abhay-module-2                                                     [jar]
[INFO] abhay-module-3                                                     [jar]
[INFO] 
[INFO] -----------------------< org.abhay:abhayPlugin >------------------------
[INFO] Building abhayPlugin 1.0-SNAPSHOT                                  [1/4]
[INFO] --------------------------------[ pom ]---------------------------------
[INFO] 
[INFO] --- depclean-maven-plugin:2.0.2-SNAPSHOT:depclean (default-cli) @ abhayPlugin ---
-------------------------------------------------------
[INFO] Starting DepClean dependency analysis
[INFO] Skipping because packaging type pom.
[INFO] 
[INFO] ----------------------< org.abhay:abhay-module-1 >----------------------
[INFO] Building abhay-module-1 1.0-SNAPSHOT                               [2/4]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- depclean-maven-plugin:2.0.2-SNAPSHOT:depclean (default-cli) @ abhay-module-1 ---
-------------------------------------------------------
[INFO] Starting DepClean dependency analysis
[WARNING] Dependencies were not copied locally
-------------------------------------------------------
 D E P C L E A N   A N A L Y S I S   R E S U L T S
-------------------------------------------------------
USED DIRECT DEPENDENCIES [0]: 
USED INHERITED DEPENDENCIES [0]: 
USED TRANSITIVE DEPENDENCIES [0]: 
POTENTIALLY UNUSED DIRECT DEPENDENCIES [0]: 
POTENTIALLY UNUSED INHERITED DEPENDENCIES [0]: 
POTENTIALLY UNUSED TRANSITIVE DEPENDENCIES [0]: 
[INFO] 
[INFO] ----------------------< org.abhay:abhay-module-2 >----------------------
[INFO] Building abhay-module-2 1.0-SNAPSHOT                               [3/4]
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- depclean-maven-plugin:2.0.2-SNAPSHOT:depclean (default-cli) @ abhay-module-2 ---
-------------------------------------------------------
[INFO] Starting DepClean dependency analysis
[WARNING] Dependencies were not copied locally
-------------------------------------------------------
 D E P C L E A N   A N A L Y S I S   R E S U L T S
-------------------------------------------------------
USED DIRECT DEPENDENCIES [1]: 
    com.fasterxml.jackson.core:jackson-core:2.12.2:compile (size unknown)
USED INHERITED DEPENDENCIES [0]: 
USED TRANSITIVE DEPENDENCIES [0]: 
POTENTIALLY UNUSED DIRECT DEPENDENCIES [3]: 
    commons-codec:commons-codec:1.15:compile (size unknown)
    com.jcabi:jcabi-manifests:1.1:compile (size unknown)
    commons-io:commons-io:2.8.0:compile (size unknown)
POTENTIALLY UNUSED INHERITED DEPENDENCIES [0]: 
POTENTIALLY UNUSED TRANSITIVE DEPENDENCIES [2]: 
    org.slf4j:slf4j-api:1.7.5:compile (size unknown)
    com.jcabi:jcabi-log:0.14:compile (size unknown)
[INFO] 
[INFO] ----------------------< org.abhay:abhay-module-3 >----------------------
[INFO] Building abhay-module-3 1.0-SNAPSHOT                               [4/4]
[INFO] --------------------------------[ jar ]---------------------------------
[WARNING] Could not transfer metadata org.abhay:abhay-module-2:1.0-SNAPSHOT/maven-metadata.xml from/to example-repo (C:\Users\ABHAY SINGH/.m2/repository): Cannot access C:\Users\ABHAY SINGH/.m2/repository with type default using the available connector factories: BasicRepositoryConnectorFactory
[WARNING] Failure to transfer org.abhay:abhay-module-2:1.0-SNAPSHOT/maven-metadata.xml from C:\Users\ABHAY SINGH/.m2/repository was cached in the local repository, resolution will not be reattempted until the update interval of example-repo has elapsed or updates are forced. Original error: Could not transfer metadata org.abhay:abhay-module-2:1.0-SNAPSHOT/maven-metadata.xml from/to example-repo (C:\Users\ABHAY SINGH/.m2/repository): Cannot access C:\Users\ABHAY SINGH/.m2/repository with type default using the available connector factories: BasicRepositoryConnectorFactory
[INFO] 
[INFO] --- depclean-maven-plugin:2.0.2-SNAPSHOT:depclean (default-cli) @ abhay-module-3 ---
-------------------------------------------------------
[INFO] Starting DepClean dependency analysis
[WARNING] Dependencies were not copied locally
-------------------------------------------------------
 D E P C L E A N   A N A L Y S I S   R E S U L T S
-------------------------------------------------------
USED DIRECT DEPENDENCIES [1]: 
    org.abhay:abhay-module-2:1.0-SNAPSHOT:compile (size unknown)
USED INHERITED DEPENDENCIES [0]: 
USED TRANSITIVE DEPENDENCIES [3]: 
    commons-codec:commons-codec:1.15:compile (size unknown)
    com.fasterxml.jackson.core:jackson-core:2.12.2:compile (size unknown)
    com.jcabi:jcabi-manifests:1.1:compile (size unknown)
POTENTIALLY UNUSED DIRECT DEPENDENCIES [0]: 
POTENTIALLY UNUSED INHERITED DEPENDENCIES [0]: 
POTENTIALLY UNUSED TRANSITIVE DEPENDENCIES [3]: 
    org.slf4j:slf4j-api:1.7.5:compile (size unknown)
    com.jcabi:jcabi-log:0.14:compile (size unknown)
    commons-io:commons-io:2.8.0:compile (size unknown)

-------------------------------------------------------
[INFO] DEPENDENT MODULES FOUND
Due to dependent modules, the debloated result of some dependencies from previous modules has been changed now.
The dependency-module details of such dependencies with the new results are as follows :

    1) ModuleCoordinates : org.abhay:abhay-module-2:1.0-SNAPSHOT
       DependencyCoordinates : com.jcabi:jcabi-manifests:1.1:compile
       OldType : unusedDirect
       NewType : usedDirect

    2) ModuleCoordinates : org.abhay:abhay-module-2:1.0-SNAPSHOT
       DependencyCoordinates : commons-codec:commons-codec:1.15:compile
       OldType : unusedDirect
       NewType : usedDirect

-------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for abhayPlugin 1.0-SNAPSHOT:
[INFO] 
[INFO] abhayPlugin ........................................ SUCCESS [  0.878 s]
[INFO] abhay-module-1 ..................................... SUCCESS [  1.306 s]
[INFO] abhay-module-2 ..................................... SUCCESS [  1.285 s]
[INFO] abhay-module-3 ..................................... SUCCESS [  1.249 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  4.841 s
[INFO] Finished at: 2021-08-12T17:17:08+05:30
[INFO] ------------------------------------------------------------------------
  1. Now, in the new feature, after the analysis of module-3 there is an extra section for dependencies whose debloated status has been changed. This will tell the user, not to exclude these dependencies from their respective pom.xml, which will prevent build failures.
  2. This feature does not analyze the bulk of data to generate a report (maybe a better way), but it serves the purpose which was required.

The implementation of the above feature is here #101. You can review it and provide me the feedback as soon as possible.

Thank you

tdurieux commented 3 years ago

Nice idea. Do you think it is possible to add a summary report at the end of the built of the three modules? And this summary could also contain the information from (DEPENDENT MODULES FOUND)

ABHAY0O7 commented 3 years ago

Do you think it is possible to add a summary report at the end of the built of the three modules?

Sorry to say, but to my knowledge, this is not possible and actually, this was the whole problem for me, just think, if I have a way of adding the summary report at the end of the build, then instead of the summary report, I will prefer the bulk analysis of the result of all modules generated by depclean and then the problem of multi-module analysis would never arrive, but the things didn't work this way. I had already spent a lot of time researching this.

How do they work? The mojo considers every module as an individual project, so whatever we write inside the execute() method, will be executed by every module in the order provided by the maven reactor. So, we can collect the data from every module and can manipulate it at the end of every module which I already did here #101, but not at the end of the whole project. 😢

Also, I think the only solution to it is inside the maven reactor codebase because the work performed by the reactor can only be possible by the bulk analysis of modules, not individual analysis. Unfortunately, I didn't find the codebase and logic behind the working of the maven reactor, but I am researching this, and maybe in the future I will be able to implement this summary report too. 😄

Until then I will try to add some new tests. 👨🏽‍💻

Thank you Abhay

ABHAY0O7 commented 3 years ago

Hello everyone, I am Amisha pursuing Btech in Computer Science I am looking to work on this project can anyone tell me how to start? @ABHAY0O7 can you please guide me?

And if you don't mind, please answer her too. And If you are busy, then provide me this wonderful opportunity of guiding new contributors. 😃

ABHAY0O7 commented 3 years ago

Hello @tdurieux @bbaudry Since today is the last day of the GSoC coding period, I want you to review and merge all of my pending PRs so that I can include them in my final report. Also, if possible I will be sending more PRs of some new tests or updates in README, so please try to review and merge them too before the deadline. 😅

Thank you Abhay

Amishakumari544 commented 3 years ago

Hello everyone, I am Amisha pursuing Btech in Computer Science I am looking to work on this project can anyone tell me how to start? @ABHAY0O7 can you please guide me?

And if you don't mind, please answer her too. And If you are busy, then provide me this wonderful opportunity of guiding new contributors. 😃

Hello @tdurieux @bbaudry Since today is the last day of the GSoC coding period, I want you to review and merge all of my pending PRs so that I can include them in my final report. Also, if possible I will be sending more PRs of some new tests or updates in README, so please try to review and merge them too before the deadline. 😅

Thank you Abhay

It would be great if you help me .

tdurieux commented 3 years ago

Hello @tdurieux @bbaudry Since today is the last day of the GSoC coding period, I want you to review and merge all of my pending PRs so that I can include them in my final report. Also, if possible I will be sending more PRs of some new tests or updates in README, so please try to review and merge them too before the deadline. 😅

Thank you Abhay

Sorry @ABHAY0O7, I was on holiday without my laptop. I am reviewing and merging your PRs.

ABHAY0O7 commented 3 years ago

It would be great if you help me.

Hello @Amishakumari544, Sorry for the delay, The project is written completely in Java, and if you know it then you can start by adding java-docs, refactoring, readme update, or maybe some new tests. Make sure to visit here : A Comprehensive Study of Bloated Dependencies in the Maven Ecosystem. Try to understand the project first, then it will be easier to contribute. You can refer to these links for information about Gradle & Maven plugins. Maven-api Gradle-api