Better out of the box behavior for multiprojects

[mcandre (Andrew)]

When I execute gradle jar at the top level of a multiproject, I expect the resulting artifacts to include the classes from child projects. By default, Gradle does the dumb thing, only including classes from the top-level project.

There is a workaround ( see How to .jar all .class output from all sub-projects into one jar? ), but it’s dumb to have to look this up, when it’s such an obvious thing that Gradle should simply do by default.

Can we fix the default behavior in a future version of Gradle?

[ddimitrov (Dimitar Dimitrov)]

@mcandre

When I execute gradle jar at the top level of a multiproject, I expect the resulting artifacts to include the classes from child projects. By default, Gradle does the dumb thing, only including classes from the top-level project.

I wouldn’t agree that it is dumb. Even ignoring that not all projects are JVM based, assume I have 5 subprojects, 3 of them libraries and 2 of them applications, a jar that bundles all of them would be fairly useless.

Another use case is when some of the artifacts are alternative incompatible implementations of the same interface that are bundled in different configurations to produce multiple versions of the product.

The current way is what most of the people expect. What you are looking for can be trivially accomplished by a plugin, but it doesn’t make sense as a default behavior.

[Karrde (Mark Worger)]

If you’re expecting a single jar then I would suggest that you actually don’t want a multi-project build and instead should be using a single project with multiple configurations.