[wildfly-dev] Re: WildFly documentation and UX for galleon packs and layers

Another existing thing that may be relevant -- Harald Pehl's cool model-graph-tools work: https://github.com/model-graph-tools/setup?tab=readme-ov-file I picked that particular link because the README has more of an overview of the various pieces in that github org. We're talking here about expanding the graph. Since I used the word graph and part of what we're discussing is the natural language description of these things, now I'll say GraphRAG and go drink a shot. ;-) On Thu, Mar 27, 2025 at 2:45 AM Jeff Mesnil via wildfly-dev < wildfly-dev(a)lists.jboss.org&gt; wrote: Perhaps this is what you meant, but a general description of what a layer does is fine, and the language for that can touch a bit on resources provided, but it shouldn't try to be complete or overly detailed. I think adding natural language resource descriptions for each feature into layer-spec.xml is too much. It's duplicate content. And it's hard enough to get the original content right! And, if possible tie that with our model reference for the datasource As a practical matter, they must be tied, at least at the time of content generation. Unless we are going to bloat all of our generated Galleon feature spec.xml files with all the resource description content. Or duplicate what wildscribe does. Perhaps duplicating what wildscribe does could make sense for this fp/layer documentation effort, but then we'd be less likely to get proper links. Tangent: https://docs.wildfly.org/35/wildscribe/subsystem/datasources/data-source/... is kind of a bug. That page only exists because we generate a specific ManagementResourceRegistration for 'ExampleDS' to account for any driver-specific runtime attributes it provides. That's fine, but we're missing any wildscribe content for the base datasource=* resource it extends. ^^^ is only a semi-tangent as this is the kind of problem that we can kind of ignore now but which might be harder to ignore if we start linking things together. Best regards, -- Brian Stansberry Principal Architect, Red Hat JBoss EAP WildFly Project Lead He/Him/His