Future of Composite builds


(Crazyjavahacking) #1

Hi,

What is the future of composite builds? There were plans to extend the functionalities and remove the restrictions, but it looks like they were not changed that much after Gradle 3.1.

Especially the restrictions of not being able to include an already composite build and API differences when depending on a task from a composite are in question.

Thanks,
Martin


(uklance) #2

You might be interested in the workarounds mentioned here


(Daniel Svojanovský) #3

Hi,

personally, I think that the bigger issue is that you can’t use substitute specific configurations and/or use classifiers. That effectivelly means that you’re limited to default configuration with default jar file.


(Sterling Greene) #4

We are doing things, but it’s mostly under the covers work to support some other features.

Gradle 4.1 fixed some issues/restrictions.
Gradle 4.3/4.4 had some internal changes.

I think we’re likely to address some issues with using composite builds with plugins {} and make it so you can run tasks from an included build from the command-line before tackling nested composites/composite-of-composites. Although, we’ve made some changes to prepare for that.

We’re not likely to address this directly. We’re going to strengthen the way you can describe publications of a project so you don’t need to rely on classifiers and configurations.