Google Closure using ES5 strict mode even though I specified non-strict mode (in minify-maven-plugin configuration) - minify

I'm using the com.samaxes.maven minify-maven-plugin to minify a collection of JS source files written using some of the ES6 features Google Closure supports. Here's the relevant configuration in my POM:
<!-- minify-maven-plugin: Minification using Google Closure -->
<plugin>
<groupId>com.samaxes.maven</groupId>
<artifactId>minify-maven-plugin</artifactId>
<version>1.7.6</version>
<executions>
<!-- Creation of the common-[version].js file -->
<execution>
<id>common-minify</id>
<phase>prepare-package</phase>
<configuration>
<charset>UTF-8</charset>
<jsSourceDir>.</jsSourceDir>
<jsSourceFiles>
...
</jsSourceFiles>
<jsFinalFile>./js/common-${project.version}.js</jsFinalFile>
<jsEngine>CLOSURE</jsEngine>
<closureLanguageIn>ECMASCRIPT6</closureLanguageIn>
<closureLanguageOut>ECMASCRIPT5</closureLanguageOut>
</configuration>
<goals>
<goal>minify</goal>
</goals>
</execution>
<!-- 2 other similarly configured executions are here. -->
...
</executions>
</plugin>
The problem is, when I run the maven goal this configuration, I get the following error message:
[INFO] Creating the merged file [common-1.8.24.js].
[INFO] Creating the minified file [common-1.8.24.min.js].
Jan 03, 2017 12:03:06 PM com.google.javascript.jscomp.LoggerErrorManager println
SEVERE: [1mcommon-1.8.24.js:5577: [31mERROR[39m - object literals cannot contain duplicate keys in ES5 strict mode[0m
supportsDataForwarding: function () {
^
This looks to me like Google Closure is trying to compile using ES5 Strict mode, even though I specified the non-strict ECMASCRIPT5 mode in my <closureLanguageOut> option (see doc here). Why is it not disabling strict mode?

i had the same problem and found a way to let the minify-maven-plugin not fail the build in case it complains about ES5 strict mode:
<plugin>
<groupId>com.samaxes.maven</groupId>
<artifactId>minify-maven-plugin</artifactId>
<version>1.7.6</version>
<executions>
<execution>
<id>default-minify</id>
<phase>process-resources</phase>
<configuration>
<charset>UTF-8</charset>
<closureWarningLevels>
<es5Strict>OFF</es5Strict>
</closureWarningLevels>
...
</configuration>
<goals>
<goal>minify</goal>
</goals>
</execution>
</executions>
You may further fine-tune using the following documentation How to tell closure compiler which warnings you want. Hope this helps :)

Related

babel-maven-plugin not transpiling spread operator to ES5

I am using DOJO toolkit and after upgrading to use the closure compiler, I noticed I needed to transpile to ES5 BEFORE the dojo build util does it's job in order to take advantage of newer ES6+ features.
So I am using babel-maven-plugin to accomplish this.
Everything is working fine with the exception that the ...spread operator is not transpiling.
Do I need to download the #babel/preset-env package as well to set the preset option? or is there an option I am missing?
After further discovery there is no need to download any preset package.
babel-standalone takes in preset options through its API as defined here and use in the babel-maven-plugin here.
The preset option is not passed to the Babel API like defined in a .babelrc config file. It is passed in without the preset- prefix. So to get the #babel/preset-env preset option you need to simply pass in env.
So to round this out, here are the common presets and how you would pass them through to the API:
#babel/preset-env --> env
#babel/preset-react --> react
#babel/preset-flow --> flow
#babel/preset-typescript --> typescript
So in order to use babel-maven-plugin I need to set up the pom.xml as follows:
<plugin>
<groupId>com.jarslab.maven</groupId>
<artifactId>babel-maven-plugin</artifactId>
<version>1.6</version>
<executions>
<execution>
<id>js-transpile</id>
<phase>process-resources</phase>
<goals>
<goal>babel</goal>
</goals>
<configuration>
<verbose>true</verbose>
<babelSrc>./js/babel/babel.min.js</babelSrc>
<sourceDir>./js</sourceDir>
<targetDir>./js</targetDir>
<presets>env</presets>
</configuration>
</execution>
</executions>
</plugin>

JaCoCo Coverage not Calculated Correctly

I've a pretty standard Java-Maven build with some plain JUnit tests and some for Arquillian. JaCoCo is hooked via Maven like this:
<properties>
<sonar.jacoco.reportPath>${project.basedir}/../target/jacoco.exec</sonar.jacoco.reportPath>
</properties>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>${argLine}</argLine>
</configuration>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.4</version>
<configuration>
<destFile>${sonar.jacoco.reportPath}</destFile>
<append>true</append>
</configuration>
<executions>
<execution>
<id>agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>report</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
Running Sonar now seems to work, however the code coverage is all wrong. I'm not sure if these are separate issues or if there is one problem with the configuration producing all of them, so I'll just list them:
test suites are not run at all (meaning JUnit tests with #RunWith(AllTests.class))
Arquillian tests (with #RunWith(Arquillian.class)) are run, but the code coverage is wrong, i.e. entities have a code coverage of 0%
an entire module is not tested and I'm not sure why (all but one of the tests has #RunWith(Parameterized.class), but this annotation works in another module)
(After Qword's suggestion I tried it without the reportPath. However the reports in target/sites/jacoco/ are still missing the coverage.)
I'm wondering if the problem is with the JUnit runners or maybe because some of these tests are in another module than the classes they test (Arquillian / integration tests especially). On the other hand, some of the JUnit runners seem to work as well. Maybe it's a third component that breaks the build.
I tried arquillian-extension-jacoco as well, this plug-in doesn't seem to work at all (tests won't even start).
Is the problem with the JUnit runners? With the integration tests? How do I fix this?
You don't actually need to specify sonar.jacoco.reportPath. First of all, it's been deprecated in favor of sonar.jacoco.reportPaths. Second, if you specify the latter property, all reports will be created in a single binary file, but this is not default Jacoco behaviour (and SonarQube deprecated that as well).
I would suggest, as a first step, to
Entirely remove properties sonar.jacoco.reportPath and sonar.jacoco.reportPaths
Remove the configuration node from Jacoco plugin definition
Now, you'll won't find anymore the jacoco.exec file but instead for every module you'll find a new directory target/sites/jacoco in which there will be reports in CSV, XLM, and HTML. This is the standard Jacoco behaviour in v0.8.4.
I'm not entirely sure this will fix all your problems, but at least
I'm quite sure SonarQube will be able to correctly pick up the reports and show the coverage
You'll be able to analyse coverage with a simple mvn clean install on your local machine without having to go to SonarQube every time

Which maven phase will be always executed after test phase?

I have implemented a Maven plugin which is used to create test database (with random name) before Maven test phase, and drops that database when the test phase is completed.
The plugin need to be executed two times, before test phase (when is used to create database) and after test phase (when is used to drop that test database).
Which Maven lifecycle phase will be always executed after test phase, whether test phase is successfully executed or not?
There are no particular phase in the Maven lifecycle that corresponds to pre- and post-test. This is because unit tests are not supposed to require an external environment. It sounds like what you want to do are not unit tests but integration tests instead, because they require an environment to be set up.
From the docs:
test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
integration-test - process and deploy the package if necessary into an environment where integration tests can be run
And there is a pre-integration-test, integration-test and post-integration-test that are used to setup, run and destroy the test environment.
pre-integration-test: perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
integration-test: process and deploy the package if necessary into an environment where integration tests can be run.
post-integration-test: perform actions required after integration tests have been executed. This may including cleaning up the environment.
As such, it would be easier and a lot cleaner to do this in integration-test phase using the maven-failsafe-plugin.
Now, if you really want to run that as unit tests, I would not write the creation / deletion of the database as a Maven plugin. It would be a lot better to let your application create the test database when it is configured in a test environment. (For example, if you're using Spring, it has a lot of facilities for that.)
And, if you really want to run that as unit tests in the test phase, and using your plugin, you will have to skip the default execution of the maven-surefire-plugin and then define an execution of your Maven plugin creating the database, a new execution of the maven-surefire-plugin and an execution of your Maven plugin dropping the database, bound to the test phase.
This works because Maven invokes the plugins in the order as they are defined in the POM when they're bound to the same phase.
A configuration would look like:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
<executions>
<execution>
<id>default-test</id>
<configuration>
<skip>true</skip>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId><!-- group id of your plugin --></groupId>
<artifactId><!-- artifact id of your plugin --></artifactId>
<version><!-- version --></version>
<executions>
<execution>
<id>create-db</id>
<phase>test</phase>
<goals>
<goal><!-- your goal --></goal>
</goals>
<!-- add configuration -->
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
<executions>
<execution>
<id>test</id>
<phase>test</phase>
<goals>
<goal>test</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId><!-- group id of your plugin --></groupId>
<artifactId><!-- artifact id of your plugin --></artifactId>
<version><!-- version --></version>
<executions>
<execution>
<id>drop-db</id>
<phase>test</phase>
<goals>
<goal><!-- your goal --></goal>
</goals>
<!-- add configuration -->
</execution>
</executions>
</plugin>

IntelliJ Error when running unit test: Could not find or load main class ${surefireArgLine}

I get the following error when running Unit tests in IntelliJ:
Error: Could not find or load main class ${surefireArgLine}.
I am using maven and in pom.xml I have:
<properties>
...
<surefire.argLine />
</properties>
<build>
<plugins>
<plugin>
<groupId>com.mysema.maven</groupId>
<artifactId>apt-maven-plugin</artifactId>
<version>1.1.1</version>
<executions>
<execution>
<goals>
<goal>process</goal>
</goals>
<configuration>
<outputDirectory>target/generated-sources/java</outputDirectory>
<processor>com.mysema.query.apt.jpa.JPAAnnotationProcessor</processor>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.17</version>
<configuration>
<!--Sets the VM argument line used when unit tests are run.-->
<argLine>${surefire.argLine}</argLine>
</configuration>
</plugin>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.7.1.201405082137</version>
<executions>
<!--
Prepares the property pointing to the JaCoCo runtime agent which
is passed as VM argument when Maven the Surefire plugin is executed.
-->
<execution>
<id>pre-unit-test</id>
<goals>
<goal>prepare-agent</goal>
</goals>
<configuration>
<!--Sets the path to the file which contains the execution data.-->
<destFile>${project.build.directory}/coverage-reports/jacoco-ut.exec</destFile>
<!--
Sets the name of the property containing the settings
for JaCoCo runtime agent.
-->
<propertyName>surefireArgLine</propertyName>
</configuration>
</execution>
...
Did anyone have similiar problem? How to set value for surefireArgLine?
I had the same problem and i think i found the solution on the vertx-issue tracker.
In short you have to configure your IntelliJ Maven (surefire plugin) integration to behave differently.
This works for me in IntelliJ 14.1.6 with mvn 3.3.9
Preferences -> Build,Execution,Deployment -> Build Tools -> Maven -> Running Tests
For IntelliJ 2019 and above
Settings-> Build,Execution,Deployment -> Build Tools -> Maven -> Running Tests
Uncheck argLine
I was able to fix this error in Netbeans by changing the surefire-plugin version to 2.10 and removing
<argLine>-Xmx1024m -XX:MaxPermSize=256m ${argLine}</argLine>
from the maven-surefire-plugin configuration. Instead i have created a property argLine that is picked automatically by surefire.
<properties>
<argLine>-Xmx1024m -XX:MaxPermSize=256m</argLine>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.10</version>
</plugin>
Now, i can run and debug single files and test methods. And Code Coverage is working as expected.
Update of pom.xml solved my problem.
<argLine>${surefire.argLine}</argLine>
Complete plugin info in pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.18.1</version>
<configuration>
<parallel>classes</parallel>
<threadCount>10</threadCount>
<workingDirectory>${project.build.directory}</workingDirectory>
<jvm>${env.JDK1_8_HOME}\bin\java</jvm>
<argLine>${surefire.argLine}</argLine>
</configuration>
<dependencies>
<dependency>
<groupId>org.apache.maven.surefire</groupId>
<artifactId>surefire-junit4</artifactId>
<version>2.18.1</version>
</dependency>
</dependencies>
</plugin> -->
Was looking for this and found this project "fix" it in this thread
Basically define your jacocoArgLine var name as empty project property. Then in surefire configuration use #{jacocoArgLine} instead of dollar prefix.
I found out that I have to run my test case from maven with
mvn -Dtest=TestCircle test
not directly from IDE.
For a more permanent fix for every new project add the following to your IntelliJ IDEA Custom VM Options:
Help > Edit Custom VM options
Add: -Didea.maven.surefire.disable.argLine=true
This will deactivate surefire for all new projects you open.

jaxb2 maven plugin and configuration inside execution tag

I try to use JAXB2 maven plugin to generate java code from a bunch of .xsd files. If I try to generate from all xsds in a single execution I'll get org.xml.sax.SAXParseException: 'root' is already defined. I cannot modify the xsd files so I need to generate each independently. I found the following pom configuration to achieve that:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
<version>1.3</version>
<executions>
<execution>
<id>jaxb-Execution1</id>
<phase>generate-sources</phase>
<goals><goal>xjc</goal></goals>
<configuration>
<schemaDirectory>${jaxbSchemaDirectory}</schemaDirectory>
<outputDirectory>${jaxbGenerateDirectory}</outputDirectory>
<staleFile>${jaxbGenerateDirectory}/.staleFlagExecution1</staleFile>
<bindingDirectory>${jaxbSchemaDirectory}</bindingDirectory>
<bindingFiles>bindings1.xml</bindingFiles>
<schemaFiles>schema1.xsd</schemaFiles>
<clearOutputDir>false</clearOutputDir>
</configuration>
</execution>
<execution>
<id>jaxb-Execution2</id>
<phase>generate-sources</phase>
<goals><goal>xjc</goal></goals>
<configuration>
<schemaDirectory>${jaxbSchemaDirectory}</schemaDirectory>
<outputDirectory>${jaxbGenerateDirectory}</outputDirectory>
<staleFile>${jaxbGenerateDirectory}/.staleFlagExecution2</staleFile>
<bindingDirectory>${jaxbSchemaDirectory}</bindingDirectory>
<bindingFiles>bindings2.xml</bindingFiles>
<schemaFiles>schema2.xsd</schemaFiles>
<clearOutputDir>false</clearOutputDir>
</configuration>
</execution>
</executions>
But this is not working. The problem is that configurations are not read from inside of the execution block. Why is that? I am using maven 2.2.1.
I had the same issue when I tried to run the plugin using:
mvn jaxb2:xjc
A workaround for me was using:
mvn generate-sources