I am running katalon scripts on my agent which we use as apart of CICD. The code works in Katalon IDE but when running the same code on agent, it throws error for a dependency which we have added to our set of drivers.
We have come to a conclusion that there is some other dependency/jar which is making the commons-io pull for an older version which does not provide the required method.
And that’s where I felt the need for dependency management. Wanted to know if there is any out-of-the-box solution provided for dependency management for Katalon scripts?
I want to make sure that the right versions of dependencies which I specify get added so that I do not have to deal with conflicting version/unintentional versions getting pulled.
In any katalon project, you will find a file named .classpath. This file is generated by Katalon Studio when you open the project. In the file, you will find the paths of all jars provided for the project. For example, one of my project has the .classpath as follows:
The v2.6.0 of commons.io is bundled in the Katalon Studio’s distributable. The v2.13.0 is the one I added into the Drivers folder manually.
Which version will be used? — The 2.6.0 will be used because the line of 2.6.0 appears first in the .classpath file. Katalon Studio won’t load the classes with the same Fully Qualified Class Name in the v2.13.0 as the v2.13.0 appears late in the .classpath file.
Now you want to remove the v2.6.0 of commons-io out of the .classpath file.
It is supported. See the doc:
This is the way how Katalon Studio wants users to follow to manage external dependencies for katalon projects. It does not understand other ways of dependency management of Maven & Gradle.
Hi @kazurayam , I took a look at documentation but did not find it so asking it here. Is it possible to provide a relative path rather than absolute path in our .classpath file? I see that Katalon Studio writes absolute paths which are not available when we run the Katalon scripts on our agent. Which is why Katalon is not able to find those jars and defaults to it’s pre-defined/provided versions.
I personally have never used the feature of excluding jars out of the Katalon project’s classpath. So I am not sure if you can manage your problem using that feature. Maybe not, as your exercise proved. I guess that the feature is not used by many users. There could be rooms to be improved.
I suppose you execute a shell script on your CI/CD server to run your tests in KRE, aren’t you?
You now know the exact full path of the v2.6.0 of commons-io, don’t you?
Then, you can resolve your problem a bit brutally. Your shell script should be able to move the jar out of the KRE intallation directory to some temporary directory before it runs katalonc. I suppose that Katalon will update the .classpath file when the project is opened so that the updated file won’t include the v2.6.0 of commons-io.
I have ever done this (removing a bundled jar) manually, not by shell script runtime. It looked working. However it affected badly to other projects that lack newer version of jar in the Drivers folder. Therefore I would advise you to restore the v2.6.0 back before your project finishes.
Your OS user need to have an enough access priviledge to operate the jar file, of course.
You can read the full souce of the latest commons-io. You can learn how to implement the new method(s) that you want to use but not avaiable in the old v2.6.0.
So, you would be able to write your own Groovy class that mimics what you want on the top of v2.6.0 commons-io. You can locate the class in the Keywords directory.
Yes, Katalon is powerful but I would very much appreciate if Katalon comes up with a way to perform dependency management! Because the deeper we go and write more tests, more of such problems we encounter. - @vu.tran
@kazurayam@vu.tran I would agree with Katalon and gradle being two different beasts and it probably won’t be a good idea to make them work together. But that being said, dependency management becomes core to a project to avoid dependency hell and conflicts when the project starts getting bigger and start using several depdendencies. If not gradle, then Katalon needs to come up with it’s own version of dependency management. We cannot rely on classpath because it always gets updated when you run it on different machines and based on my work, I can also guarantee you that it also wipes out all the previous config that you might have done.
For ex. if you exclude some library, it gets readded back when it is run fresh because classpath has no provision to specifically tell what needs to be excluded.
I would totally agree with you. I think that Katalon Studio is good for the starters for automated UI testings because it bundles “everything required to get started”. The starters in Katalon Studio don’t have to learn what Dependency Management is and how to code it.
However, as the projects live long and get more developed, I get frustrated by the lack of industry standard Dependency Management.
No. It is impossible to change the design of the .classpath file. The .classpath file is created and managed by the Eclipse platform on which Katalon Studio is built upon. Katalon Studio would have no chance to change the design of .classpath. The Eclipse platform writes the .classpath file using the absolute path of the external jars; you must accept it.
I guess that you added and commited the .classpath file into the Git repository. You pushed it to a remote repository, which KRE shares for CI/CD execution. It’s usual. Everybody does the same.
But what would happen if you remove the .classpath file out of the git repository? I mean, you want to add a line
.classpath
in the <projectDir>/.gitignore file. If you have already added the .classpath file into the repository, you also need to purge it out of the reposigory by a git command:
$ cd <projectDir>
$ git rm --cached .classpath
Let me think: KRE clones the project from the remote repository and opens the project. KRE finds the .classpath file missing in the project, then what will KRE do? I believe that KRE will generate the .classpath file refering to the libraries’ absolute paths in the given runtime environment.
So, if you remove the .classpath file out of the Git repository, the file will be repeatedly regenerated with the absolute path of jars contained in the KRE runtime environment while taking your “Exclude XXXX.jar” setup into account. Thus, possibly, your problem will be resolved.