Nested archive analysis at component level

[twogee]

I work on a project where we needed to analyze nested archives on a jar level (and even try to divide WEB-INF/classes in separate "bundles").

This helped to uncover errors in build rules and componentize WEB-INF/classes (by showing circular dependencies).

Would that be of general interest? I can describe the implementation in more detail, then.

[jesper.pedersen]

WEB-INF/classes should be considered as an archive, and the WarArchive should have special integration.

Feel free to describe your design in more detail, and possible link a PoC implementation.

[twogee]

Currently, WarScanner/EarScanner contain a bunch of SortedMaps for all kinds of dependencies extracted from .class files.

My idea was to encapsulate them in ClassScanner, so that I could have a bunch of those, one for a package or a group of packages.

WarScanner/EarScanner would then have a HashMap for keeping ClassScanner's, with a package name as a key.

Finally, the contents of ClassScanner's could be stored into a ClassesArchive (as it is done now) or a bunch of JarArchive's.

Why? Because different Report's are currently written so that they analyze dependencies etc between JarArchive's and treat ClassesArchive as a placeholder that is explicitly excluded from further analysis.

See https://github.com/twogee/tattletale/tree/master/src/main/java/org/jboss/tattletale/analyzers

The last of the changes is in Main, where a list of Archive's is created for further analysis in Report's. All NestableArchive's are substituted by their subarchive lists.

[jesper.pedersen]

The code can benefit from a refactoring for sure. And a quick look at your changes shows that you are on the right path. Let me know when this pull request is ready for in-depth review.

[twogee]

I am done with that change (although it is spread across several commits).

[jesper.pedersen]

One PR with all commits squashed.