[closure-compiler-maven-plugin] enable --@define compiler command line option

[lukas-vlcek]

It would be very useful to allow to specify compiler options like --@define and possibly others.

I would like to use it for things like integration with WTF (Web Tracing Framework) where it allows to use --@define=WFT.ENABLED=false to strip out WFT related code in advanced compilation mode. (See For Closure Compiler Users chapter)

If I understand correctly it means define values need to be propagated to JsClosureCompileMojo#compile() method and add something like compilerOptions.setDefineToBooleanLiteral(String defineName, boolean value). To make it more general would of course require more work.

So may be extending compiler pom definition along the lines like this:

 <plugin>
     <groupId>com.github.jlgrock.javascript-framework</groupId>
     <artifactId>closure-compiler-maven-plugin</artifactId>
     <version>${jsframework.version}</version>
     <configuration>
         <defines>
             <define>
                <defineName>goog.DEBUG</defineName>
                <value>false</value>
                <valueType>boolean</valueType>
             </define>
             <define>
                <defineName>WFT.ENABLED</defineName>
                <value>false</value>
                <valueType>boolean</valueType>
             </define>
         </defines>
     </configuration>
 </plugin>

valueType possible values: boolean, double, string, integer

@jlgrock I am not an Mojo and maven plugin expert. Do you think this would be possible? Or can you think of better way of doing this? I am willing to try to implement it and send PR but your comments and ideas can help me a lot.

[jlgrock]

Actually, i don't think there is a better way to do this. Actually, this is pretty interesting. This falls into the crap that they don't document. There's so much of it, it kills me. As far as the Mojo work, I think you have the grasp of the injection code, and that's pretty much the hardest part.

Anyways, I did a refactor so that we had some better logical separation and fixed some of your code quality issues. The code quality is set pretty crazy high on this project, regarding documentation and funny java quirks. I'm not going to lie, after using this for a while, it's the reason I started looking at other languages (Groovy, Scala, JRuby) that had less quirks (at least less that required me to keep doing mind numbing tasks). When I pulled your code down, it didn't compile because of the checkstyle errors. Did you get to test it?

As I mentioned in the pull request, I tested it using the test project. I'll make sure to check that in.

[lukas-vlcek]

Yes, you are right about the checkstyle, it was failing for me and I silently commented the plugin out during testing on my side :smile:. I wanted to look at it later after we sort out the basic idea of this PR. Anyway, thanks for looking at this [checkstyle] issue.

I added two more commits into PR. Feel free to look at them and update as needed.

That would be probably it... I like how the code is right now and I am looking forward to the next release to use the new functionality. Though, do not hesitate to let me know if there is anything I can help you with.

[jlgrock]

Looks good, and I'll drop out a release today. Thanks for the help Lukas!