[BUG] Web.xml filters not kept as dependencies

[afillatre]

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

[patbaumgartner]

Adding this feature to depclean would be nice. In general, it would be great to parse any XML files for patterns that look like an import statement. We still have some legacy apps which use XML config files. But I assume other frameworks would work the same.

[afillatre]

@cesarsotovalero since there can be many cases where we need to parse XML files (or even other text file formats), what do you think about adding a configuration to the plugin to provide the list of extra files to parse ? I think this should be better than trying to read everything we find, either by brute force or hard-coded patterns.

For instance, I can think of Spring beans declared in XML files that do not need to be named xxx-beans.xml, which would be hard to locate otherwise.

[cesarsotovalero]

Hi @afillatre,
I get your point. So we can definitely add a parameter to DepClean to let the users declare a path to the XML files where they have this type of dependencies.
I'll give it a try this way.

Can you point me to some open source Spring project that relies on this form of dependency usage for so that I can use it for testing purposes?

[afillatre]

I can too work on this if you need. You just tell me :)
Since the ActualUsedClasses filters its input (it's only keeps the classes it knows from the initial dependency parsing), you can send almost anything you find in the XML files. So any XML file would be fine to test it (no need to understand how a Spring file is constructed, for instance)