Remove some hardcoding of specifics so Checkstyle can be more Extensible

[rnveach]

I am tired of Checkstyle limiting itself to mainly Java files. I am looking for checkstyle to support more different type of unique files (XML, Properties, etc..) by extending it at https://github.com/rnveach/checkstyle-extras .

In the process of setting this process up and starting it, it started to become apparent how limited Checkstyle was making itself. Configuration isn't really the issue, as it already supports 3rd party classes. It doesn't mind if a new walker or such is being added. But there are specific other, more newer additions, that is hindering the process and causing conflicts or extra code duplication.

The following (so far) is a list I have identified and looking to have loosen up so Checkstyle can support more.

• Checkstyle's copyright on Java only support. ( Update Checkstyle's Copyright #11596 )
• Tests only know Checker or TreeWalker and need some minor re-working to be able to override for newer "walkers ( Some reworking for test structures #11603 )
• Sub-modules of a module are not really supported, even though some areas are coded to provide this support ( Allow 3rd party Check providers to group modules under custom parent module #11644 )
• ASTs have no generic interface and implmentation that we have to duplicate utility code between our different types of nodes
  • Creating a interface between all ASTs to start a synchronization process of common methods ( Issue #11604: separates detail ast from xpath #11617 )
  • Add methods like getting type, line and column number, iterating through children, etc.
  • Create a commonality for AstTreeStringPrinter and possibly out Walker modules .
• Suppressions is oddly coded for Checker or TreeWalker and has no idea of flexibility like configurations do.
  • This lead to Remove Experimental from XPath Filter #11597 .
• XPath is very TreeWalker specific and not flexible for other nodes
  • Utility class is very strict when it doesn't need to be ( minor: removes checkstyle specific class in ReverseListIterator #11598 )
  • XPath will be split between AST specific and generic classes ( Issue #11604: separates detail ast from xpath #11617 )
• After all this, common functionality should be abstracted out, to separate core functionality and walker specific functionality. This includes walkers, checks, xpath nodes, events, etc....
• Add documentation showing areas of Checkstyle that is now more open to 3rd parties
  • How 3rd parties can make their own sub-modules and walkers

I am looking for these areas to change, not functionally, but in a way that makes way for extensibility by either Checkstyle itself or 3rd parties.

[romani]

I have worries to become a base library for some other tools/project. They will force us to have too abstract model extend our contract with others.

I would rather let all that tools be less dependent on us and be able to resolve their problems without forcing us to extend API.

I ok with some changes, but let's not think that we need to be friendly to others. We will break all contracts and move in direction that we need.

Our history shows us that we do not have time to think and work on our API strategy :( .