8:44 a.m.
By the way, if the current webapp and ear archetypes are not good starting points then we
should fix that right now.
—E
On 9 Aug 2023, at 14:42, Eduardo Martins <emartins(a)redhat.com>
wrote:
> On 9 Aug 2023, at 12:19, Jeff Mesnil <jmesnil(a)redhat.com> wrote:
>
> On 9 Aug 2023, at 12:41, Eduardo Martins <emartins(a)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
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)
>
>> Something worth mentioning is that I am not sure about the need for an archetype,
which would require us to go after new product deliverables,
>
>
> I’m not sure what you mean here. WildFly already has 3 archetypes that are released
every time.
We don’t have EAP archetypes tho, that’s what I meant with needing new product
deliverables.
> Unfortunately none of them are a good starting point:
>
> * wildfly-subsystem-archetype generates a WildFly subsystem
> -> it’s out of scope and targets WildFLy developers, not WildFly users
> * wildfly-jakartaee-ear-archetype generate a EAR project
> -> Users should get started with a WAR and move to an EAR when their application
is sufficiently complex to require them.
> * wildfly-jakartaee-webapp-archetype
> -> This one could be a starting point but I agree with Darran that it’s not simple
enough to get started. It uses also JSF and JPA (with H2 as the default database?). The
goal of getting started is that the user can build on top of it. If we use that one, we
have to ask the users to remove things and that’s a poor UX.
>
>> maybe investigate what is behind the scenes on their getting started, I don’t see
maven being used, at least directly.
>
> 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.
—E