Configuring Build Kit publish command

Hello,

I am currently using the Build Kit to launch JUnit tests via a terminal with the “mmm publish” command. My tests are correctly executed, but the command takes up to 10 min to complete. I want to optimize this duration. The code coverage task takes ~5 min and prints “[codeCoverAnalyzer] .WARNING : unable to find source code for XYZ.java” for each class in the project. Can I fix these warnings without changing my platform ? I am using the SDK 21.03 distribution and a 7.12.1 platform for ESP32 with PSRAM.

Beside these warnings, how can I configure or disable some tasks in the publish process (code coverage, Javadoc generation, etc.) ? In my module.ivy, in the ea:build tag, I have already some properties like this: <ea:property name=“skip.build.virtual.device” value=“true” />
A complete list with an explanation for each property would be perfect.

If there is a more appropriate way to launch the JUnit tests (and generate the report) via a command line than using “mmm publish”, please tell me.

Best regards,
Yoann Jézégou, developer at Otodo

Hello Yoann,

A fix has been done on the code coverage analyzer for the warning message in the architecture 7.16 but this version has not been released yet.
In the meantime you can disable the code coverage analysis by adding this property in your module.ivy:

<ea:property name="microej.testsuite.properties.s3.cc.activated" value="false" />

If your prefer to keep the code coverage analysis enabled, we could provide the version of the code coverage analyzer containing the fix, so you can patch your platform, let me know.

A complete list with an explanation for each property would be perfect.

We are working on it, we’ll let you know when it is published.

If there is a more appropriate way to launch the JUnit tests (and generate the report) via a command line than using “mmm publish”, please tell me.

You can launch only the clean and test targets by using the -t option:

mmm -t clean,test

Regards,
Thomas Delhoménie

Thanks for your answer. Disabling the code coverage analysis speeds up the process a lot.

Since I don’t use the code coverage analysis for now, I prefer to wait for the new platform rather than applying a patch.

I tried the “mmm -t clean,test” command, but I got a ClassNotFoundException when my test tried to access the tested class. I tried with “clean,compile,test”, but the result is the same. “clean,build,test” works, but seems to perform some operations twice and takes more time than “publish”.

Best regards,
Yoann Jézégou, developer at Otodo

Adding “compile” in the list of targets does not change anything since the “compile” target is already triggered by the “test” target. The “build” target is kind of an alias for the “package” target.
What is the build type of your project (tag ea:build of your module.ivy file) ? Can you describe the structure of your project please ?
It would help to have the logs of the build, or a minimal project to reproduce the issue.

Regards,
Thomas Delhoménie

Hello,

The build type of my project is build-microej-javalib, revision 5.0.0.
My tested code (= the class not found) is in src/main/java/com/otodo/hub/impl/utils. The testing class is in src/test/java/com/otodo/hub/impl/test.

The logs :
logs targets clean test.txt (9.5 KB)

Best regards,
Yoann Jézégou, developer at Otodo

In your case the packaging phase is indeed required: mmm -t clean,package,test
But I don’t get why it would take more time than with mmm publish. It won’t save a lot of time since it only avoid to publish the artifact, but it should not be longer. Can you attach the logs of a build with mmm -t clean,package,test please ?

Hello,

With clean,package,test it works and it seems a little bit faster than publish. So I will use this command, thanks for your help.

If you still want the logs :
logs targets clean package test.txt (13.2 KB)

Best regards,
Yoann Jézégou, developer at Otodo

The addon processor execution is done twice indeed. It should have no impact (except marginally on build time), but I will check why. Thanks for the feedback.

Best Regards,
Thomas