Unable to Open Project Due to Missing TempTestSuite

Hello,
I am unable to open my Katalon project because it cannot find TempTestSuite.class file.

What file or folder do I need to delete so that I can open my project again?

Here is the error on the build server:

error 16-Jan-2020 11:56:31 org.eclipse.core.internal.dtree.ObjectNotFoundException: Tree element ‘/E%%Bamboo%xml-data%build-dir%143360001-162627588%Katalon Studio%ChaChing_Tests%Trying out Covisum Project.prj/bin/lib/TempTestSuite1579014032497.class’ not found.
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.AbstractDataTree.handleNotFound(AbstractDataTree.java:257)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.DeltaDataTree.copyCompleteSubtree(DeltaDataTree.java:310)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.DeltaDataTree.naiveCopyCompleteSubtree(DeltaDataTree.java:774)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.DeltaDataTree.copyCompleteSubtree(DeltaDataTree.java:314)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.DeltaDataTree.naiveCopyCompleteSubtree(DeltaDataTree.java:774)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.DeltaDataTree.copyCompleteSubtree(DeltaDataTree.java:314)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.DeltaDataTree.naiveCopyCompleteSubtree(DeltaDataTree.java:774)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.DeltaDataTree.copyCompleteSubtree(DeltaDataTree.java:314)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.DataTreeNode.asBackwardDelta(DataTreeNode.java:54)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:48)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.DeltaDataTree.asBackwardDelta(DeltaDataTree.java:88)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:832)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:808)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.watson.ElementTree.immutable(ElementTree.java:519)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.events.ResourceDeltaFactory.computeDelta(ResourceDeltaFactory.java:43)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.events.NotificationManager.getDelta(NotificationManager.java:234)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:143)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:374)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1469)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.resources.Project.create(Project.java:307)
error 16-Jan-2020 11:56:31 at org.eclipse.core.internal.resources.Project.create(Project.java:247)
error 16-Jan-2020 11:56:31 at com.kms.katalon.groovy.util.GroovyUtil.initGroovyProjectDescription(GroovyUtil.java:559)
error 16-Jan-2020 11:56:31 at com.kms.katalon.groovy.util.GroovyUtil.initGroovyProject(GroovyUtil.java:153)
error 16-Jan-2020 11:56:31 at com.kms.katalon.controller.ProjectController.openProject(ProjectController.java:146)
error 16-Jan-2020 11:56:31 at com.kms.katalon.execution.console.ConsoleMain.getProject(ConsoleMain.java:341)
error 16-Jan-2020 11:56:31 at com.kms.katalon.execution.console.ConsoleMain.findProject(ConsoleMain.java:236)
error 16-Jan-2020 11:56:31 at com.kms.katalon.execution.console.ConsoleMain.launch(ConsoleMain.java:139)
error 16-Jan-2020 11:56:31 at com.kms.katalon.console.application.Application.runConsole(Application.java:76)
error 16-Jan-2020 11:56:31 at com.kms.katalon.core.application.Application.runConsole(Application.java:87)
error 16-Jan-2020 11:56:31 at com.kms.katalon.core.application.Application.start(Application.java:70)
error 16-Jan-2020 11:56:31 at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
error 16-Jan-2020 11:56:31 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
error 16-Jan-2020 11:56:31 at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
error 16-Jan-2020 11:56:31 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:388)
error 16-Jan-2020 11:56:31 at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:243)
error 16-Jan-2020 11:56:31 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
error 16-Jan-2020 11:56:31 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
error 16-Jan-2020 11:56:31 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
error 16-Jan-2020 11:56:31 at java.lang.reflect.Method.invoke(Method.java:498)
error 16-Jan-2020 11:56:31 at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)
error 16-Jan-2020 11:56:31 at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)
error 16-Jan-2020 11:56:31 at org.eclipse.equinox.launcher.Main.run(Main.java:1519)

Hi @dstahlnecker

Please delete Lib and bin folder.

Thanks @ThanhTo!
Deleting the bin and Libs folders seems to have done the trick.
:smiley:

Hi.
I am currently having the same issue.
I have deleted the “bin”, “bin_1”, and “Libs” directories located directly within my main Katalon Project directory. But I continue to receive this error.

org.eclipse.core.internal.dtree.ObjectNotFoundException: Tree element ‘/C%%KatalonSuites%PE_Core%PE_Core.prj/bin/lib/TempTestSuite1624471905232.class’ not found.
at org.eclipse.core.internal.dtree.AbstractDataTree.handleNotFound(AbstractDataTree.java:260)
at org.eclipse.core.internal.dtree.DeltaDataTree.copyCompleteSubtree(DeltaDataTree.java:313)
at org.eclipse.core.internal.dtree.DeltaDataTree.naiveCopyCompleteSubtree(DeltaDataTree.java:777)
at org.eclipse.core.internal.dtree.DeltaDataTree.copyCompleteSubtree(DeltaDataTree.java:317)
at org.eclipse.core.internal.dtree.DeltaDataTree.naiveCopyCompleteSubtree(DeltaDataTree.java:777)
at org.eclipse.core.internal.dtree.DeltaDataTree.copyCompleteSubtree(DeltaDataTree.java:317)
at org.eclipse.core.internal.dtree.DeltaDataTree.naiveCopyCompleteSubtree(DeltaDataTree.java:777)
at org.eclipse.core.internal.dtree.DeltaDataTree.copyCompleteSubtree(DeltaDataTree.java:317)
at org.eclipse.core.internal.dtree.DataTreeNode.asBackwardDelta(DataTreeNode.java:57)
at org.eclipse.core.internal.dtree.DataDeltaNode.asBackwardDelta(DataDeltaNode.java:51)
at org.eclipse.core.internal.dtree.DeltaDataTree.asBackwardDelta(DeltaDataTree.java:91)
at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:835)
at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:834)
at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:834)
at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:834)
at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:834)
at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:834)
at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:834)
at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:834)
at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:834)
at org.eclipse.core.internal.dtree.DeltaDataTree.reroot(DeltaDataTree.java:811)
at org.eclipse.core.internal.watson.ElementTree.immutable(ElementTree.java:522)
at org.eclipse.core.internal.events.ResourceDeltaFactory.computeDelta(ResourceDeltaFactory.java:46)
at org.eclipse.core.internal.events.NotificationManager.getDelta(NotificationManager.java:240)
at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:149)
at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:380)
at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1502)
at org.eclipse.core.internal.resources.Project.create(Project.java:312)
at org.eclipse.core.internal.resources.Project.create(Project.java:252)
at com.kms.katalon.groovy.util.GroovyUtil.initGroovyProjectDescription(GroovyUtil.java:700)
at com.kms.katalon.groovy.util.GroovyUtil.initGroovyProject(GroovyUtil.java:190)
at com.kms.katalon.controller.ProjectController.openProjectForUI(ProjectController.java:118)
at com.kms.katalon.composer.project.handlers.OpenProjectHandler$1.run(OpenProjectHandler.java:166)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)

I solved this problem by reinstalling Katalon software. But I don’t understand why this would happen. Is it possible on your end to explain how to prevent this from happening again?

I suppose, the Exception you posted above occurred because your Katalon Studio project previously crashed somehow and it left some internal state (workspace) dirty. The dirty state caused difficulty in the next trial of opening the project.

Eclipse workspace is a resource stored in the Katalon Installation directory. So I think that reinstalling KS initialized the workspace and fixed your problem. It’s OK. That’s a known tips among the Eclipse developers.

No. This question should to be addressed to yourself. How did you crashed your project previously? how can you refrain from crashing it again?

Thank you.

What concretely do you mean by “crashed”? Can you give some common practical examples of a Katalon Project crashing?

If this issue occurs again, is there some way for me to go into the Katalon Project directory and change some file’s text to remove the “dirty” internal state?

I can tell you that the last major “change” I had made to that Katalon Project was the following.

  1. I set up a Tortoise SVN subversion account
  2. From “Computer A”, I dumped my Katalon project directory in the subversion
  3. I checked-out the, the Katalon project directory from the subversion into “Computer B”
  4. I then ran it from Computer B and made some changes.
  5. It crashed on Computer B

But I don’t think the above is what you mean by “crashed”.

No, I can’t describe “crashed” concretely. I just meant Katalon Studio freezes, stops, or is interrupted by OS hibernation etc.

I do not have immediate “answer”. But I find Cultural Interface: !MESSAGE The workspace exited with unsaved changes in the previous session; refreshing workspace to recover changes. suggests something.

Did you include the bin and Libs directory in the subversion repository? That is a bad exercise. You shouldn’t do it.

If I were you I would explicitly exclude the following files/directories under the Katalon project dir out of repository:

.gradle

bin

Reports

Libs

output

!output/.gitkeep
build

.classpath

.project

It is important not to transfer the bin and Libs directories from one machine to another.

If these 2 directories are absent, Katalon Studio does a clean build of all Groovy source codes into classes. But, if KS finds bin and Libs dir present, it skips a clean build.

If you include the bin compiled by Computer A and just copied the bin to Computer B, I guess any curious things may happen on Computer B. For example, let me assume that on Computer A you had KS version 7.x and on Computer B you have KS version 8.x. On Computer B, KS version 8.x might be confused when it finds classes compiled by KS version 7.x. It may cause KS to “crash”.

A rule of thumb is that you should do a clean build of Katalon projects on each machine.

I guess, after successfully opening the project on Computer B, and before making any changes, you should have saved the project by quitting Katalon Studio. This is just to make sure the Eclipse platform under Katalon Studio initialise its internal cache named “workspace” for your project so that your project is successfully saved into Computer B and fully operational.

Well, I know nothing concrete about the cause of your problem. I am just guessing and spitting useless words around. Please ignore me.

I am replying a little bit late.

Well, I know nothing concrete about the cause of your problem. I am just guessing and spitting useless words around. Please ignore me.

On the contrary, what you are saying is invaluable information.

Here is what I have told my Subversion to ignore in the Katalon project’s directory.

As per your description, my thinking is to only keep the following directories which contain MY explicit work:

  • Data Files
  • Keywords
  • Scripts
  • Test Cases
  • Test Listeners
  • (Maybe) Test Suites

What is your view on these ones?

  • .settings
  • settings
  • console.properties
  • debug
  • GlobalVariables.glbl
  • PE_CORE.prj (PE_CORE is the name of my project)

As an aside, I think this is very useful information not only to me but to many other users. You may wish to consider write up a online tutorial going through each every directory/file in a project, describing what it does, how it is generated, and whether to store it in a Subversion repo.

When I created a new WebUI project in Katalon Studio 7.9.1

KS automatically generated a file named .gitignore. The generated file likes this:

.gradle

bin

Reports

Libs

output

!output/.gitkeep
build

.classpath

.project

.gitignore is used by Git, which specifies intentionally untracked files to ignore. The above code is a “standard .gitigore”: Katalon Studio recommends you to ignore those files/directories as listed above.

Of course you are free to modify it. I do add some more files/directories for my projects as neccessary.

@Ilya_Novak

You should read the above “.gitignore” as the basis for you to set up your Svn.

Let me make my comments to your Svn setup.

name should ignore? comment
.cache ? i dont know what it is
.settings arguable, up to you “Project > settings” is stored here. If you want to share it with others in your team, you should save .settings into Git/Svn. But be aware some of the member files contain timestamp information so that they would request you to commit often; this is annoying. If you do not want to share the “Project > setting” with others, you can ignore .settings. Katalon Studio will automatically recreate it if missing.
bin must ignore .class files here. you should not save it into Git/Svn. you should do clean build on each machines
bin_1 ? i dont know what it is
Checkpoint ? i dont know what it is. created by TestOps?
Data Files should not ignore here you would have the settings of Data binding if any
Drivers arguable, up to you here you would have, if any, some external dependencies (*.jar) which you manually installed. Sometimes the external jar files are bulky, so that it is not recommended to save the jar files into Git/Svn. If you are to ignore it, later you need to do installation again. If you want to avoid manual installation, see Dependency Management with Native Gradle support.
Include should not ignore you would have, if any, Cucumber-related source codes here
Keywords should not ignore you would have, if any, Groovy source codes here
Libs must ignore auto generated .groovy files here. you should not save it into Git/Svn. you should do clean build on each machines
Object Repository should not ignore here you may have Test Objects generated using WebRecorder/Spy tools
Plugins arguable, up to you here you would have the Plugin jars, if any, which you manually installed. Sometimes the jar files are bulky, so that it is not recommended to store *.jar files into Git/Svn. If you ignore Plugins/*.jar, you may need to do installation again later
Profiles should not ignore here you would have the Execution Profiles. At least you will have “default” profile.
Reports must ignore XML, HTML, CSV, JSON as Test Suite Reports. They are bulky. There could be many versions. Those should not be stored in Git/Svn. If you want to share with your team the information how your tests ran, you should look at Katalon Test Ops.
Scripts should not ignore Test Case scripts here

Wonderful!

Thank you.

My view is as follows:

name should ignore? comment
.settings arguable, up to you see the previous post of mine
settings should ignore Katalon Studio automatically generates files there. we dont need them in Git/Svn.
console.properties up to you, may ignore I don’t know what it is. looks to be generated by Katalon Studio automatically.
debug ? i dont know what it is. @Ilya_Novak’s personal one?
GlobalVariables.glbl ? i dont know what it is
Profiles/*.glbl should not ignore Execution Profiles are stored here
PE_CORE.prj should not igore important. A Katalon Studio project must have a *.prj file in the project root directory. If not present, Katalon Studio will fail to open the project.

Hi,

I am one Katalon user, from my observation, I see that

.cache : it is introduced in 8.0.0 which does not see in 7.91. For my project, when opening with 8.0.0 with large project, Katalon does not face with performance issue, but 7.9.1 does. I guess that .cache for this purpose related to keyword parse

Checkpoint: This is a concept commonly related to data checking. Example:

Table : Employee(id, name)

1, Employee 1
2, Employee 2
3, Employee 3

For day#1, data in the table is

1, Employee 1
2, Employee 2
3, Employee 3

For day#2, data in the table is:

1, Employee 4
2, Employee 2
3, Employee 3

=> One of the purpose of check point is to isolate data changed.

For more details about checkpoint, you are able to read on Katalon doc

Hope it is useful about the Katalon Structure

FYI.

@loc.nguyen

Should .cache be ignored for Git/Svn, or not?

Should Checkpoint be ignored for Git/Svn, or not?

Please give us your view.

.cache can be ignored because Katalon will parse project again and create new cache
Checkpoint cannot be ignore if you create checkpoint and use it in your scripts. (Consider it is designed as same same data files but for database check)

I think it is arguable if “Checkpoint” should be committed into Git/Svn or not.

To me “Checkpoint” is not a “source code”; it is a variant of Database snapshots.

If you save the Checkpoint everyday into Git/Svn, the repository could become large. A too large repository will become unable to clone/checkout at the end of the day.

I have ever had a bad experience of a too large Git repository. A few years ago, a developer of my team committed & pushed thousands of PDF files as test fixture into the team’s shared remote Git repository (some people tend to do it!). The size of the repository jumped up to some giga bytes; I was unable to clone it any longer. I gave up cloning it after hours. I had to throw the repository away and recreate it excluding PDF files.

First, you can check by yourself by deleting folder Checkpoint and use Katalon, if Katalon cannot work normally -> need this folder and the opposite

After that, about the checkpoint, I think that it is based on your purpose and how many data returned (I mean its size) in the query of checkpoint.

How many MB that your checkpoint take?

The Data Files folder, which is managed by Katalon Studio natively, will have just a small number of config files. The folder is NOT supposed to contain bulky CSV,Excel files or DB snapshots. therefore it is appropriate to include Data Files folder into Git/Svn. However, we (Katalon Users) do often locate bulky CSV, Excel files into the Data Files. Why we tend to do this? — because we don’t know anywhere else to save CSV/Excel files other than the Data File folder.

As soon as we locate bulky CSV,Excel files into the Data Files folder, the Data Files turns its nature. it becomes questionable if we should store Data Files/*.xlsx into Git/Svn or not? — well, it depends, it is up to each of us.


We should rather say “don’t save Checkpoints into Git/Svn”, shouldn’t we?

I suppose that Checkpoint deserves a feature of backup/restore on its own (possibly through Test Ops?) rather than storing it into Git/Svn.

@ThanhTo
Any comment on this?

Sorry, I have never used it, have no experience about it.

You can refer to this one: https://docs.katalon.com/katalon-studio/docs/manage-checkpoints.html#create-a-database-checkpoint