javagl / dependencycleaner Goto Github PK

Right now, the tool offers the option to drag-and-drop a pom.xml and figure out its dependencies. (These are passed as a list of https://github.com/javagl/DependencyCleaner/blob/master/src/main/java/de/javagl/dependencycleaner/ArtifactInfo.java objects to the downstream dependency resolution etc).

There should be some more flexibility in that. Particularly, there should also be the option to scan the local .m2 directory for broken JARs. Maybe one could also add some filter or search functionality for that (e.g. "Seach for JARs that have groupID de.javagl"), or allow scanning only subdirectories. (The .m2 folder can be huge ...)

Are there other options that should be considered?

(Probably, at some point, one might even want to configure local repos, or even extract them from some POM. That would be a second step, but should be kept in mind)

Hello can you add me as a collaborator , would like to contribute :)

Currently, the detection whether a file is "invalid" is solely done by creating a new JarFile object. For totally broken files, this already throws an exception and thus they are detected.

But there may be files where the famous "Invalid LOC header" message appears, and this seems only to appear when trying to access the classes in the JAR.

The detection of whether a JAR is "invalid" should therefore at least iterate over all entries of the JAR/ZIP file, to see whether they can be accessed.

The current, initial implementation was a first shot to get the basic functionality integrated and working. The result can be considered as a standalone tool that may be useful for someone.

For further development, the basic structure should be cleaned up a little. A first step here would be to more cleanly define the "data model" that the dependency cleaner operates on. Currently, this is mostly summarized in the https://github.com/javagl/DependencyCleaner/blob/master/src/main/java/de/javagl/dependencycleaner/DependencyStatus.java and https://github.com/javagl/DependencyCleaner/blob/master/src/main/java/de/javagl/dependencycleaner/DependencyTreeNode.java classes. These classes mainly serve the purpose of decoupling layer between the dependency cleaner and the Eclipse Aether classes that are used internally for the dependency resolution. The first refactoring would be to pull out the current "model" classes into an own package (and probably convert them into interfaces - this is something that I do basically "by default"), and maybe extend them with some basic MVC support (i.e. the option to add Listeners to be informed about state changes - right now, this is handled in the UI...).

The UI was written quickly and pragmatically. I think it does make sense to present the information in a TreeTable, but maybe other presentations (maybe even based on a different UI toolkit) should be considered. So the UI classes could be pulled into a ui.swing package.

Although this will not imply many changes from a conceptual point of view, classes will be moved around and renamed, so it should be done as one, coordinated refactoring step.