Anyone think it realistically breaks something for someone if we remove those main methods and mini CLI utilities from freemarker.jar?
I try to bring the artifact into a state that's not being flagged at security-conscious companies, and this is one of the potential annoyances. And really, why does a "Java library" dependency have those? Specifically, these are the ones we might should remove: - - freemarker.core.CommandLine: It just prints the version number. Of course freemarker.jar!/META-INF/MANIFEST.MF also has that. - freemarker.core.ASTPrinter: Prints the AST of a template... - freemarker.ext.dom.Transform: Command line to run a template with the single specified XML document exposed. Output is written into the specified file or to stdout. Internally uses freemarker.ext.dom.NodeModel#parse(org.xml.sax.InputSource, boolean, boolean), which doesn't protect against XML External Entity (XXE) attacks. Ouch! Also, I guess it's too simplistic for real-world use, and once you need a bit more, it's quite easy to replace with custom code (it's a 200 line class). - freemarker.ext.jdom.NodeListModel (our long deprecated legacy XML wrapper), which have a main method: Similar to freemarker.ext.dom.Transform, but even more minimalistic. Certainly it's also open to XXE attacks. - freemarker.template.utility.ToCanonical: Small utility where you pass in a list of FTL files as command-line arguments, and it outputs similar files in canonical form with ".canonical" appended after the file name. I highly doubt people use this. All the others are in test code (not in FreeMarker jar), so they don't matter.
