Entry point a2c

[axidex]

Which entry point should I specify(Steady-CLI 3.2.5)? I'm just tried with specifying main class in pom, but it didn't work (vulas.reach.sourceDir = app). Also i tried just point to src of project (vulas.reach.sourceDir = app/src).

[axidex]

In addition, before running this command i did mvn package

[henrikplate]

Hello @axidex - There's no need to use the CLI if you do have a POM file. In that case, I really recommend using Steady's Maven plugin, which will pick automatically all the application sources as entry points for the A2C reachability analysis. If you added Steady using a profile, you can just call mvn -Dsteady compile steady:a2c (see here for more info). If you did not add it as a build plugin, you would need to call it using the full name (see here).

[axidex]

@henrikplate But here is a problem, in my project I can't build source code(i already have precompiled project) and therefore I have no opportunity to use maven

[henrikplate]

Since you said you ran mvn package, which includes compiling project sources, I thought this would be a possibility. Were you able to run the app goal beforehand, which is a prerequisite for all the other analyses? Also, can you explain the project layout in more detail, e.g. where the source or compiled classes are, the dependencies etc.

[axidex]

@henrikplate, Thank you, running before a2c "mvn app" solved my problem, but now a new one has appeared. Here is the test repository on which it was tested https://github.com/axidex/test vulas.reach.fwk = wala

vulas.reach.fwk = soot

[henrikplate]

Thanks for sharing the test project. Note that it was easily possible to use the Maven plugin: I just cloned the repo, compiled the classes in src and ran the app and a2c goals using the following command:

mvn -Dvulas.core.space.token=A5344E8A6D26617C92A0CAD02F10C89C -Dvulas.shared.backend.serviceUrl=http://localhost:8033/backend/ compile org.eclipse.steady:plugin-maven:3.2.5:app org.eclipse.steady:plugin-maven:3.2.5:a2c

During a2c, however, I had the same problem, and this seems being due to the Java version used. When going back from Java 17 to Java 11, the reachability analysis worked.

According to the error messages, it looks like Soot cannot find the modules with JCL classes, that is probably something that changed between Java 11 and 17. To investigate this further requires digging into Soot, maybe they have something documented...

[axidex]

I'm tried using maven, but here is a new problems with bigger project - https://github.com/axidex/test2

[henrikplate]

I debugged into it and do not think they are problematic. The first occurs in a method trying to find the URL of the JAR from which a class was loaded. But since those classes are part of the project, they do not come from a JAR (but the target/classes directory). The second is related and occurs in a method computing the digest of a JAR, which again is not possible because the classes come from a directory. I think both error messages should be changed to warnings (or maybe suppressed altogether).

[axidex]

That means this is builded properly ? -1 it's good or not?