On 9 Aug 2023, at 14:55, Jeff Mesnil <jmesnil@redhat.com> wrote:



On 9 Aug 2023, at 15:42, Eduardo Martins <emartins@redhat.com> wrote:



On 9 Aug 2023, at 12:19, Jeff Mesnil <jmesnil@redhat.com> wrote:

On 9 Aug 2023, at 12:41, Eduardo Martins <emartins@redhat.com> wrote:

Oh I didn’t meant we should only have one solution, was just trying to clarify what you are targeting now. 


You’re right. That’s a good thing to clarify.
My goal with that thread is to make WildFly more accessible and improve its user experience.
Part of that is the tooling (code generator, maven archetype, whatever) but if we do not let users find out and help them get started, all the tooling improvements we are doing are lost to them.

In that sense, I don’t see why we could not create a getting started page *now* with what we have.

My concern is more about us going forward with new archetypes, and in 6 months possibly abandon such direction. 

IMHO We should first learn why Quarkus team opted for a maven plugin instead of archetypes, and plan to go forward on the right direction. If we should not go with archetypes in the future then we could for now:
a) use the existent archetypes

As I mention, they are not a good fit to « get started ».
If an user needs to create a EAR, they are fine but this should not be the introduction to WildFly…

EAR is kind of legacy yet some people still needs it, but yeah not really a good get started resource.


We can discuss the webapp archetype though… Again, starting with JSF and JPA seems a big jump in complexity. If an users does not need them (we can argue about JPA but there is a bunch of backends apps that do not need JSF), we have to tell the users how to remove things and that’s not how a good user story can progress.


Well I believe the idea of this archetype was always to be the starting point of a war packaged app, which is the norm nowadays (as opposed to the EAR), and if JSF and JPA are not that common nowadays we should remove that. 



b) use hello-world quickstart (going in a flow similar to quarkus get started page. 1. curl command to download the Quickstarts, 2. Build hello-world with wildfly server provisioning, 3. Run provisioned server, 4. Access the running app) 

That’s not a great start imho. Once an user has done that, they are stuck with the structure of the Quickstarts and will have to dp extensive work to get a « clean » application from it (without deps to wildfly-quickstart-parent, cleaning up the openshift, provisioned-server, bootable-jar profiles, etc.)
The Quickstarts are a good collection of examples but they are not great to get started…


That was just a quick idea and definitely not fully thought, but an additional point 5. of that "get started" web page procedure, could be a jump to the new app development guide in the works, where the user then creates an app from scratch, and IIRC will be using the standard maven archetypes in such process, cause it targets EAP too. Anyway still just quick thoughts, IMHO what would be of most importance now would be figure out if archetypes is the right direction, cause it won’t be nice to send users now in such direction, and then ask them to abandon such idea.

I don’t know. However the output of their code generator is a Maven project. It would be the same for WildFly.
We can start with a Maven archetype now (Darran’s draft PR is quite close to be ready imho) and update it with a code generator when we have one. You mention you wanted to start this in Q4 and I don’t know the amount of work to create such generator but I don’t want to wait until Q1 2024 or later to improve the user experience of WildFly (and wildly.org).

Totally agree we should improve WFLY users experience now (and all the time), just a bit concerned that we may go in a direction that we may discard in a few months. Please note that while developing and maintaining the archetype is not a big deal, we also need to cover other aspects like web and docs.

That’s great to be able to discuss the direction from the user experience. Could you point to the RFE for the code generator so that we can see what are the other choices that were discussed?

The RFE was pretty much just created last year, and then postponed to Q4, nothing really useful there other than it targets to provide an online tool to create app projects, similar to code.quarkus.io . We discussed it on last 2 F2Fs but no big decisions made there as well.

—E