introspection.json

[autumn egret]

I sugggest you make it a requirement to get that introspection.json from somewhere. Python (and Elixir) used to be able to make that query if the file wasn't provided, but it's already given to you in modules by the engine, and for publishing the client library, since it can be provided by the DaggerDev module, like this: https://github.com/dagger/dagger/blob/297f72bd35a438499fa524c1c3cd137f049bca8e/.dagger/sdk_python.go#L125. Which in turn calls this: https://github.com/dagger/dagger/blob/297f72bd35a438499fa524c1c3cd137f049bca8e/.dagger/sdk.go#L98

codegen introspect -o schema.json

The advantage is simplification and easier maintenance.

The closest you can get from not building go code is:

dagger query --doc ./cmd/codegen/introspection/introspection.graphql > introspection.json

Or

dagger call -m github.com/helderco/daggerverse/codegen introspect as-json -o introspection.json

[mystic quarry]

I sugggest you make it a requirement to get that introspection.json from somewhere
Yes, it's already how that works. The file can be provided, it's in the case it's not, to keep a nice developer (java sdk developer, not user) experience

the dagger call version might be the easiest one, I'll try that

[autumn egret]

Warning that that module makes a few additions to the result, so it's not entirely the same as the dagger query one, but should be compatible unless you validate the schema.

[autumn egret]

Yeah, Python's GraphQL client library supports making an introspection query out of the box. For the longest time Python's codegen just needed to connect to the server to make that query, but I wanted to simplify. By getting the result from outside, that code could run offline, so it's less dependent and easier to manage. However, you're not necessarily planning on having the Java SDK make that query, so I think the best would be to expose a dagger call introspection -o schema.json function that calls to this: https://github.com/dagger/dagger/blob/297f72bd35a438499fa524c1c3cd137f049bca8e/.dagger/sdk.go#L86

Can you clarify how that makes it easier for a java sdk maintainer?

[mystic quarry]

you can easily run a simple mvn install that will generate the code, package and push it in a local .m2 folder. Basically the thing here is you don't escape the java world

Not yet done, but I'm also looking at building a proper dagger module to work with java/maven (like the Go one) that might also help

[autumn egret]

But then you need Java tooling to develop.

[autumn egret]

Yeah, that's a good idea.

It's a pattern we use for SDKs, to have a "dev" module. Python was the first: https://github.com/dagger/dagger/blob/main/sdk/python/dev/src/python_sdk_dev/main.py

[mystic quarry]

if you are working on the Java sdk, yes. Not mandatory, but it's a nice experience.
If you are creating a java module based on the sdk, you don't need anything from java, all is covered by dagger

[autumn egret]

Having a "dev" module makes it easier for anyone in the team to make some fixes if needed, so it's good to account that not everyone touching an SDK's codebase is a developer in that language. This a particularity of our team because we help maintain several different languages.

There's been discussions around reusing the "runtime" module for that as well, so that you have one Go module for both things, instead of two separate modules.