jlgrock / closurejavascriptframework Goto Github PK

Currently used version of selenium is dated. We need to upgrade to new version which has a lot better support of CORS.

I am hitting a use case where I want to call external http rest service from the integration test. This service is started as a part of integration test and runs on localhost. Currently, when I do something like this:

var xhr = new goog.net.XhrManager();
xhr.send(
    "id",
    "http://localhost:9200",
    undefined,
    undefined,
    undefined,
    undefined,
    function(event) {
        assertNotNull(event);
    }
);

I get:

[ERROR] (StrictErrorReporter.java:79) runtimeError: message=[Access to restricted URI denied] sourceName=[file:/.../target/javascriptFramework/closure-library/closure/goog//net/xhrio.js] line=[481] lineSource=[null] lineOffset=[0]

It turns out that this is problem of HtmlUnit version 2.9 (which is used by selenium 2.24.1) as it does not support CORS. Better CORS support is available in HtmlUnit version 2.11 and higher. See HtmlUnit changes report.

I do not think it is possible to easily skip JavaScript tests now. What exactly needs to be done (implemented) in order to enable skipping tests via -DskipTests option?

Is this result of copy and paste?

https://github.com/jlgrock/ClosureJavascriptFramework/blob/master/closure-compiler-maven-plugin/src/main/java/com/github/jlgrock/javascriptframework/closurecompiler/JsClosureCompileMojo.java#L220

It is identical to https://github.com/jlgrock/ClosureJavascriptFramework/blob/master/closure-compiler-maven-plugin/src/main/java/com/github/jlgrock/javascriptframework/closurecompiler/JsClosureCompileMojo.java#L228

I think I found one issue related to #50
-DskipTests seems to work as expected if it is set on the command line but it does not seem to work if it is configured in the profile section like this:

<profile>
        <id>skipTest_profile</id>
        <properties>
            <skipTests>true</skipTests>
        </properties>
        <build> [...] </build>
</profile>

I think such use case is pretty rare but may be there are other more common ways how to hit it or this might be a symptom of something more serious.

If including (using the war include) multiple versions of the same file, it's going to have a classpath conflict and overwrite the other version of the library. Although the output (compiled) versions will come through just fine, the debug files will overwrite one another. Which means it is a guess as to which is actually being used in the debugSource directory.

In v1.18.1 we use closure compiler version v20131014 by default. There has been several releases since then (see https://github.com/google/closure-compiler/wiki/Releases). We should consider upgrading the closure compiler and start plan for a new release (v1.18.2?) that will be using it by default.

I have two projects, A & B, B has a dependency on A. Both of them have an external dependency of C (lets say jquery for example).

I put in the jquery extern file in both of the project’s /externs directory.

When compiling, A compiles fine.

Then B compiles. It brings in it’s own jquery extern file, project A, and project A’s extern file. This causes B to fail since there are two externs both declaring the same thing.

Is there any way how to configure fain grained levels of warnings? See https://github.com/google/closure-compiler/wiki/Warnings

For example I have run into issue where in the source code of closure-library are mismatched JSDocs parameter types in one file and by default the STRICT errorLevel results into terminated compilation due to this. Is there any way how to say: "OK, just try to use options.setWarningLevel(DiagnosticGroups.CHECK_TYPES, CheckLevel.WARNING) but keep the rest of the levels unchanged"?

When adding other JSAR maven projects, if you have an externDependencies folder, it will create a never-ending nesting of this folder unto itself. Not sure where this is in the code, but no one is currently doing much with externDependencies, thankfully. Please let me know if anyone is using them and I'll look into it sooner.

Probably not a common situation but still might be a symptom of small issue, I have a maven project with several modules, one of them is of type war and its folder is completely empty (no src folder, just the pom.xml file) and it depends on other modules which is of type jsar. When building the parent project I get:

[ERROR] Failed to execute goal com.github.jlgrock.javascript-framework:jsar-maven-plugin:1.18.2:war-move (default-war-move) on project essential: Unable to move files to war archive directory: java.io.IOException: Directory at location "/Users/lukas/projects/lukas-vlcek/bigdesk-3ng/essential/target/javascriptFramework/output/assertionSource" does not exist. -> [Help 1]

Hi,

I think there is a chance to upgrade compiler, see http://code.google.com/p/closure-compiler/wiki/Releases for the most recent version.

Is any upgrade to the road map soon?

Regards,
Lukas

INFO Generating Test Suite
INFO Calculating File Set
ERROR -1
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:371)
at java.util.ArrayList.get(ArrayList.java:384)
at com.github.jlgrock.javascriptframework.closuretesting.resultparsing.testingcomponents.TestCase.addToLastTestFailureStatistic(TestCase.java:284)
at com.github.jlgrock.javascriptframework.closuretesting.resultparsing.parsers.TestCaseParser.setDivProperty(TestCaseParser.java:108)
at com.github.jlgrock.javascriptframework.closuretesting.resultparsing.parsers.TestCaseParser.parse(TestCaseParser.java:52)
at com.github.jlgrock.javascriptframework.closuretesting.resultparsing.ParseRunner.parseFiles(ParseRunner.java:99)
at com.github.jlgrock.javascriptframework.closuretesting.ClosureTestingMojo.parseFiles(ClosureTestingMojo.java:206)
at com.github.jlgrock.javascriptframework.closuretesting.ClosureTestingMojo.execute(ClosureTestingMojo.java:53)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)

From David - async testing results:

Normal Passing test: http://pastie.org/3935756

Normal Failing test http://pastie.org/3935765

Passing inline test, Failing async test http://pastie.org/3935750

Passing async test, failing inline test http://pastie.org/3935730

Failing async, failing inline http://pastie.org/3935775

Currently used version of selenium is dated. We need to upgrade to new version which brings a lot better support of CORS.

I am hitting a use case where I want to call external http rest service from the integration test. This service is started as a part of pre-integration test phase and runs on localhost. Currently, when I do something like this in my javascript test:

var xhr = new goog.net.XhrManager();
xhr.send(
    "id",
    "http://localhost:9200",
    undefined,
    undefined,
    undefined,
    undefined,
    function(event) {
        assertNotNull(event);
    }
);

I get:

[INFO] --- closure-testing-maven-plugin:1.18.0:js-closure-test (default-js-closure-test) @ ... ---
[INFO] (ClosureTestingMojo.java:111) Generating Test Suite...
[INFO] (ClosureTestingMojo.java:281) Calculating File Set...
[INFO] (ClosureTestingMojo.java:184) Parsing 1 Test Files (1 threads)...
[ERROR] (StrictErrorReporter.java:79) runtimeError: message=[Access to restricted URI denied] sourceName=[file:/.../target/javascriptFramework/closure-library/closure/goog//net/xhrio.js] line=[481] lineSource=[null] lineOffset=[0]

Note the Access to restricted URI denied message.

It turns out that this is problem of HtmlUnit version 2.9 (which is used by selenium 2.24.1) as it does not support CORS. Better CORS support is available in HtmlUnit version 2.11 and higher. See HtmlUnit changes report.

I tested selenium 2.35.0 which uses HtmlUnit 2.12 and it works well. Upgrading to even newer version of selenium would require adaptation to changed API. But it might be worth too.

The goog.testing.ContinuationTestCase can be used for testing of async components. The problem, however, is that tests based on ContinuationTestCase do not output DIV element that can be parsed into TestCaseStart.

Check for example output of <closure-library>/closure/goog/testing/continuationtestcase_test.html.

As a result the test always end up with the following error:

[ERROR] (ClosureTestingMojo.java:85)
There was a problem with the '_path_to_test.html' Test Case.
Unable to scrape the results of any test cases.  Please check the output to guarantee that test cases are being executed or remove the test case file.

As of writing I am not sure what would be the best solution for this problem but I want to record it.

When dealing with Element.innerHTML in Selenium tests result can differ depending on the used browser. HtmlUnitDriver allows to specify which BrowserVersion to use.

The idea is to allow configuration of browserVersion for both the closure-testing-framework-plugin and closure-testing-report-maven-plugin. As a results user can control output of sensitive operations (like above mentioned Element.innerHTML).

Example of configuration

    <plugin>
        <groupId>com.github.jlgrock.javascript-framework</groupId>
        <artifactId>closure-testing-maven-plugin</artifactId>
        <version>${jsframework.version}</version>
        <configuration>
            <browserVersion>FF</browserVersion>
        </configuration>
    </plugin>

Supported values

If browserVersion is empty of not specified at all then the default BrowserVersion is used, which usually defaults to INTERNET EXPLORER but it is an internal implementation detail of BrowserVersion and is subject to change depending on used library version.

Example Unit Test

To give specific example of unit test where it was important to control browser version imagine the following use case. We generate HTML elements using the following code:

var captionDiv = goog.dom.createDom(goog.dom.TagName.DIV,"captionClass");
goog.dom.appendChild(caption, goog.dom.createTextNode("Caption"));

This creates a DIV element with class="captionClass" and text node containing text "Caption". Now, we can easily use innerHTML in test like this:

assertEquals(
    captionDiv.innerHTML.toLowerCase(),
    '<div class="captionClass">Caption</div>'
);

Now, without specifying browserVersion such test would fail:

* Test = testMethod : FAILED
    Expected <<div class="captionClass">Caption</div>> (String) but was <<div class=captionClass>Caption</div>> (String)
    Difference was at position 11. Expected [...s="captionClass"...] vs. actual [...s=captionClass...]

This is caused by the fact that if INTERNET EXPLORER browser version is used (which is used by default) then element attribute values are output without quotation. When we specify browserVersion equal for example to FF then such test would pass.

The following code (:

TestFailureStatistic tfs = this.testFailureStatistics.get(this.testFailureStatistics.size()-1);

Is causing the following error:
[INFO] --- closure-testing-maven-plugin:1.12.0:js-closure-test (default-js-closure-test) @ integration-testing ---
INFO Generating Test Suite
INFO Calculating File Set
ERROR -1
java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:371)
at java.util.ArrayList.get(ArrayList.java:384)
at com.github.jlgrock.javascriptframework.closuretesting.resultparsing.testingcomponents.TestCase.addToLastTestFailureStatistic(TestCase.java:284)
at com.github.jlgrock.javascriptframework.closuretesting.resultparsing.parsers.TestCaseParser.setDivProperty(TestCaseParser.java:108)
at com.github.jlgrock.javascriptframework.closuretesting.resultparsing.parsers.TestCaseParser.parse(TestCaseParser.java:52)
at com.github.jlgrock.javascriptframework.closuretesting.resultparsing.ParseRunner.parseFiles(ParseRunner.java:99)
at com.github.jlgrock.javascriptframework.closuretesting.ClosureTestingMojo.parseFiles(ClosureTestingMojo.java:206)
at com.github.jlgrock.javascriptframework.closuretesting.ClosureTestingMojo.execute(ClosureTestingMojo.java:53)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:195)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:140)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:451)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:188)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)

When generating the typical asynchronously loading assert and debug code, the configured outputWrapper is ignored. When the synchronous files are created, they use the compiler and wrap the code in that wrapper. This is causing problems when wrapping the compiled code in an anonymous function, preventing the synchronous debug and assert libraries from working.

Add an option to the compiler plugin that requests the synchronous debug and assert output ignore any configured outputWrapper.

Hi,

In the latest version we have an issue configuring via pom.xml.

This is the target in pom.xml

                    <plugin>
                            <groupId>org.mojo.javascript-framework</groupId>
                            <artifactId>closure-compiler-maven-plugin</artifactId>
                            <version>${jsframework.version}</version>
                            <configuration>
                                    <compileLevel>SIMPLE_OPTIMIZATIONS</compileLevel>
                                    <errorlevel>SIMPLE</errorlevel>
                            </configuration>
                    </plugin>

However the configuration is never read. Temporarely we've set them using project properties instead however this requires us to use our own repository. Would much rather be able to use the public version.

Is this something you've experienced also? Or is there something in our configuration that is screwed?

I've debugged the plugin and the config variables aren't read from the pom. We've got quite a few other plugins that are similar but they have no issue reading the config section.

Keep up the great work!

Cheers
Patrick

Our project needs some page-wide code to execute before our included test cases. We need a place to insert our own code after the goog.base include, but before the tests are added. We also could use a place after the tests for some cleanup.

Need to determine what is taking the longest amount of time to see if it can be sped up. For our larger projects, on a Windows environment, this can take up to 10 minutes to run. In Linux/Mac, this tends to take ~2 min.

Not sure if anyone needs this, but it should be reasonably trivial to implement

can likely have a debug version running as well, just need to execute a different js file depending on the logging mode.
http://code.google.com/p/jsdoc-toolkit/source/browse/trunk/jsdoc-toolkit/java/src/JsDebugRun.java?r=848

In many cases, it would be nice if there was a way to specify the version of the closure-library. Right now, the version packaged with the framework is not adjustable. This can be remedied by cloning the closure-library repo in an automated way and packaging it as a maven product for use in the jsdependency plugin.

if I set

<build>
<sourceDirectory>src/main/js</sourceDirectory>
</build>

make sure that the sourceDirectory is properly overridden.

Would it make sense to implement support for https://github.com/nanaze/jscomprun for unit testing?

As long as #11 is not solved, can we upgrade to the new version of Closure Compiler and Library?

See
http://code.google.com/p/closure-compiler/wiki/Maven

It seems some bugs were fixed:
http://code.google.com/p/closure-compiler/wiki/Releases

Show standard workflow techniques for how to do testing with this framework.

Should show how the test cases get generated and how you can open them in a browser.

It would be nice to show how you can compile and then edit your test cases thereafter to save time and not compile over and over again.

Essentially, apply prettyprint to the closure output for debugging closure issues.

In some instances, it would be useful to have a version of the assert and debug libraries that is a single file instead of the asynchronously loading files that are currently generated. A specific use case is hosting the compiled and assert/debug code from a secured web server that needs to modify the returned JavaScript at request time. This is nearly impossible to do with the async code because the library needs to have a single entry point and we don't want to expose all of the internal files from the web server.

From a user:

I am trying to setup specific testing scenario and I can not find a way how to do it properly, thus I am contacting you directly, you might be able to give me some hints.

Here is the situation:
I am implementing some application with Google Closure and I am using your CJF (1.14.0). Now, my javascript src files live in src/main/javascript/ and my test files live in src/test/javascript. I am not very familiar with what is really going on when I run 'mvn clean test' but I encountered situation when not all test resources are picked up and I am getting the following error (please see below for a more details):

ERROR Problem with require in file 'xxx/src/test/javascript/org/Manager_test.js'. Found goog.require for 'org.xyz.TestService', but did not find a corresponding goog.provide.
java.lang.NullPointerException
at com.github.jlgrock.javascriptframework.closurecompiler.CalcDeps.orderDependenciesForNamespace(CalcDeps.java:232)
at com.github.jlgrock.javascriptframework.closurecompiler.CalcDeps.slowSort(CalcDeps.java:197)
at com.github.jlgrock.javascriptframework.closurecompiler.CalcDeps.calculateDependencies(CalcDeps.java:101)
at com.github.jlgrock.javascriptframework.closurecompiler.CalcDeps.executeCalcDeps(CalcDeps.java:299)
at com.github.jlgrock.javascriptframework.closurecompiler.JsClosureCompileMojo.createDepsAndRequiresJS(JsClosureCompileMojo.java:95)
at com.github.jlgrock.javascriptframework.closurecompiler.JsClosureCompileMojo.execute(JsClosureCompileMojo.java:516)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)

It seems that the closure-library.zip resource contains buggy version of Closure library sources.

I am hitting this issue when using SIMPLE_OPTIMIZATIONS:
https://groups.google.com/forum/?fromgroups=#!topic/closure-library-discuss/s4PxsXfKz0A
this seems to be already fixed since
http://code.google.com/p/closure-library/source/detail?r=2115

It seems to be confusing because if I for example use compiler of version r2180

<plugin>
    <groupId>com.github.jlgrock.javascript-framework</groupId>
    <artifactId>closure-compiler-maven-plugin</artifactId>
    <version>1.13.2</version>
    <configuration>
        <compileLevel>SIMPLE_OPTIMIZATIONS</compileLevel>
    </configuration>
    <dependency>
            <groupId>com.google.javascript</groupId>
            <artifactId>closure-compiler</artifactId>
            <version>r2180</version>
    </dependency>
</plugin>

then the Closure library that is used is older than this.

When I ran with ADVANCED_OPTIMIZATIONS, I got errors like:
closure/closure/goog/events/events.js:896: ERROR - Bad type annotation. Unknown type goog.debug.ErrorHandler

Suggesting this problem:
https://code.google.com/p/closure-library/wiki/FrequentlyAskedQuestions#When_I_compile_with_type-checking_on,_I_get_warnings_about_"

Solved by including closure-library/closure/goog/deps.js. I noticed in the code that closure-library/closure/goog/base.js is included automatically in com.github.jlgrock.javascriptframework.closurecompiler.JsClosureCompileMojo.execute() using getBaseLocation(closureLibraryLocation), and after adding a similar inclusion for deps.js, the problem went away.

The goal would be to allow users to keep whole closure-library sources as part of the project resources (like in vendor folder) and have it used by CJF maven testing plugin instead of built-in closure-library.

I do always keep extracted copy of closure-library as a part of the project for two reasons:

• I implement some tests that can be run manually (by opening single HTML file) and for this I need the library sources in extracted form (these tests are also run as a part of CJF tests via maven test plugin support but it is faster if I can run individual test manually without all the maven ceremony)
• I often look into the library sources (and my IDE allows me to quickly navigate into it)

This will also allow users to use different version of closure-library than the one provided by the CJF (there is no official maven friendly packaging anyway). This will however require user to make sure the closure-library sources are complete and valid.

WDYT? @jlgrock

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.

If I release 1.13.0, and someone is using 1.12.4 of the library, the maven source will currently break their build (in some cases). This is due to the fact that Maven will by default use the newest (non-snapshot) version of the plugin. To fix this, the components.xml needs to include the version, preferably populated by maven variables.

Is it possible to support compiled Soy templates? Or even better compilation of Soy templates?

IMO, this would mean management of specific Soy templates version and injecting soyutils_usegoog.js into dependencies for the Closure compiler.

Would be great to have it!

The regex method for reading in the test cases is working most of the time, but every now and again, it will fail on reading the test case in its entirety. The messages need to show up in the test case section, rather than before it, to help facilitate easy fixing of issues.

Good work, you rock!

With the releases below I'm having some JavaScript compilation errors that I don't suffer when using the latest (r1971) closure-compiler release.

closure-compiler-maven-plugin:1.11.13:js-closure-compiler
com.google.javascript:closure-compiler:jar:r1592

Is it possible configuring compiler version? I've tried setting "closure-compiler.version=r1971" on Maven startup but doesn't work.

Many, many thanks for your contribution.-

Need to figure out a way to reference a local copy of Closure because one of the slowest parts of the build process is waiting for 1000 files to expand

I have noted this about all of the JsDocToolkit maven plugins - they all do this. There has to be a way to fix this, but I'm not sure how. Exposing the path could expose something about your system that you don't want folks to know, so I would like this fixed. In the meantime, A git/ant task should be able to rename the files pretty easily. Don't know if this will affect local linking, however.