"Slim-JAR" from CordApp project (for RPC/re-use outside of Corda)

[adnklauser]

We are currently programming against Corda 4 and we feel that the way the cordapp plugin achieves its goal makes our gradle setup unnecessarily bloated.

Expected

We maintain our flows/contracts/states in one gradle project. We can configure this gradle project to produce

• a CordApp (semi-fat JAR) for deployment in the network
• a traditional (slim) JAR that other gradle projects can consume to trigger the flows that our CordApp offers via RPC
• consumers of the traditional JAR can fetch the slim JAR from a maven repository.
• The CordApp and slim JAR have the same artifact name, but different qualifiers

Actual

• The cordapp plugin 'hijacks' the jar task that the java library plugin has set up. This means that if we (corda users) want to have a "normal" jar task, we have to re-implement java library plugin functionality to create an "unmodified" jar task.
• The cordapp plugin manipulates all generated Maven POMs (injecting the DelegatedPom/FilteredPom). This means that consumers of the slim JAR won't have dependency information and need to specify transitive dependencies manually.

Workaround

Naturally, we can set up a second gradle project that produces the slim "client"/"api" JAR:

• The "api" JAR contains our contract/state/flows. It's normal Java library and gets consumed by code that communicates with the Corda node via RPC
• A separate "cordapp" project contains no code and just references the "api" JAR to produce a semi-fat CordApp JAR.

Drawbacks of the workaround:

• Two distinct artifact names
• More complex project model

Ideas

CordApp feels a bit like a WAR/EAR. There is a CordApp-specific manifest file and it contains its dependencies (albeit unpacked).

Would be an option to structure the CordappPlugin more like the WarPlugin so that it configures a type: CordApp task (subclass of Jar) that is independent of any jar task configured by the JavaLibraryPlugin?

As for the generated Maven POM, it should be possible to control the POM that gets used via the MavenPublication.

[soudmaijer]

@adnklauser did you ever managed to work around this issue?