This project shows a minimal working version of a Gradle project. I’m coming from a Maven background, so a couple of gotchas happened along the path because of that. They are documented in the code and here (if I took the time to write them down).
Trying to use Gradle as new build system, because Maven is a mess with the slightly out of ordinary build requirements for this project.
Although this is an minimalist project, the problem solved is not so easy. The requirements are the following.
- Have a Java ‘java-stuff’ project (pretty standard, nothing fancy)
- Have another project that is based on Jython ‘jython-stuff’, that depends on the artifacts from ‘java-stuff’.
- ‘jython-stuff’ can only be executed if Jython is actually present (the ‘jython-stuff’-build runs primarily on Jython itself).
- ‘jython-stuff’ has additional dependencies, which are resolved via zc.buildout
- Allow the following interaction with ‘jython-stuff’
- shell: Open a shell in the project (this compiles/resolves all required dependencies (including zc.buildout) and opens a Jython shell with an appropriate classpath and sys.path)
- script: Alternatively run a script with the same conditions as when opening a shell.
- Run zc.buildout (the Gradle/Maven for Python) from within the build
- Adding local Maven cache to help with dependency resolution (${user.home}/.m2/repo)
- Transitive dependencies in Maven can be used as compilation dependencies. This doesn’t work with Gradle. Meaning that if you have a dependency on IMPL.jar, which implements (and transitively includes) an API.jar, then you cannot reference the code in API.jar unless you have a dependency declared on it. Makes sense, but is not what Maven gives you.
- All downloads should happen with Ivy. Ivy is extremely flexible and can handle most cases. Use that to download, it will save you trouble in the longtime.
- One problem I discovered is when the actual dependencies downloaded with Ivy are not the ones that you want to depend on. See the ‘downloadJython.gradle’ for a clutch, a proper solution is still outstanding.
- it makes sense to have the local maven repository (~/.m2/repository) added to the lookup path for Ivy, but take care to make it portable (see TODO).