Migration from CUBA 7.2x to 1.2x

I am giving a trying to migrate my project, aparently the Studio completed the migration but with the following exception:

	at com.haulmont.jmixstudio.buildsystem.gradle.GradleBuildFilesProvider.getBuildGradle(GradleBuildFilesProvider.kt:76)
	at com.haulmont.jmixstudio.buildsystem.gradle.GradleBuildFilesProvider.searchBuildFiles(GradleBuildFilesProvider.kt:47)
	at com.haulmont.jmixstudio.buildsystem.gradle.ui.projecttree.JmixBuildScriptSection.getChildrenImpl(JmixBuildScriptSection.kt:31)
	at com.haulmont.jmixstudio.intellij.ui.cubatree.AbstractJmixSection.getChildren(AbstractJmixSection.kt:56)
	at com.haulmont.jmixstudio.intellij.ui.cubatree.jmix.JmixProjectModuleNode.getChildrenImpl(JmixProjectModuleNode.kt:55)
	at com.haulmont.jmixstudio.intellij.ui.cubatree.AbstractJmixSection.getChildren(AbstractJmixSection.kt:56)
	at com.intellij.ide.util.treeView.AbstractTreeStructureBase.getChildElements(AbstractTreeStructureBase.java:38)
	at com.intellij.ui.tree.StructureTreeModel.getValidChildren(StructureTreeModel.java:383)
	at com.intellij.ui.tree.StructureTreeModel.validateChildren(StructureTreeModel.java:299)
	at com.intellij.ui.tree.StructureTreeModel$Node.isLeaf(StructureTreeModel.java:559)
	at com.intellij.ui.tree.StructureTreeModel.isLeaf(StructureTreeModel.java:335)
	at com.intellij.ui.tree.LeafState.get(LeafState.java:64)
	at com.intellij.ui.tree.AsyncTreeModel$CmdGetChildren.load(AsyncTreeModel.java:574)
	at com.intellij.ui.tree.AsyncTreeModel$CmdGetChildren.getNode(AsyncTreeModel.java:547)
	at com.intellij.ui.tree.AsyncTreeModel$Command.get(AsyncTreeModel.java:440)
	at com.intellij.ui.tree.AsyncTreeModel$Command.get(AsyncTreeModel.java:406)
	at com.intellij.util.concurrency.Invoker$Task.run(Invoker.java:316)
	at com.intellij.openapi.application.impl.ApplicationImpl.tryRunReadAction(ApplicationImpl.java:1084)
	at com.intellij.openapi.progress.util.ProgressIndicatorUtils.lambda$runInReadActionWithWriteActionPriority$0(ProgressIndicatorUtils.java:75)
	at com.intellij.openapi.progress.util.ProgressIndicatorUtils.runActionAndCancelBeforeWrite(ProgressIndicatorUtils.java:158)
	at com.intellij.openapi.progress.util.ProgressIndicatorUtils.lambda$runWithWriteActionPriority$1(ProgressIndicatorUtils.java:115)
	at com.intellij.openapi.progress.ProgressManager.lambda$runProcess$0(ProgressManager.java:57)
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:188)
	at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$12(CoreProgressManager.java:624)
	at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:698)
	at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:646)
	at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:623)
	at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:66)
	at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:175)
	at com.intellij.openapi.progress.ProgressManager.runProcess(ProgressManager.java:57)
	at com.intellij.openapi.progress.util.ProgressIndicatorUtils.runWithWriteActionPriority(ProgressIndicatorUtils.java:112)
	at com.intellij.openapi.progress.util.ProgressIndicatorUtils.runInReadActionWithWriteActionPriority(ProgressIndicatorUtils.java:75)
	at com.intellij.util.concurrency.Invoker.invokeSafely(Invoker.java:205)
	at com.intellij.util.concurrency.Invoker.lambda$offerSafely$0(Invoker.java:183)
	at com.intellij.util.concurrency.Invoker$Background.lambda$offer$0(Invoker.java:486)
	at com.intellij.util.concurrency.BoundedTaskExecutor.doRun(BoundedTaskExecutor.java:246)
	at com.intellij.util.concurrency.BoundedTaskExecutor.access$200(BoundedTaskExecutor.java:32)
	at com.intellij.util.concurrency.BoundedTaskExecutor$1.execute(BoundedTaskExecutor.java:225)
	at com.intellij.util.ConcurrencyUtil.runUnderThreadName(ConcurrencyUtil.java:213)
	at com.intellij.util.concurrency.BoundedTaskExecutor$1.run(BoundedTaskExecutor.java:214)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:668)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:665)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:665)
	at java.base/java.lang.Thread.run(Thread.java:829)

The result is, I lost many screens in the migrated Jmix project, see below the comparison:


Unfortunately, I can’t reproduce the problem. Can you please tell me what version of IntelliJ IDEA and Jmix plugin do you use? And which project language: java or kotlin?


IntelliJ 2021.3.2 (Community) - IntelliJ IDEA 2021.3.2 (Community Edition)
Build #IC-213.6777.52, built on January 27, 2022
macOS 12.2.1
JMIX 1.2.1

Hi @mortoza_khan

I’m trying to reproduce the error, but I can’t. Could you clarify please which database, Java version do you use? Or can you give us some test project where the error reproduces?

Regards, Elena

It’s not a project that freshly developed in CUBA 7.2 but originally created in v6.x and migrated to v7x platform. Therefore, it will not be easy to create a similar one for testing. But I have shared with you the exception that should help you.

I am using MS SQL Server 2017 database and java 11.06

Hi @mortoza_khan

We create a ticket about the exception, but to resolve it we need more information.
It would be great if you could give us:

  • MigrationResult.md file from your migrated project root folder
  • idea.log with the exception.


Hi Yulia
Thanks for creating the ticket. FYI, I have tried again to migrate using the latest Jmix version (1.2.2) but got the same result where many screen files are missing. I didn’t check if anything else is also missing in the migrated project.

The requested files are attached.
MigrationResult.md (999 Bytes)
idea.log.zip (907.9 KB)

I hope this helps you to identify the root cause to resolve the issue.

Hi @mortoza_khan

Thanks for the idea.log, it’s very useful. We have found a possible cause of the exception:
there are two files controller.java (perhaps in two different modules) with the same name and package and the jmix migrator trying to save it twice (to one module).

After that error remaining java classes were not migrated. Then screen descriptors were migrated correctly, but without connected controllers part of them were not shown in “Jmix” tool window. We suppose one can find them through standard project structure.

So, as a solution you can find two controller.java files, delete one of them and try again. Also it’s possible to improve the migration to handle such situations in the future.


Hi Yulia
Thank you so much, that helps.
I found controller.java (and a few other files) under CustomerTemplate. As those are custom templates, probably the CUBA is allowed to have controller files in the same name.

I removed them all, cleaned and then migrated my project. Unfortunately, I didn’t get any better results!

I have attached those files from the latest attempt to migrate.
MigrationResult.md (1.0 KB)
idea 2.log.zip (207.5 KB)

Hi @mortoza_khan

So, now it’s not the same IllegalStateException, but some screens aren’t migrated anyway in your project, right?


Yes that’s the problem.

Hi Yulia, is there any updates?

Hey, are you still investigating this??

Hi @mortoza_khan
Yes, I’ve asked developers to help me with the problem.

Hi @mortoza_khan
I am investigating the problem and I have a couple of questions.
Don’t you see your files only on the “Jmix” tab or also on the “Project” tab?
Have you tried to find some lost file through the “Navigate → File…” Idea’s tool?
Were the controllers for the missing screens migrated correctly?
Could you provide file names: one file which was moved correctly and another which was lost (it will help me to trace the log)?

Thank you for your help

Hi @y.konyashkina and @Anton.Kozub
Good to know that you’re working with the developers.

If I expand the project tab I see all folders but they contain only the controller files only, no xml file for the screen.


File correctly converted:

File that was not converted:

When I searched one of the missing screen files, I found that. I have attached the screen xml file in case that is useful. You will find fetchPlan is red in color.
bank-reconciliation screen file.txt (17.6 KB)

I hope this helps to identify the issue, Let me know if you need any additional info.

It’s ok that you don’t see xml file in the same folder with it’s controller. Unlike Cuba, Jmix keeps them separately: controllers in java folder, descriptors in resources. And if they are configured clearly, the “Jmix” tab shows them together.
In our case, I suppose, all files were migrated, but were not transfromed correctly, so Jmix cannot connect and show them in the tab. Let’s find out what was going wrong.
The file bank-reconciliation screen file.txt looks strange, it has three window root tags. Did you take it from Cuba project or from Jmix one after the migration?
Are there any errors in BankReconciliation.java file? Can you attach both versions of this file - before and after the migration?

Hi Anton
The file I sent you was after migration.

Here is the files before migration:
bank-reconciliation.xml (5.8 KB)
BankReconciliation.java (552 Bytes)

Here is the files after migration to jmix
BankReconciliation.java (525 Bytes)

You mentioned that you project had been created on Cuba v6. These files you attached are still using old api. You should upgrade them to Cuba v7 approaches if you want to migrate to Jmix successfully:

  1. Use xmlns="http://schemas.haulmont.com/cuba/screen/window.xsd" instead of xmlns="http://schemas.haulmont.com/cuba/window.xsd" in descriptors;
  2. For the Controller instead of extending deprecated AbstractWindow use the newest technique, for example:
    public class BankReconciliation extends StandardLookup<Bank> {

In fact, I am not planning to make such tedious code conversion at this moment, waiting for the new version of JMIX with Vaadin 23 to convert screens in one go… will be painful but better once than again and again… Do you think it can be done as I don’t know how the project migration process will work for Vaadin 23 preview version to be released this quarter of the year?