Project should be refactored to allow gadgets/chains to be generated (and unit tested) with only exactly the exact required dependencies and versions, even in cases where two different gadgets/chains require a different version of the same library (See #16). This should also reduce the likelihood of unintended classes or dependencies accidentally leaking into the payloads.
The already included jboss shrinkwrap should suffice for runtime dependency management. Make sure dependencies for gadget chains can still be bundled in the jar somehow.
It is also a goal to keep the project build and code as simple as possible for people to contribute gadgets/chains.
Option 1: Reflection
Write or use a reflection DSL that can be used by payload generation code that can use gadget classes dynamically instead of using statically linked code.
Something like jOOR might be useful for reflection.
Pros: Simple build process
Cons: Convoluted reflection-based payload generation code
Option 2: Maven/Build Voodoo
Split up project into multi-module with aggregator project to generate all-in-one jar. Gadgets/chains can go into an arbitrary number of separate sub-projects according to any dependency version conflicts.
Pros: Simple, statically linked payload generation code
Cons: Convoluted, splintered build process