Sorry, this is a rant.
I was recently investigating Maven plugins for LESS compilation. The use-case is pretty run-of-the-mill (I think?): I want to be able to write a .less file anywhere in my project src/ folder and have Maven compile it to CSS in the corresponding folder in target/ at some point of the build pipeline.
I first looked into lesscss-maven-plugin, a short-and-sweet kind of tool that looks perfect if you have one (and *only one*) target folder for all of your CSS. Working on a large project including things such as separate templates and per-plugin CSS, this would not be working for us.
More reading and research lead me to Wro4j, Web Resources Optimization for Java. One understood the cryptic acronym, it sounds like the kind of all-encompassing tool that the Gods of Bandwidth and Simplicity would bestow upon us mere mortals provided we made the required server sacrifices. A noble idea, but after actually using the thing, it didn’t take me long to drop the religious metaphor.
Wro4j is a horrible mess. There’s absolutely no justification in any way, shape or form for the complexity involved in this plugin. As a perfect example of being too clever for its own good, Wro4j includes several parsers for the configuration file: an XML parser, a JSON parser, and for some reason a Groovy parser. Why you would need three different ways to configure a poor Maven plugin âwhich should get its configuration from the pom.xml anywayâ is beyond me.
And the implementation is the most horrific part: when supplied with a config file, Wro4j will try all successive parsers (yes, even when the file extension is .xml(1)) on the file and end up with this absolutely undecipherable error message if parsing failed with each ‘Factory’. Which will happen when Wro4j doesn’t like your XML configuration file for some reason.
I ended up using a bash script to find .less files and call lessc on them. No it’s not portable, no it’s not “the maven way”, but at least it works and it’s maintainable.
1: it takes a special kind of crazy YAGNI-oblivious Java helicopter architect to consider that a Groovy file saved as ‘config.json’ should be a supported feature. In a Maven (which is so heavily XML-based) plugin of all places!
I don’t blame you for this rant, since it contains some useful feedback which can be used to improve a tool. I would have appreciated it more, if this kind of inconveniences would have been reported as issues or comments on mailing list. But this is how things works…. some uses prefer ranting before asking.
Anyway, taking your ranting step by step and answering to your criticism:
1) “Wro4j is a horrible mess. Thereâs absolutely no justification in any way, shape or form for the complexity involved in this plugin”
How hard can it be to follow 3 simple steps: http://alexo.github.io/wro4j/ and switching from runtime solution to build time without a single code change?
2) “As a perfect example of being too clever for its own good, Wro4j includes several parsers for the configuration file: an XML parser, a JSON parser, and for some reason a Groovy parser.”
For the same reason there are users ranting that they don’t like “XML hell”, but prefer JSON, or groovy, or God knows what other DSL. It is completely configurable what DSL you need to build a model. If you don’t like XML, use groovy. If you don’t like groovy or JSON, just build your own.
Indeed, all this configuration flexibility comes with cost. Cost of trying to understand or at least read provided documentation.
3) “And the implementation is the most horrific part: when supplied with a config file, Wro4j will try all successive parsers (yes, even when the file extension is .xml(1))”
This flow or reading DSL model is the default one, since it allows easily to switch from one DSL to another without any code change. It is documented here: https://code.google.com/p/wro4j/wiki/SmartWroModelFactory
And guess what: it is configurable. If you don’t like it, replace it with XML DSL only or your custom one.
4) “… end up with this absolutely undecipherable error message if parsing failed with each âFactoryâ. Which will happen when Wro4j doesnât like your XML configuration file for some reason.”
Could you provide the example of how absolutely undecipherable error doesn’t help you to understand the reason of the problem? If your criticism is valid, I will create an issue and will improve this message for next release.
You are not the first one and not the last one who prefer ranting to constructive criticism, there is no way to satisfy everybody.
I don’t blame you that you prefer to build your own tool which solves your particular use-case. After all, using an existing completely free and open source tool is completely optional.