I want to figure out the order of deployment of microservices, i.e. if I'm service A, that depends on B, to make sure B is deployed (B is managed by other team, deploying themselves) Naive way I'm thinking of is to read the build graph, and figure it out, get the toposorted list, and check it against some sort of registry of deployed services how do I do that? (also, is this a good idea?)

seems reasonable. Dependency Analysis Gradle Plugin has some facilities that almost meet your needs

why alter? sounds exactly what i want, no?

or you could fully roll your own and use the

com.autonomousapps:graph-support

package, which has a

Graphs.topological()

function that you can play with

does it matter?

yes

i was thinking just checking against "-api" suffix or something like that specifically

I wrote that task specifically for helping to visualize the local project graph, so it doesn't care about external modules

I see, and I'd then parse that as a string? Or would you suggest some more structured way?

it has a variety of outputs. • gv (graphviz) files • a json output • simple txt files that just list the project paths in topological order

great ill look into it btw how are you doing that? gradle tooling api?

no just standard gradle APIs.

but now you're describing a way where I'm depending on the jar that powers your plugin, not somehow consuming the tasks of that plugin?

but now you're describing a way where I'm depending on the jar that powers your plugin, not somehow consuming the tasks of that plugin?

I think the first thing you should try is apply the plugin and run the task if you find it doesn't meet your needs, some options: 1. If you think you have a generally useful idea, you could contribute it back to the plugin 2. If you think your use-case is too narrow, then you can use an artifact I publish along with the plugin that provides support for what you need

yep will do, sounds most same I'm just thinking about the idea with the lifecycle task way I was naively thinking that the order of execution of the

markedAsApi

tasks will be the toposort

that's kind of clever. Not sure it'll work, but might. You'd have to parse the gradle console output though, so it's not great

yea, regexes will lead to tears

are all your micoservices local to the repo?

lets say no

do they have a known group or groups?

this is a hypothetical future architecture

then you can filter for only local instead

hmm i see

you also have access to the full dep graph here. So if you have to you could crack open the jars and look inside

could I mark such projects with my custom plugin and look for that?

put something in

META-INF

for example

neat however if your library gives me projects, I could interrogate applied plugins, no? sounds faster?

short answer: no

why?

project.pluginManager.hasPlugin("api-marker")

or is that a different project type?

1) the code I'm referring to doesn't give you access to the

project

instance 2) doing what you suggest violates IP

hmm true, but how do you even looks at the graph without violating IP if touching other projects is illegal

it's the dependency graph

yea I probably dont know enough gradle primitives is that the issue is - I hear what you say but cant map it onto gradle apis

I'd suggest cloning the plugin I referenced above and looking at its code. There are a lot of examples there

yep sounds great maybe one freebie before that please, is this api reachable when writing the normalne project build.gradle? or do I have to be a plugin, or rather only reachable from within a plugin subclass

GraphViewBuilder

is internal to my plugin. The

graph-support

lib is public, however. So it depends on what you're asking about

btw I'm playing with

./gradlew :client:projectGraphMain

and it works, but can I also get a graphviz for the whole build?

the closest way to achieve that is to run the task against the "entry point" or highest-level project in your build

which is what, not root build.gradle?

the runtime classpath might be more interesting, but yes

is this api reachable when writing the normalne project build.gradle? or do I have to be a plugin, or rather only reachable from within a plugin subclass

Anything you can do in a plugin you can do in the normal build script too, it's just not too idiomatic to do imperative logic in the build script.