Hi Brian,

thank-you for your feedback.

I first thought that having 2 feature-packs would provide less confusion. The cloud feature-pack exposes a lot of env variables that will get ignored with bootable JAR. So my concern was more at the doc level.

After having rethought at it, having a single feature-pack, as you mentioned, should be a better approach.  Simpler to maintain, should avoid fp explosion and create a simpler User experience.

Having the existing cloud fp to work for bootable JAR would imply:

• The bash scripts installed by default will not break bootable JAR. They are ignored (we already ignore some files that get provisioned such as standalone launch scripts, some tools script). We would be able to exclude them at provisioning time for bootable JAR packaging but it would be not mandatory.
• We are introducing a new JBoss Modules module specific for Bootable JAR, that we could see installed in all cases even if not used in a non bootable JAR case (a very small module).  We would be able to exclude it at provisioning time for nominal server installation but it would be not mandatory.

So in the end we should be able to use the cloud feature-pack for both packaging without having to mandatorily adjust the provisioning configuration. The provisioning configuration could be adjusted to exclude some packages (bash scripts or bootable JAR specific JBoss Modules module) for optimal provisioned content.

I am going to revisit the proposal to reflect this approach.

From: Brian Stansberry <bstansbe@redhat.com>
Date: Wednesday, 6 August 2025 at 00:23
To: Jean Francois Denise <jdenise@redhat.com>
Cc: WildFly Dev <wildfly-dev@lists.jboss.org>
Subject: Re: [wildfly-dev] [proposal] WildFly Maven Plugin, package bootable JAR for the cloud

Sent from Outlook for Mac

Is there a way we can make this work with wildfly-cloud-feature-pack?

It seems like this new FP and the existing one share a lot of overlap, but then beyond the shared stuff for bootable jar a bit more stuff is needed and for the s2i use case a bunch of incorrect-for-bootable jar stuff is installed.

That kind of feels like layers.

To be fair, providing 1 feature pack and asking users to configure it for the desired target might be more of a burden to them than providing 2 FPs. But two FPs does seem confusing. It also increases our cost of delivery.

This is a bit of a tangent, but for sure we are going to need to adapt Galleon so a FP can base on one of a set of compatible alternatives, not be fixed to one. Dual mode for EE 10 and 11 will mean different flavors of wildfly-ee, and we can't have that result in needing 2 of every other FP we produce.

On Wed, Jul 30, 2025 at 10:16 AM Jean Francois Denise via wildfly-dev <wildfly-dev@lists.jboss.org> wrote:

Hi,

I’ve created a proposal[1] to package a WildFly Bootable JAR for the cloud when using the WildFly Maven Plugin (we are currently packaging a bootable JAR for bare-metal only). 

I’m looking for a feature team to work on this proposal.

I would also need an outside perspective to fully form the team.

Best regards,

JF

[1] https://github.com/wildfly/wildfly-proposals/pull/748

_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@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/UEWT3QQF7AUNXZTQASS77CDC2LNWR53U/

--

Brian Stansberry

Architect, JBoss EAP

WildFly Project Lead

He/Him/His