Use of the 'org.wildfly' groupId
by Brian Stansberry
Currently we have a number of different repos publishing artifacts using
the 'org.wildfly' groupId with no further namespacing.
Going forward I don't think we should allow any other new repos to do that.
It leads to administrative hassles, e.g. with setting things up in Nexus.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
1 month, 2 weeks
Applying to Commonhaus
by Brian Stansberry
(project leads -- please be sure to read the 'If you maintain' part below.)
I'd like to take the next step in transitioning the WildFly project to a
vendor-neutral foundation by applying to Commonhaus. We've been talking
about this for quite a while, gathering input, and the consensus I've seen
has been that Commonhaus is the best option. I think Commonhaus’ guiding
principles around honoring project and community identity and offering
guidance instead of mandates, with its “community-first” governance model,
make it the best for WildFly.
The process of applying is covered at
https://github.com/commonhaus/foundation/discussions/new?category=joining....
I'm hoping to initiate a discussion by the end of this week. That entails
filling out the issue template linked above and sending up a PR with the
necessary information.
Note that I'll be applying for the 'WildFly' project, which is somewhat
nebulously defined. A simplistic, and incomplete boundary is that it covers
the non-archived projects hosted in the 'wildfly' GitHub organization. It
will also cover non-archived projects in the 'wildfly-extras' GitHub org,
except, perhaps:
creaper
sunstone
wildfly-camel
wildfly-camel-book
wildfly-camel-examples
It can cover those as well, but I want to check with the respective project
maintainers that that's what they want.
It will also cover a few repos in the 'jboss' and 'jbossas' Github orgs
that really should be moved to the 'wildfly' org.
If you maintain a project that is not in one of the categories above but
that you believe fits into WildFly project governance, or could fit into a
sensibly modified WildFly governance, and you'd like it to be considered
part of this application, please let me know. If you want to discuss it
here, that's fine.
Some (not definitive) considerations as to whether a project 'fits'
* Is it somehow 'WildFly' branded, or perhaps 'JBoss' branded as a leftover
from 'JBoss AS'?
* How much is it used outside of the various WildFly deliverables?
Thanks!
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
11 months, 1 week
WildFly 36 Schedule
by Brian Stansberry
Hello,
Work is well underway on WildFly 36. These are the dates we're planning for
releasing 36 Beta and Final:
36 Beta
Freeze (PRs ready deadline) - Wed Mar 19
Tag/deploy of main WildFly bits - Wed Mar 26
Other deliverables, announcement - Thu Mar 27
36 Final
Freeze (PRs ready deadline) - Wed Apr 2
Complete merging - Mon Apr 7
Buffer day - Tue Apr 8
Tag/deploy of main WildFly bits - Wed Apr 9
Other deliverables, announcement - Thu Apr 10
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
1 year
WildFly documentation and UX for galleon packs and layers
by Jeff Mesnil
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/
1 year
WildFly Mini Conference 2025 is Today – Join Us Live!
by Ranabir Chakraborty
Hello everyone,
The *WildFly Mini Conference 2025* is happening today! Join us as we
explore the latest advancements in *WildFly, Jakarta EE, and Automation*
with expert-led sessions and community discussions.
*Date:* Tuesday, March 25, 2025
*Time:* 14:00 - 18:00 UTC
*Live stream:* https://www.youtube.com/live/d8IExBP7rxw
Make sure to *click "Notify me"* on YouTube to get a reminder when the
event goes live.
*Agenda Highlights:*
-
Quick Prototyping with WildFly
-
WildFly Day One Operations with Ansible Automation
-
Everything About Jakarta EE TCKs in 20 Minutes
-
WildFly in a Vendor-Neutral Foundation
-
WildFly AI Feature Pack: Deploying an MCP Server
Don’t miss this opportunity to engage with the WildFly community and learn
from industry experts. For more details, visit:
https://www.wildfly.org/events/wmc-202503.html. We look forward to seeing
you there!
~
*Ranabir Chakraborty*
1 year
