This message was deleted.

effectively, I’m interested in using a gradle project to compose other gradle projects - rather than write shell scripts or something that isn’t gradle

perhaps have ProjectA publish an artifact to maven repo (which would include versioning, dependency metadata) and have ProjectB consume it?

perhaps have ProjectA publish an artifact to maven repo (which would include versioning, dependency metadata) and have ProjectB consume it?

this is what

./gradlew assembleArtifact

does

is the issue then having to build everything together? If they’re already decoupled via publishing, why do they need to be built together?

is the issue then having to build everything together

yes. this issue is about avoiding a custom scripting tool and being able to leverage Gradle instead of say https://fastlane.tools/ I have a custom job where I build a downstream app and our internal SDK together, I would like this to be a gradle task

To get that capability in Gradle you could use a custom Gradle task that either executes another Gradle build, or uses the Tooling API. Or a shell script to run both (publishing to mavenLocal, for example). Or a CI job that does something similar. Or rethink the coupling on SDK and consumer.

yeah I’m adding a new gradle project that does:

execOperations.exec {
    commandLine(
        "./gradlew",
        ":assembleArtifact",
        "-Ppublish.version=$version"
    )
}

Just kind of wild to have 3 gradle daemons

yea. a bit of a smell. seems like those tasks should either be decoupled, or at a minimum handled outside of Gradle.

I would probably use the tooling API to trigger other builds, not

exec

. I'd say it is at least a bit cleaner. :-)

could you share that feature request? I’d love to have fully isolated builds within the same daemon

Are you sure

GradleBuild

will run within the same daemon?

I have no idea tbh

I actually doubt it

the daemon is typically limited to doing one build at a time (occasionally see “daemon is busy, starting a new daemon” messages or somesuch.

The feature request was actually not mine, it is https://github.com/gradle/gradle/issues/8246

agreed, same here…

So, just to clarifiy I’m using a third gradle project to compose two projects • first project (owned by me) publishes an Sdk • second project (a downstream app, not owned by me) consumes that Sdk This 3rd project that composes the two • owned by me, so it could be merged with the first one. • it builds the downstream app with my sdk If

GradleBuild

stays isolated, then I could use it. But the downstream app internally uses composite builds, as does my sdk. So that might be a blocker?

perhaps change the third gradle project to a simple script. Lots of Gradle overhead just to sequence two things. • <in SDK project> ./gradlew buildAndPublisSdk • <in downstream project> ./gradlew consumeSdkAndDoAmazingThingsWithIt

Does the tooling API provide more efficient access to task output? I have no idea where to get started with that tbh.

access to task output

I’ll be building APKs, and would probably want to copy them into the build directory of my 3rd composing project. Obviously could do this with a

CopySpec

, but there might be something more efficient then executing a

./gradlew buildApk

command every time, and copying

could consider removing permutations; instead of

build the downstream app from our SDKs source, from artifactory, from a git branch

…build the downstream app from a versioned artifact (pass in version as a property), thereby decoupling producer from consumer.

agreed, same here…

But we were wrong actually. I just tried and indeed

GradleBuild

runs in-daemon and thus has to be compatible with the same Gradle version. Using the tooling API, it always runs in a separate daemon and by default uses the Gradle version defined in the wrapper files, so better for unknown sub-builds.

If

GradleBuild

stays isolated, then I could use it. But the downstream app internally uses composite builds, as does my sdk. So that might be a blocker?

Yes, as I said,

GradleBuild

does not support running composite builds right now, see the linked issue above.

Does the tooling API provide more efficient access to task output? I have no idea where to get started with that tbh.

The tooling API is what IDEs also use, so generally said, everything the IDE can do, you can do in your build too, so I'd say yes, you can access task outcome better.

…build the downstream app from a versioned artifact (pass in version as a property), thereby decoupling producer from consumer.

This is what I’m doing. I’m just using that 3rd Gradle project to effective compose these two calls:

# from SDK - it publishes to a local maven folder
./gradlew assembleArtifact -Ppublish.version=99.99.99-SNAPSHOT

# from downstream app
./gradlew :downstream-app:assembleDebug -PSDK_VERSION=99.99.99-SNAPSHOT -PADDITIONAL_MAVEN_REPOSITORIES='/absolutePath/my-sdk/build/artifactory-publishing/artifacts/assembleArtifact'

And note, the above is simplified. I’m just trying to build some wrapper logic to make it all one step. It might include things like checking out a git repo in the future at a specific commit (or if the repo is already checked out, navigate to the desired commit)

I don't think the plugins should harm each other either way

plugin versions are still fully isolated with

GradleBuild

? I guess it doesn’t matter with composite builds