Mavenize Build

[malaverdiere]

Building Soot can be a bit difficult for newcomers. A simpler build process that handles all the dependencies is desirable.

Further, the build process should take in consideration the projected modularization (see #43)

Soot should be built using Maven or Ivy, and the whole software should be buildable from a single command, with no parametrization needed.

[soundmonster]

Unfortunately, Soot seems to depend on not properly maintained software which would have to be mavenized, too. The only dependency which is properly supported is Guava. The rest isn't: Heros, Jasmin, Java-Cup, JastAdd, Polyglot (not sure if needed since JastAdd). I was not even able to building from scratch using Ant, failing to obtain JastAddExtensions (seem to be in a closed SVN repo).

Nevertheless, I would certainly like to see Soot mavenized, too.

[johanneslerch]

I see two challenges that have to be solved: the dependencies that do not use maven and soot itself, which seems to generate code during the build job.

The first challenge can be addressed by a technique described in this blog post: https://devcenter.heroku.com/articles/local-maven-dependencies

For the second, i am not sure if maven plugins exist for the source generating tasks in ant. But it should be possible to wrap the ant-build: http://stackoverflow.com/questions/1456901/how-to-wrap-an-ant-build-with-maven

I currently also fail to build soot using ant, which stops me from trying to apply above techniques. If someone who has a deep understanding of the current build process, modules, and dependencies could assist me with this issue, i would volunteer to elaborate the maven part.

[StevenArzt]

I am actually pretty happy with the current ant-based build system. The problem is not ant, the problem is that we have a lot of rather implicit dependencies on components maintained by other people (mainly JastAdd and its various extensions). Even if we mavenize Soot, we still retain the dependency on JastAdd which is not under our control. Every trick we play for maven (e.g., local repos) would be just a different trick around the very same issue we have now.

For our own continuous integration server, I wrote a shell script that downloads and updates JastAdd and all the other stuff we need before the actual Soot build runs. If people are interested, we can add this script to Soot to automate this part. An alternative would be to add a big JAR file containing JastAdd that we just reference.

[malaverdiere]

Another idea would be to use Ivy in the existing ant build process. One thing that would be cool is that jars can be uploaded to some maven repository (such as ibiblio). It would be nice for people who want to use soot/flowdroid as a library with a dependency management build process such as maven or sbt.

[timtadh]

I actually created a pretty good solution to building soot with apache buildr. It is in my jpdg repository. It could definitely be cleaned up to an included here. Although, to be honest if I had to do it again I would try and see if I could use gradle do to the broader support and easier install.

[StevenArzt]

The worst aspect of Soot dependency management is currently JastAddJ. For all other dependencies, we just need the respective JAR file, but for JastAddJ, we do actually need the source. Given that this front-end is really outdated anyway, we should first get this back into an acceptable state (https://github.com/Sable/soot/issues/300) and make it a normal clear-cut library dependency. As I said, we have no control over the project, but apparently their new version can be compiled into a single JAR file one can just use. Or we switch to something else entirely for parsing Java source files, doesn't matter from the point of dependency management.

[timtadh]

@StevenArzt I have had success hooking into the OpenJDK compiler and getting their AST. It has been about 3 years since I have done it. It wasn't TOO hairy. The big advantage is that since it is the compiler the source is parsed in the "correct" way.