TL:DR; WildFly documentation has not kept pace with the flexibility we added with Galleon feature packs and Glow. How can we improve it? I have been using several WildFly feature packs the last few weeks in which I've not been involved in and I noticed a few improvements we could make to our documentation that would greatly reduce the friction and make for a better developer experience. For a traditional way to use WildFly (donwload the server zip, build your deployments and deploy it), the documentation experience mostly comes from 2 places: * the WildFly model reference[1] that describes what WildFly is providing * the Jakarta EE[2] & MicroProfile[3] APIs that we are using to write the applications However, with the use of Galleon feature packs, the documentation and model reference are no longer captured and deliver to the developers. If I want to use the API X in my applications, what are the feature packs & layers that I need to provision for WildFly? WildFly Glow has introduced a set of rules that binds layers to these APIs. So for example if I'm using the MicroProfile Health API[4], this API is enabled by the "microprofile-config" layer. These rules are only used within WildFly Glow but I think there is values in exposing them to developers. Ideally, when I want to try a new API, I would have liked to answers questions like: * Which layer do I need to provision when I'm using the Langchain4J API? * Which feature pack is providing that layer? * What are the resources contributed by this layer? * What are the layers that provides LLM integrations? * For the ollama layer that I want to use, how can I configure these resources? (I'm using the WildFly AI feature pack but this is just an example of the friction I've encountered) We have all the code in place to answer these questions but they are sprinkled in many Git repositories and you must know what you are looking for to get answers: * Which layer do I need to provision when I'm using the Langchain4J API? => the "ai" layer (as described in https://github.com/wildfly-extras/wildfly-ai-feature-pack/blob/main/ai-fe... ) * Which feature pack is providing that layer? => the "org.wildfly:wildfly-ai-galleon-pack" is providing this layer (as described at https://github.com/wildfly-extras/wildfly-ai-feature-pack/tree/main?tab=r... ) * What are the resources contributed by this layer? => the "ai" spec defines them at https://github.com/wildfly-extras/wildfly-ai-feature-pack/blob/main/ai-fe... but we don't have a generated model reference for them * What are the layers that provides LLM integrations? => they are listed at https://github.com/wildfly-extras/wildfly-ai-feature-pack/tree/main/ai-fe... * For the ollama layer that I want to use, how can I configure these resources? => the spec defines them at https://github.com/wildfly-extras/wildfly-ai-feature-pack/blob/main/ai-fe... but I don’t have their model reference => the default Ollama model is llama3.1:8b and can be configured with the expresion "org.wildfly.ai.ollama.chat.model.name" (using the ORG_WILDFLY_AI_OLLAMA_CHAT_MODEL_NAME env var) or with the OLLAMA_CHAT_MODEL_NAME env var (from https://github.com/wildfly-extras/wildfly-ai-feature-pack/blob/b0a59b9ba6... ) I don't have a strong opinion for where I want to go but looking at what we did with WildFly Glow, we have a strong foundation to capture all these data. The https://github.com/wildfly/wildfly-galleon-feature-packs is a "magical" Git repository that lists for every version of WildFly the feature packs that we provide. From there, we should be able to find the layers that are contributed by these feature packs, the API that they provide and the resources they install. From these resources, we should be able to end up with something very similar to the model reference with the description of the resources, their default values, units, the expressions that can be used to customize them, etc. Ideally, I would like to end with a web site that tells me: * WildFly 35.0.1.Final is supporting LangChain4j with its "org.wildfly:wildfly-ai-galleon-pack" feature pack and its "ai" layer. * This galleon pack is incubating and is subject to changes. * If you want to use Ollama, this galleon pack also provides the ollama-chat-model, ollama-embedding-model, and ollama-streaming-chat-model * The ollama-chat-model has a default temperature of 0.9 that can be customized with the env var ORG_WILDFLY_AI_OLLAMA_CHAT_TEMPERATURE I'm thinking about creating a WildFly proposal to capture these doc/UX improvements as they will be relevant to all the feature packs we are delivering (including WildFly itself) as well as having the tools for user feature packs that are not curated by WildFly Glow. Traditionally we have used WildScribe to generate the Model reference that we publish in our docs but I’m not sure how much can be reused from this top down approach where I want to know which resources are contributed by which layer & galleon pack. What do you think? [1] https://docs.wildfly.org/35/wildscribe/ [2] https://jakarta.ee/specifications/platform/10/apidocs/ [3] https://javadoc.io/doc/org.eclipse.microprofile/microprofile/latest/ [4] https://github.com/wildfly/wildfly/blob/8302c565354934b3a20f3c06abc4759a5... -- Jeff Mesnil Engineer @ Red Hat http://jmesnil.net/

Hi, > On 26 Mar 2025, at 17:14, Jean Francois Denise <jdenise(a)redhat.com&gt; wrote: > > Hi Jeff, > I would like to add the Wildfly Glow documentation[1] to your description. > The doc contains, for each execution context (cloud vs bare-metal), what Glow knows about: > * The feature-packs [2] > * For each layer of each feature-pack, the set of rules that activates it [3]. For example: <prop name="org.wildfly.rule.class" value="dev.langchain4j.*,org.eclipse.microprofile.ai.llm.*"/> > BTW: the documentation for the incubating space was missing, I just enabled it. > > We do generate this information from a maven plugin that inspects the feature-packs content [4]. See, I was not joking when I was saying that the https://github.com/wildfly/wildfly-galleon-feature-packs repo was the magical sauce behind these improvements :) Thanks for reminding me of this documentation. https://docs.wildfly.org/wildfly-galleon-feature-packs/#_supported_galleo... is a valuable source of information that should surface higher in our doc tree. It is valuable not only in the context of WildFly Glow but also for users that wants to know about layers. We should link to it https://docs.wildfly.org/35/Galleon_Guide.html#wildfly_galleon_layers. We could also go one level deeper and documents what each layer provides. For example the "postgresql-datasource” layer should also explains which resources it provides to give a human-reading description of its features at https://github.com/wildfly-extras/wildfly-datasources-galleon-pack/blob/m... .

subsystem at https://docs.wildfly.org/35/wildscribe/subsystem/datasources/data-source/...

That is already a way to answer part of your questions I think. Definitely, we have related snippets of documentation spread out in our existing docs and GitHub repos. I’m now trying to figure out a way to drill down this information in a comprehensive manner.

Jeff -- Jeff Mesnil Engineer @ Red Hat http://jmesnil.net/ _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...