6:35 p.m.
Hi,
We are evaluating how we could improve the user experience for using WildFly and one of
the idea is to create a « Get Started » page on wildfly.org <http://wildfly.org/>
that would be an entry point for users that wants to try WildFly.
This would be useful not only for new users (that have no previous knowledge of WildFly)
but also existing users to let them understand the more recent ways to use WildFly.
The expectation for this page would be simple:
* no knowledge of WildFly required
* Few prerequisites:
* Java & Maven installed
* Few steps:
* Step 1: create a Maven project (using WildFly archetypes, more on that below)
* Step 2: run mvn package
* Step 3: run ./targer/server/bin/standalone.sh
* Step 4: verify the application is up and running
* Next steps
* the page should link to next logical steps after getting started with WildFly (eg
deploy on Kubernetes, secure WildFly, etc.)
This page would provide a good user experience and rely on the WildFly archetype to
bootstrap all the « plumbing » that needs to be done to setup WildFly so that the users
can focus on "their » code.
We already have WildFly archetypes[1] but there are opportunities for a simpler one which
focus on that user experience.
Darran is already working on such one[2] that takes advantage of the wildfly-maven-plugin
to provision WildFly so that everything is controlled from the project pom.xml
Having a good archetype would also make sure that this "getting started" page is
always up to date with the latest release of WildFly (as we update the archetype for every
new release of WildFly).
For a quick review of Darran’s PR[3], we are not far from being able to release it and
build on top of it for this « get started » page.
We can already start working on this page and create its shell while polishing up the
archetype.
What do you think?
Best regards,
jeff
[1] https://mvnrepository.com/artifact/org.wildfly.archetype
[2] https://issues.redhat.com/browse/WFLY-17651
[3] https://github.com/wildfly/wildfly-archetypes/pull/26
<https://github.com/wildfly/wildfly-archetypes/pull/26/commits/16a596b6d26...
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
7:04 p.m.
A little more background to the ideas behind the archetype.
I was aiming for just enough to have something running a user can call and
have as the starting point for their project. A rest endpoint with a very
simple page to call it felt like just enough. The user can then proceed
with their own development whilst not having to unravel a lot of unrelated
content in the starting project.
This would then upen the path for future user story related content how to
go from this basic project to some other task so our user stories can
become related getting from step A to B with this project being step A for
many follow on stories.
On Wed, Aug 9, 2023 at 10:35 AM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
Hi,
We are evaluating how we could improve the user experience for using
WildFly and one of the idea is to create a « Get Started » page on
wildfly.org that would be an entry point for users that wants to try
WildFly.
This would be useful not only for new users (that have no previous
knowledge of WildFly) but also existing users to let them understand the
more recent ways to use WildFly.
The expectation for this page would be simple:
* no knowledge of WildFly required
* Few prerequisites:
* Java & Maven installed
* Few steps:
* Step 1: create a Maven project (using WildFly archetypes, more on that
below)
* Step 2: run mvn package
* Step 3: run ./targer/server/bin/standalone.sh
* Step 4: verify the application is up and running
* Next steps
* the page should link to next logical steps after getting started with
WildFly (eg deploy on Kubernetes, secure WildFly, etc.)
This page would provide a good user experience and rely on the WildFly
archetype to bootstrap all the « plumbing » that needs to be done to setup
WildFly so that the users can focus on "their » code.
We already have WildFly archetypes[1] but there are opportunities for a
simpler one which focus on that user experience.
Darran is already working on such one[2] that takes advantage of the
wildfly-maven-plugin to provision WildFly so that everything is controlled
from the project pom.xml
Having a good archetype would also make sure that this "getting started"
page is always up to date with the latest release of WildFly (as we update
the archetype for every new release of WildFly).
For a quick review of Darran’s PR[3], we are not far from being able to
release it and build on top of it for this « get started » page.
We can already start working on this page and create its shell while
polishing up the archetype.
What do you think?
Best regards,
jeff
[1] https://mvnrepository.com/artifact/org.wildfly.archetype
[2] https://issues.redhat.com/browse/WFLY-17651
[3] https://github.com/wildfly/wildfly-archetypes/pull/26
<https://github.com/wildfly/wildfly-archetypes/pull/26/commits/16a596b6d26...
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
7:12 p.m.
You mean something similar to https://quarkus.io/get-started/ ?
We have something different planned too (on a RFE) but I didn’t had the
chance yet to look after that, in short something similar to
https://code.quarkus.io where a website and a maven plugin is used instead
of cli and archetype, allowing better functionality and interaction towards
building the Maven project. I plan to start looking at this Q4.
On Wed, 9 Aug 2023 at 11:05, Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
A little more background to the ideas behind the archetype.
I was aiming for just enough to have something running a user can call and
have as the starting point for their project. A rest endpoint with a very
simple page to call it felt like just enough. The user can then proceed
with their own development whilst not having to unravel a lot of unrelated
content in the starting project.
This would then upen the path for future user story related content how to
go from this basic project to some other task so our user stories can
become related getting from step A to B with this project being step A for
many follow on stories.
On Wed, Aug 9, 2023 at 10:35 AM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
> Hi,
>
> We are evaluating how we could improve the user experience for using
> WildFly and one of the idea is to create a « Get Started » page on
> wildfly.org that would be an entry point for users that wants to try
> WildFly.
>
> This would be useful not only for new users (that have no previous
> knowledge of WildFly) but also existing users to let them understand the
> more recent ways to use WildFly.
>
> The expectation for this page would be simple:
>
> * no knowledge of WildFly required
> * Few prerequisites:
> * Java & Maven installed
> * Few steps:
> * Step 1: create a Maven project (using WildFly archetypes, more on
> that below)
> * Step 2: run mvn package
> * Step 3: run ./targer/server/bin/standalone.sh
> * Step 4: verify the application is up and running
> * Next steps
> * the page should link to next logical steps after getting started with
> WildFly (eg deploy on Kubernetes, secure WildFly, etc.)
>
> This page would provide a good user experience and rely on the WildFly
> archetype to bootstrap all the « plumbing » that needs to be done to setup
> WildFly so that the users can focus on "their » code.
>
> We already have WildFly archetypes[1] but there are opportunities for a
> simpler one which focus on that user experience.
> Darran is already working on such one[2] that takes advantage of the
> wildfly-maven-plugin to provision WildFly so that everything is controlled
> from the project pom.xml
>
> Having a good archetype would also make sure that this "getting started"
> page is always up to date with the latest release of WildFly (as we update
> the archetype for every new release of WildFly).
> For a quick review of Darran’s PR[3], we are not far from being able to
> release it and build on top of it for this « get started » page.
> We can already start working on this page and create its shell while
> polishing up the archetype.
>
> What do you think?
>
> Best regards,
> jeff
>
>
> [1] https://mvnrepository.com/artifact/org.wildfly.archetype
> [2] https://issues.redhat.com/browse/WFLY-17651
> [3] https://github.com/wildfly/wildfly-archetypes/pull/26
>
<https://github.com/wildfly/wildfly-archetypes/pull/26/commits/16a596b6d26...
> --
> Jeff Mesnil
> Engineer @ Red Hat JBoss EAP
> http://jmesnil.net/
>
> _______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
7:31 p.m.
On 9 Aug 2023, at 12:12, Eduardo Martins <emartins(a)redhat.com>
wrote:
You mean something similar to https://quarkus.io/get-started/ ?
Kind of. A single page that would show and tell what I need to do to run a Jakarta EE
application on WildFly.
We have something different planned too (on a RFE) but I didn’t had
the chance yet to look after that, in short something similar to
https://code.quarkus.io <https://code.quarkus.io/> where a website and a maven
plugin is used instead of cli and archetype, allowing better functionality and interaction
towards building the Maven project. I plan to start looking at this Q4.
That’s not exclusive.
Even if we have a code generator instead of a Maven archetype, we still need a
"getting started page » as an entry point.
We can start building this page based on our archetypes and update it whenever we have a
code generator.
I suspect than a lot of choices we will make for this user experience could influence what
we could achieve with a code generator.
Best regards,
Jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
7:41 p.m.
Oh I didn’t meant we should only have one solution, was just trying to
clarify what you are targeting now.
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,
maybe investigate what is behind the scenes on their getting started, I
don’t see maven being used, at least directly.
On Wed, 9 Aug 2023 at 11:32, Jeff Mesnil <jmesnil(a)redhat.com> wrote:
On 9 Aug 2023, at 12:12, Eduardo Martins <emartins(a)redhat.com> wrote:
You mean something similar to https://quarkus.io/get-started/ ?
Kind of. A single page that would show and tell what I need to do to run a
Jakarta EE application on WildFly.
We have something different planned too (on a RFE) but I didn’t had the
chance yet to look after that, in short something similar to
https://code.quarkus.io where a website and a maven plugin is used
instead of cli and archetype, allowing better functionality and interaction
towards building the Maven project. I plan to start looking at this Q4.
That’s not exclusive.
Even if we have a code generator instead of a Maven archetype, we still
need a "getting started page » as an entry point.
We can start building this page based on our archetypes and update it
whenever we have a code generator.
I suspect than a lot of choices we will make for this user experience
could influence what we could achieve with a code generator.
Best regards,
Jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
8:19 p.m.
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.
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.
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).
Best regards,
Jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
10:42 p.m.
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
10:44 p.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
10:55 p.m.
On 9 Aug 2023, at 15: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
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…
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.
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…
> 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?
Jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
11:17 p.m.
On 9 Aug 2023, at 14:55, Jeff Mesnil <jmesnil(a)redhat.com>
wrote:
> On 9 Aug 2023, at 15: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
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 <http://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 <http://code.quarkus.io/> . We discussed it on last 2
F2Fs but no big decisions made there as well.
—E
11:45 p.m.
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 think that the archetypes are the important piece here.
They are just a way to generate a clean, valid and complete Maven project to run a Jakarta
EE application on WildFly.
An user would use the archetype once to bootstrap their app and then they no longer needs
anything from it.
If/when we have a code launcher that does that, the output will be the same: a clean,
valid and complete Maven project to run a Jakarta EE application on WildFly.
Releasing a code launcher should not (and MUST not) invalidate any Maven projects that
were created by another mechanism.
Jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
11:50 p.m.
On Wed, Aug 9, 2023 at 3:45 PM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
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 think that the archetypes are the important piece here.
They are just a way to generate a clean, valid and complete Maven project
to run a Jakarta EE application on WildFly.
An user would use the archetype once to bootstrap their app and then they
no longer needs anything from it.
If/when we have a code launcher that does that, the output will be the
same: a clean, valid and complete Maven project to run a Jakarta EE
application on WildFly.
+1 the key to both of these is that in a very short period of time the user
has gone from zero to having their own project they can now continue their
development on. The proposed archetype is also very simple so as a
starting point it should keep maintenance requirements down.
Releasing a code launcher should not (and MUST not) invalidate any Maven
projects that were created by another mechanism.
Jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
11:52 p.m.
FYI I was not referring to code.quarks.io full abilities, but only to the
functionality where you fill some app metadata fields, and enable some
check marks wrt app APIs/features needed, and a maven project is generated,
something that IIRC is not done using archetypes.
On Wed, 9 Aug 2023 at 15:45, Jeff Mesnil <jmesnil(a)redhat.com> wrote:
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 think that the archetypes are the important piece here.
They are just a way to generate a clean, valid and complete Maven project
to run a Jakarta EE application on WildFly.
An user would use the archetype once to bootstrap their app and then they
no longer needs anything from it.
If/when we have a code launcher that does that, the output will be the
same: a clean, valid and complete Maven project to run a Jakarta EE
application on WildFly.
Releasing a code launcher should not (and MUST not) invalidate any Maven
projects that were created by another mechanism.
Jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
10:43 p.m.
On Wed, Aug 9, 2023 at 6:20 AM 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.
Sure, iteration is good.
How will this fit into the wildfly.org landing page? That's something to
have a clear idea of from the start, as the true 'getting started' point is
the landing page.
> 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.
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).
Best regards,
Jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
11:06 p.m.
On 9 Aug 2023, at 15:43, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
On Wed, Aug 9, 2023 at 6:20 AM 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.
Sure, iteration is good.
How will this fit into the wildfly.org landing page? That's something to have a
clear idea of from the start, as the true 'getting started' point is the landing
page.
When I go to wildfly.org, ideally, I’d like to get a « Get Started » link in the menu at
the top.
I’d get rid of the « Home » link as it duplicates the WildFly icon (and it’s a well-known
idiomatic pattern to have the icon at the top-left of the page being a link to the home
page).
So the top of home page of wildfly.org would look like
| "icon » |News| |About| |Contribute| |Get Started| |Docs| |CVE Reporting| |Fork|
I’d also remove the |Downloads| page as it is a visible button on the home page.
This « get started » page would be a starting point but it might not be sufficient for
more complex use cases (eg using domain mode). However once the user has follow the
instructions to get WildFly up and running, we could have a section with Next steps. One
of these could be « there are other way to install WildFly (zip, galleon, bootable jar »,
please consulter our installation guide at
https://docs.wildfly.org/latest/Installation_Guide.html to learn more about them ».
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
11:51 p.m.
On Wed, Aug 9, 2023 at 9:07 AM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
> On 9 Aug 2023, at 15:43, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>
>
>
> On Wed, Aug 9, 2023 at 6:20 AM 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.
>
> Sure, iteration is good.
>
> How will this fit into the wildfly.org landing page? That's something
to have a clear idea of from the start, as the true 'getting started' point
is the landing page.
When I go to wildfly.org, ideally, I’d like to get a « Get Started » link
in the menu at the top.
I’d get rid of the « Home » link as it duplicates the WildFly icon (and
it’s a well-known idiomatic pattern to have the icon at the top-left of the
page being a link to the home page).
+1
So the top of home page of wildfly.org would look like
| "icon » |News| |About| |Contribute| |Get Started| |Docs| |CVE
Reporting| |Fork|
Limiting links to this to the header might be ok for the very first
iteration, but I think ultimately this would alter the main body of the
page. Right now we kind of emphasize downloads, and next we link to
github, docs and the forum.
Also, I noticed that in the header the Fork link is always emphasized with
a box. I think Get Started is a better choice.
I’d also remove the |Downloads| page as it is a visible button on the home
page.
I don't want to get too into the weeds but I want to point out this is a
common header on all pages, and changing it per page starts to open a can
of worms.
This « get started » page would be a starting point but it might not
be
sufficient for more complex use cases (eg using domain mode). However once
the user has follow the instructions to get WildFly up and running, we
could have a section with Next steps. One of these could be « there are
other way to install WildFly (zip, galleon, bootable jar », please
consulter our installation guide at
https://docs.wildfly.org/latest/Installation_Guide.html to learn more
about them ».
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
12:41 a.m.
I did a quick & dirty job to give an idea of this get started page:
http://jmesnil.github.io/wildfly.org/
I’m not telling anything more. If the UX is good, it should be clear from our home page
:)
Best regards,
Jeff
On 9 Aug 2023, at 16:51, Brian Stansberry
<brian.stansberry(a)redhat.com> wrote:
On Wed, Aug 9, 2023 at 9:07 AM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
> On 9 Aug 2023, at 15:43, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>
>
>
> On Wed, Aug 9, 2023 at 6:20 AM 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.
>
> Sure, iteration is good.
>
> How will this fit into the wildfly.org landing page? That's something to have a
clear idea of from the start, as the true 'getting started' point is the landing
page.
When I go to wildfly.org, ideally, I’d like to get a « Get Started » link in the menu at
the top.
I’d get rid of the « Home » link as it duplicates the WildFly icon (and it’s a well-known
idiomatic pattern to have the icon at the top-left of the page being a link to the home
page).
+1 So the top of home page of wildfly.org would look like
| "icon » |News| |About| |Contribute| |Get Started| |Docs| |CVE Reporting|
|Fork|
Limiting links to this to the header might be ok for the very first iteration, but I
think ultimately this would alter the main body of the page. Right now we kind of
emphasize downloads, and next we link to github, docs and the forum.
Also, I noticed that in the header the Fork link is always emphasized with a box. I think
Get Started is a better choice.
I’d also remove the |Downloads| page as it is a visible button on the home page.
I don't want to get too into the weeds but I want to point out this is a common
header on all pages, and changing it per page starts to open a can of worms.
This « get started » page would be a starting point but it might not be sufficient for
more complex use cases (eg using domain mode). However once the user has follow the
instructions to get WildFly up and running, we could have a section with Next steps. One
of these could be « there are other way to install WildFly (zip, galleon, bootable jar »,
please consulter our installation guide at
https://docs.wildfly.org/latest/Installation_Guide.html to learn more about them ».
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
12:53 a.m.
I would go bigger 😁
How about replacing "WildFly 29 Final is now available" with "Get started
using WildFly 29"
On the getting started page itself, maybe defaulting to collapsed but
possible something that can be expanded to show expanded output?
Maybe this is other content for follow up to again keep this page clean but
something to highlight the key components in the app they just created.
On Wed, Aug 9, 2023 at 4:42 PM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
I did a quick & dirty job to give an idea of this get started
page:
http://jmesnil.github.io/wildfly.org/
I’m not telling anything more. If the UX is good, it should be clear from
our home page :)
Best regards,
Jeff
> On 9 Aug 2023, at 16:51, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
>
>
>
> On Wed, Aug 9, 2023 at 9:07 AM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
>
>
> > On 9 Aug 2023, at 15:43, Brian Stansberry <brian.stansberry(a)redhat.com>
wrote:
> >
> >
> >
> > On Wed, Aug 9, 2023 at 6:20 AM 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.
> >
> > Sure, iteration is good.
> >
> > How will this fit into the wildfly.org landing page? That's
something to have a clear idea of from the start, as the true 'getting
started' point is the landing page.
>
>
> When I go to wildfly.org, ideally, I’d like to get a « Get Started »
link in the menu at the top.
>
> I’d get rid of the « Home » link as it duplicates the WildFly icon (and
it’s a well-known idiomatic pattern to have the icon at the top-left of the
page being a link to the home page).
>
> +1 So the top of home page of wildfly.org would look like
>
> | "icon » |News| |About| |Contribute| |Get Started| |Docs| |CVE
Reporting| |Fork|
>
>
> Limiting links to this to the header might be ok for the very first
iteration, but I think ultimately this would alter the main body of the
page. Right now we kind of emphasize downloads, and next we link to
github, docs and the forum.
>
> Also, I noticed that in the header the Fork link is always emphasized
with a box. I think Get Started is a better choice.
>
> I’d also remove the |Downloads| page as it is a visible button on the
home page.
>
> I don't want to get too into the weeds but I want to point out this is a
common header on all pages, and changing it per page starts to open a can
of worms.
>
>
> This « get started » page would be a starting point but it might not be
sufficient for more complex use cases (eg using domain mode). However once
the user has follow the instructions to get WildFly up and running, we
could have a section with Next steps. One of these could be « there are
other way to install WildFly (zip, galleon, bootable jar », please
consulter our installation guide at
https://docs.wildfly.org/latest/Installation_Guide.html to learn more
about them ».
>
>
>
>
> --
> Jeff Mesnil
> Engineer @ Red Hat JBoss EAP
> http://jmesnil.net/
>
>
>
> --
> Brian Stansberry
> Principal Architect, Red Hat JBoss EAP
> He/Him/His
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
1:27 a.m.
On 9 Aug 2023, at 17:53, Darran Lofthouse
<darran.lofthouse(a)jboss.com> wrote:
I would go bigger 😁
My design-fu is lacking but I try :)
http://jmesnil.github.io/wildfly.org/
The goal of that thread was to bootstrap the conversation.
The good thing is that there is a pretty strong agreement that this « get started » page
would be a good thing to add.
We have a great app server, a great maven plugin that lets the user controls everything
from their applications.
We are missing a step to help them bootstrap « their » code. Darran’s archetype is very
close to be usable right now. This does not prevent to explore other advanced tooling in
the future. All we are doing is let users know how to use our software (server + maven
plugin) that is available now.
Before doing any further work (that’s more that I was anticipated to do this morning), we
can maybe agree on the changes we want to make on wildfly.org <http://wildfly.org/>
homepage and the outline of this get started page.
Best regards,
Jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
1:30 a.m.
On Wed, Aug 9, 2023 at 5:28 PM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
> On 9 Aug 2023, at 17:53, Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
>
> I would go bigger 😁
My design-fu is lacking but I try :)
http://jmesnil.github.io/wildfly.org/
I like this one, logically following the flow of the page getting started
is the first thing they come to.
The goal of that thread was to bootstrap the conversation.
The good thing is that there is a pretty strong agreement that this « get
started » page would be a good thing to add.
We have a great app server, a great maven plugin that lets the user
controls everything from their applications.
We are missing a step to help them bootstrap « their » code. Darran’s
archetype is very close to be usable right now. This does not prevent to
explore other advanced tooling in the future. All we are doing is let users
know how to use our software (server + maven plugin) that is available now.
Before doing any further work (that’s more that I was anticipated to do
this morning), we can maybe agree on the changes we want to make on
wildfly.org <http://wildfly.org/> homepage and the outline of this get
started page.
Best regards,
Jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
11:10 p.m.
Hello Jeff,
A few years back at the time of WildFly 24, I have written an article about
"Getting started with WildFly"[1] which is currently on opensource.com,
Though we had several updates and also the same with jdk and maven
versions, but the content is still somewhat similar. Just from a
content point of view, maybe it can help us with a simple getting
started. Let me know if I can help with the content.
[1] https://opensource.com/article/21/7/wildfly
~
*Ranabir Chakraborty*
Software Engineer (JBoss SET)
<https://red.ht/sig>
On Wed, Aug 9, 2023 at 3:07 PM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
Hi,
We are evaluating how we could improve the user experience for using
WildFly and one of the idea is to create a « Get Started » page on
wildfly.org that would be an entry point for users that wants to try
WildFly.
This would be useful not only for new users (that have no previous
knowledge of WildFly) but also existing users to let them understand the
more recent ways to use WildFly.
The expectation for this page would be simple:
* no knowledge of WildFly required
* Few prerequisites:
* Java & Maven installed
* Few steps:
* Step 1: create a Maven project (using WildFly archetypes, more on that
below)
* Step 2: run mvn package
* Step 3: run ./targer/server/bin/standalone.sh
* Step 4: verify the application is up and running
* Next steps
* the page should link to next logical steps after getting started with
WildFly (eg deploy on Kubernetes, secure WildFly, etc.)
This page would provide a good user experience and rely on the WildFly
archetype to bootstrap all the « plumbing » that needs to be done to setup
WildFly so that the users can focus on "their » code.
We already have WildFly archetypes[1] but there are opportunities for a
simpler one which focus on that user experience.
Darran is already working on such one[2] that takes advantage of the
wildfly-maven-plugin to provision WildFly so that everything is controlled
from the project pom.xml
Having a good archetype would also make sure that this "getting started"
page is always up to date with the latest release of WildFly (as we update
the archetype for every new release of WildFly).
For a quick review of Darran’s PR[3], we are not far from being able to
release it and build on top of it for this « get started » page.
We can already start working on this page and create its shell while
polishing up the archetype.
What do you think?
Best regards,
jeff
[1] https://mvnrepository.com/artifact/org.wildfly.archetype
[2] https://issues.redhat.com/browse/WFLY-17651
[3] https://github.com/wildfly/wildfly-archetypes/pull/26
<https://github.com/wildfly/wildfly-archetypes/pull/26/commits/16a596b6d26...
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
11:17 p.m.
Some of the aims I had with the archetype were:
- Removing the need to install WildFly
- Being able to have a new project running and in a container in less
that 120 seconds (excluding maven download times) starting with just Java
and Maven installed locally.
- Eliminating any configuration of the application server just to get
started.
- Leaving the user with a local project that they can start their own
development straight away without needing to unravel anything added they
don't need.
On Wed, Aug 9, 2023 at 3:10 PM Ranabir Chakraborty <rchakrab(a)redhat.com>
wrote:
Hello Jeff,
A few years back at the time of WildFly 24, I have written an article
about "Getting started with WildFly"[1] which is currently on
opensource.com, Though we had several updates and also the same with jdk
and maven versions, but the content is still somewhat similar. Just from a
content point of view, maybe it can help us with a simple getting
started. Let me know if I can help with the content.
[1] https://opensource.com/article/21/7/wildfly
~
*Ranabir Chakraborty*
Software Engineer (JBoss SET)
<https://red.ht/sig>
On Wed, Aug 9, 2023 at 3:07 PM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
> Hi,
>
> We are evaluating how we could improve the user experience for using
> WildFly and one of the idea is to create a « Get Started » page on
> wildfly.org that would be an entry point for users that wants to try
> WildFly.
>
> This would be useful not only for new users (that have no previous
> knowledge of WildFly) but also existing users to let them understand the
> more recent ways to use WildFly.
>
> The expectation for this page would be simple:
>
> * no knowledge of WildFly required
> * Few prerequisites:
> * Java & Maven installed
> * Few steps:
> * Step 1: create a Maven project (using WildFly archetypes, more on
> that below)
> * Step 2: run mvn package
> * Step 3: run ./targer/server/bin/standalone.sh
> * Step 4: verify the application is up and running
> * Next steps
> * the page should link to next logical steps after getting started with
> WildFly (eg deploy on Kubernetes, secure WildFly, etc.)
>
> This page would provide a good user experience and rely on the WildFly
> archetype to bootstrap all the « plumbing » that needs to be done to setup
> WildFly so that the users can focus on "their » code.
>
> We already have WildFly archetypes[1] but there are opportunities for a
> simpler one which focus on that user experience.
> Darran is already working on such one[2] that takes advantage of the
> wildfly-maven-plugin to provision WildFly so that everything is controlled
> from the project pom.xml
>
> Having a good archetype would also make sure that this "getting started"
> page is always up to date with the latest release of WildFly (as we update
> the archetype for every new release of WildFly).
> For a quick review of Darran’s PR[3], we are not far from being able to
> release it and build on top of it for this « get started » page.
> We can already start working on this page and create its shell while
> polishing up the archetype.
>
> What do you think?
>
> Best regards,
> jeff
>
>
> [1] https://mvnrepository.com/artifact/org.wildfly.archetype
> [2] https://issues.redhat.com/browse/WFLY-17651
> [3] https://github.com/wildfly/wildfly-archetypes/pull/26
>
<https://github.com/wildfly/wildfly-archetypes/pull/26/commits/16a596b6d26...
> --
> Jeff Mesnil
> Engineer @ Red Hat JBoss EAP
> http://jmesnil.net/
>
> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)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...
>
11:21 p.m.
So adding server provisioning to the web app archetype, which we should do anyway, and
removing JSF and JPA, would fit the bill?
—E
On 9 Aug 2023, at 15:17, Darran Lofthouse
<darran.lofthouse(a)jboss.com> wrote:
Some of the aims I had with the archetype were:
Removing the need to install WildFly
Being able to have a new project running and in a container in less that 120 seconds
(excluding maven download times) starting with just Java and Maven installed locally.
Eliminating any configuration of the application server just to get started.
Leaving the user with a local project that they can start their own development straight
away without needing to unravel anything added they don't need.
On Wed, Aug 9, 2023 at 3:10 PM Ranabir Chakraborty <rchakrab(a)redhat.com
<mailto:rchakrab@redhat.com>> wrote:
> Hello Jeff,
>
> A few years back at the time of WildFly 24, I have written an article about
"Getting started with WildFly"[1] which is currently on opensource.com
<http://opensource.com/>;, Though we had several updates and also the same with jdk
and maven versions, but the content is still somewhat similar. Just from a content point
of view, maybe it can help us with a simple getting started. Let me know if I can help
with the content.
>
> [1] https://opensource.com/article/21/7/wildfly
> ~
> Ranabir Chakraborty
> Software Engineer (JBoss SET)
> <https://red.ht/sig>
>
>
> On Wed, Aug 9, 2023 at 3:07 PM Jeff Mesnil <jmesnil(a)redhat.com
<mailto:jmesnil@redhat.com>> wrote:
>> Hi,
>>
>> We are evaluating how we could improve the user experience for using WildFly and
one of the idea is to create a « Get Started » page on wildfly.org
<http://wildfly.org/> that would be an entry point for users that wants to try
WildFly.
>>
>> This would be useful not only for new users (that have no previous knowledge of
WildFly) but also existing users to let them understand the more recent ways to use
WildFly.
>>
>> The expectation for this page would be simple:
>>
>> * no knowledge of WildFly required
>> * Few prerequisites:
>> * Java & Maven installed
>> * Few steps:
>> * Step 1: create a Maven project (using WildFly archetypes, more on that
below)
>> * Step 2: run mvn package
>> * Step 3: run ./targer/server/bin/standalone.sh
>> * Step 4: verify the application is up and running
>> * Next steps
>> * the page should link to next logical steps after getting started with WildFly
(eg deploy on Kubernetes, secure WildFly, etc.)
>>
>> This page would provide a good user experience and rely on the WildFly archetype
to bootstrap all the « plumbing » that needs to be done to setup WildFly so that the users
can focus on "their » code.
>>
>> We already have WildFly archetypes[1] but there are opportunities for a simpler
one which focus on that user experience.
>> Darran is already working on such one[2] that takes advantage of the
wildfly-maven-plugin to provision WildFly so that everything is controlled from the
project pom.xml
>>
>> Having a good archetype would also make sure that this "getting
started" page is always up to date with the latest release of WildFly (as we update
the archetype for every new release of WildFly).
>> For a quick review of Darran’s PR[3], we are not far from being able to release
it and build on top of it for this « get started » page.
>> We can already start working on this page and create its shell while polishing up
the archetype.
>>
>> What do you think?
>>
>> Best regards,
>> jeff
>>
>>
>> [1] https://mvnrepository.com/artifact/org.wildfly.archetype
>> [2] https://issues.redhat.com/browse/WFLY-17651
>> [3] https://github.com/wildfly/wildfly-archetypes/pull/26
<https://github.com/wildfly/wildfly-archetypes/pull/26/commits/16a596b6d26...
>> --
>> Jeff Mesnil
>> Engineer @ Red Hat JBoss EAP
>> http://jmesnil.net/
>>
>> _______________________________________________
>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
<mailto: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...
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
11:27 p.m.
On Wed, Aug 9, 2023 at 3:21 PM Eduardo Martins <emartins(a)redhat.com> wrote:
So adding server provisioning to the web app archetype, which we
should do
anyway, and removing JSF and JPA, would fit the bill?
Possibly ;-) Although the other aspect of my proposal was to start with a
rest endpoint, which in turn is deployed using a war.
—E
On 9 Aug 2023, at 15:17, Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
Some of the aims I had with the archetype were:
- Removing the need to install WildFly
- Being able to have a new project running and in a container in less
that 120 seconds (excluding maven download times) starting with just Java
and Maven installed locally.
- Eliminating any configuration of the application server just to get
started.
- Leaving the user with a local project that they can start their own
development straight away without needing to unravel anything added they
don't need.
On Wed, Aug 9, 2023 at 3:10 PM Ranabir Chakraborty <rchakrab(a)redhat.com>
wrote:
> Hello Jeff,
>
> A few years back at the time of WildFly 24, I have written an article
> about "Getting started with WildFly"[1] which is currently on
> opensource.com, Though we had several updates and also the same with jdk
> and maven versions, but the content is still somewhat similar. Just from a
> content point of view, maybe it can help us with a simple getting
> started. Let me know if I can help with the content.
>
> [1] https://opensource.com/article/21/7/wildfly
> ~
> *Ranabir Chakraborty*
> Software Engineer (JBoss SET)
>
> <https://red.ht/sig>
>
>
> On Wed, Aug 9, 2023 at 3:07 PM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
>
>> Hi,
>>
>> We are evaluating how we could improve the user experience for using
>> WildFly and one of the idea is to create a « Get Started » page on
>> wildfly.org that would be an entry point for users that wants to try
>> WildFly.
>>
>> This would be useful not only for new users (that have no previous
>> knowledge of WildFly) but also existing users to let them understand the
>> more recent ways to use WildFly.
>>
>> The expectation for this page would be simple:
>>
>> * no knowledge of WildFly required
>> * Few prerequisites:
>> * Java & Maven installed
>> * Few steps:
>> * Step 1: create a Maven project (using WildFly archetypes, more on
>> that below)
>> * Step 2: run mvn package
>> * Step 3: run ./targer/server/bin/standalone.sh
>> * Step 4: verify the application is up and running
>> * Next steps
>> * the page should link to next logical steps after getting started
>> with WildFly (eg deploy on Kubernetes, secure WildFly, etc.)
>>
>> This page would provide a good user experience and rely on the WildFly
>> archetype to bootstrap all the « plumbing » that needs to be done to setup
>> WildFly so that the users can focus on "their » code.
>>
>> We already have WildFly archetypes[1] but there are opportunities for a
>> simpler one which focus on that user experience.
>> Darran is already working on such one[2] that takes advantage of the
>> wildfly-maven-plugin to provision WildFly so that everything is controlled
>> from the project pom.xml
>>
>> Having a good archetype would also make sure that this "getting
started"
>> page is always up to date with the latest release of WildFly (as we update
>> the archetype for every new release of WildFly).
>> For a quick review of Darran’s PR[3], we are not far from being able to
>> release it and build on top of it for this « get started » page.
>> We can already start working on this page and create its shell while
>> polishing up the archetype.
>>
>> What do you think?
>>
>> Best regards,
>> jeff
>>
>>
>> [1] https://mvnrepository.com/artifact/org.wildfly.archetype
>> [2] https://issues.redhat.com/browse/WFLY-17651
>> [3] https://github.com/wildfly/wildfly-archetypes/pull/26
>>
<https://github.com/wildfly/wildfly-archetypes/pull/26/commits/16a596b6d26...
>> --
>> Jeff Mesnil
>> Engineer @ Red Hat JBoss EAP
>> http://jmesnil.net/
>>
>> _______________________________________________
>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>> To unsubscribe send an email to wildfly-dev-leave(a)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...
>>
> _______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
11:33 p.m.
And that’s where we get into the need-to-know the right direction, playing
with extra functionality choices (such as adding a REST endpoint) may be
one of the reasons why Quarkus did not went with archetypes.
On Wed, 9 Aug 2023 at 15:27, Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
On Wed, Aug 9, 2023 at 3:21 PM Eduardo Martins <emartins(a)redhat.com>
wrote:
> So adding server provisioning to the web app archetype, which we should
> do anyway, and removing JSF and JPA, would fit the bill?
>
Possibly ;-) Although the other aspect of my proposal was to start with a
rest endpoint, which in turn is deployed using a war.
>
> —E
>
> On 9 Aug 2023, at 15:17, Darran Lofthouse <darran.lofthouse(a)jboss.com>
> wrote:
>
> Some of the aims I had with the archetype were:
>
> - Removing the need to install WildFly
> - Being able to have a new project running and in a container in less
> that 120 seconds (excluding maven download times) starting with just Java
> and Maven installed locally.
> - Eliminating any configuration of the application server just to get
> started.
> - Leaving the user with a local project that they can start their own
> development straight away without needing to unravel anything added they
> don't need.
>
>
> On Wed, Aug 9, 2023 at 3:10 PM Ranabir Chakraborty <rchakrab(a)redhat.com>
> wrote:
>
>> Hello Jeff,
>>
>> A few years back at the time of WildFly 24, I have written an article
>> about "Getting started with WildFly"[1] which is currently on
>> opensource.com, Though we had several updates and also the same with
>> jdk and maven versions, but the content is still somewhat similar. Just
>> from a content point of view, maybe it can help us with a simple getting
>> started. Let me know if I can help with the content.
>>
>> [1] https://opensource.com/article/21/7/wildfly
>> ~
>> *Ranabir Chakraborty*
>> Software Engineer (JBoss SET)
>>
>> <https://red.ht/sig>
>>
>>
>> On Wed, Aug 9, 2023 at 3:07 PM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
>>
>>> Hi,
>>>
>>> We are evaluating how we could improve the user experience for using
>>> WildFly and one of the idea is to create a « Get Started » page on
>>> wildfly.org that would be an entry point for users that wants to try
>>> WildFly.
>>>
>>> This would be useful not only for new users (that have no previous
>>> knowledge of WildFly) but also existing users to let them understand the
>>> more recent ways to use WildFly.
>>>
>>> The expectation for this page would be simple:
>>>
>>> * no knowledge of WildFly required
>>> * Few prerequisites:
>>> * Java & Maven installed
>>> * Few steps:
>>> * Step 1: create a Maven project (using WildFly archetypes, more on
>>> that below)
>>> * Step 2: run mvn package
>>> * Step 3: run ./targer/server/bin/standalone.sh
>>> * Step 4: verify the application is up and running
>>> * Next steps
>>> * the page should link to next logical steps after getting started
>>> with WildFly (eg deploy on Kubernetes, secure WildFly, etc.)
>>>
>>> This page would provide a good user experience and rely on the WildFly
>>> archetype to bootstrap all the « plumbing » that needs to be done to setup
>>> WildFly so that the users can focus on "their » code.
>>>
>>> We already have WildFly archetypes[1] but there are opportunities for a
>>> simpler one which focus on that user experience.
>>> Darran is already working on such one[2] that takes advantage of the
>>> wildfly-maven-plugin to provision WildFly so that everything is controlled
>>> from the project pom.xml
>>>
>>> Having a good archetype would also make sure that this "getting
>>> started" page is always up to date with the latest release of WildFly
(as
>>> we update the archetype for every new release of WildFly).
>>> For a quick review of Darran’s PR[3], we are not far from being able to
>>> release it and build on top of it for this « get started » page.
>>> We can already start working on this page and create its shell while
>>> polishing up the archetype.
>>>
>>> What do you think?
>>>
>>> Best regards,
>>> jeff
>>>
>>>
>>> [1] https://mvnrepository.com/artifact/org.wildfly.archetype
>>> [2] https://issues.redhat.com/browse/WFLY-17651
>>> [3] https://github.com/wildfly/wildfly-archetypes/pull/26
>>>
<https://github.com/wildfly/wildfly-archetypes/pull/26/commits/16a596b6d26...
>>> --
>>> Jeff Mesnil
>>> Engineer @ Red Hat JBoss EAP
>>> http://jmesnil.net/
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
>>> To unsubscribe send an email to wildfly-dev-leave(a)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...
>>>
>> _______________________________________________
> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
> To unsubscribe send an email to wildfly-dev-leave(a)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...
>
>
>
1:25 a.m.
On Wed, Aug 9, 2023 at 2:35 AM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
Hi,
We are evaluating how we could improve the user experience for using
WildFly and one of the idea is to create a « Get Started » page on
wildfly.org that would be an entry point for users that wants to try
WildFly.
This would be useful not only for new users (that have no previous
knowledge of WildFly) but also existing users to let them understand the
more recent ways to use WildFly.
The expectation for this page would be simple:
* no knowledge of WildFly required
* Few prerequisites:
* Java & Maven installed
* Few steps:
* Step 1: create a Maven project (using WildFly archetypes, more on that
below)
* Step 2: run mvn package
* Step 3: run ./targer/server/bin/standalone.sh
Any reason not to combine steps 2 and 3 and suggest either using mvn
wildfly:run or mvn wildfly:dev?
* Step 4: verify the application is up and running
* Next steps
* the page should link to next logical steps after getting started with
WildFly (eg deploy on Kubernetes, secure WildFly, etc.)
This page would provide a good user experience and rely on the WildFly
archetype to bootstrap all the « plumbing » that needs to be done to setup
WildFly so that the users can focus on "their » code.
We already have WildFly archetypes[1] but there are opportunities for a
simpler one which focus on that user experience.
Darran is already working on such one[2] that takes advantage of the
wildfly-maven-plugin to provision WildFly so that everything is controlled
from the project pom.xml
Having a good archetype would also make sure that this "getting started"
page is always up to date with the latest release of WildFly (as we update
the archetype for every new release of WildFly).
For a quick review of Darran’s PR[3], we are not far from being able to
release it and build on top of it for this « get started » page.
We can already start working on this page and create its shell while
polishing up the archetype.
What do you think?
Best regards,
jeff
[1] https://mvnrepository.com/artifact/org.wildfly.archetype
[2] https://issues.redhat.com/browse/WFLY-17651
[3] https://github.com/wildfly/wildfly-archetypes/pull/26
<https://github.com/wildfly/wildfly-archetypes/pull/26/commits/16a596b6d26...
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
--
James R. Perkins
JBoss by Red Hat
1:31 a.m.
On 9 Aug 2023, at 18:25, James Perkins <jperkins(a)redhat.com>
wrote:
On Wed, Aug 9, 2023 at 2:35 AM Jeff Mesnil <jmesnil(a)redhat.com
<mailto:jmesnil@redhat.com>> wrote:
> Hi,
>
> We are evaluating how we could improve the user experience for using WildFly and one
of the idea is to create a « Get Started » page on wildfly.org <http://wildfly.org/>
that would be an entry point for users that wants to try WildFly.
>
> This would be useful not only for new users (that have no previous knowledge of
WildFly) but also existing users to let them understand the more recent ways to use
WildFly.
>
> The expectation for this page would be simple:
>
> * no knowledge of WildFly required
> * Few prerequisites:
> * Java & Maven installed
> * Few steps:
> * Step 1: create a Maven project (using WildFly archetypes, more on that below)
> * Step 2: run mvn package
> * Step 3: run ./targer/server/bin/standalone.sh
Any reason not to combine steps 2 and 3 and suggest either using mvn wildfly:run or mvn
wildfly:dev?
I did not think about that :)
For this page, I wanted to have clear boundaries on the steps (this is how you build, this
is how you run).
Having said that, another Step that would be very interesting to showcase would be to run
« mvn wildly:dev » make a tweak to the application codebase and see the changes in the
running app.
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
1:34 a.m.
On Wed, Aug 9, 2023 at 9:31 AM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
On 9 Aug 2023, at 18:25, James Perkins <jperkins(a)redhat.com> wrote:
On Wed, Aug 9, 2023 at 2:35 AM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
> Hi,
>
> We are evaluating how we could improve the user experience for using
> WildFly and one of the idea is to create a « Get Started » page on
> wildfly.org that would be an entry point for users that wants to try
> WildFly.
>
> This would be useful not only for new users (that have no previous
> knowledge of WildFly) but also existing users to let them understand the
> more recent ways to use WildFly.
>
> The expectation for this page would be simple:
>
> * no knowledge of WildFly required
> * Few prerequisites:
> * Java & Maven installed
> * Few steps:
> * Step 1: create a Maven project (using WildFly archetypes, more on
> that below)
> * Step 2: run mvn package
> * Step 3: run ./targer/server/bin/standalone.sh
>
Any reason not to combine steps 2 and 3 and suggest either using mvn
wildfly:run or mvn wildfly:dev?
>
I did not think about that :)
For this page, I wanted to have clear boundaries on the steps (this is how
you build, this is how you run).
Using a maven goal seems more in the direction we should move. The dev goal
will allow provisioning without having to run provision first. The run goal
will too, but it currently doesn't account for the provisioning settings.
We could easily change that though.
Having said that, another Step that would be very interesting to showcase
would be to run « mvn wildly:dev » make a tweak to the application codebase
and see the changes in the running app.
This makes sense to me too. I'm not suggesting that we do this for the
getting started, but I do think using run or dev makes sense there.
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
--
James R. Perkins
JBoss by Red Hat
5:18 p.m.
Having said that, another Step that would be very interesting to
showcase would be to run « mvn wildly:dev » make a tweak to the application codebase and
see the changes in the running app.
This makes sense to me too. I'm not suggesting that we do this for the getting
started, but I do think using run or dev makes sense there.
As an idea, I added a « step 4. Continuous Development » to my PoC at
http://jmesnil.github.io/wildfly.org//getstarted/
That makes the experience a bit more playful and interactive.
jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
5:40 p.m.
Hello Eduardo,
Emmanuel is trying something with the archetype but he needs to be able to
pull it from Nexus, would you mind if I "mvn deploy" a SNAPSHOT of the
current PR so he can experiment with it?
Regards,
Darran Lofthouse.
On Thu, Aug 10, 2023 at 9:18 AM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
> Having said that, another Step that would be very interesting
to
showcase would be to run « mvn wildly:dev » make a tweak to the application
codebase and see the changes in the running app.
>
> This makes sense to me too. I'm not suggesting that we do this for the
getting started, but I do think using run or dev makes sense there.
As an idea, I added a « step 4. Continuous Development » to my PoC at
http://jmesnil.github.io/wildfly.org//getstarted/
That makes the experience a bit more playful and interactive.
jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
5:41 p.m.
Sure, no problem.
On Fri, 11 Aug 2023 at 09:40, Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
Hello Eduardo,
Emmanuel is trying something with the archetype but he needs to be able to
pull it from Nexus, would you mind if I "mvn deploy" a SNAPSHOT of the
current PR so he can experiment with it?
Regards,
Darran Lofthouse.
On Thu, Aug 10, 2023 at 9:18 AM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
> > Having said that, another Step that would be very interesting to
> showcase would be to run « mvn wildly:dev » make a tweak to the application
> codebase and see the changes in the running app.
> >
> > This makes sense to me too. I'm not suggesting that we do this for the
> getting started, but I do think using run or dev makes sense there.
>
>
> As an idea, I added a « step 4. Continuous Development » to my PoC at
> http://jmesnil.github.io/wildfly.org//getstarted/
>
> That makes the experience a bit more playful and interactive.
>
> jeff
>
> --
> Jeff Mesnil
> Engineer @ Red Hat JBoss EAP
> http://jmesnil.net/
>
>
7:04 p.m.
I played a bit more around this task and I have something that might be worth showcasing
as it impacts a lot of objectives we set for WildFly.
This revolves around having task-oriented guides that lets the user know how they could
achieve something for their applications.
For example, what does it take to use MicroProfile Config with WildFly? How can I automate
WildFly installations with Ansible? How can I build a container image with my Jakarta EE
application? How can I setup TLS on Kubernetes?
All these informations are available at different places (GitHub projects, blog posts on
wildfly.org or other places, docs.wildfly.org) but it’s very difficult to find them, make
them consistent, and navigate from one to another...
The idea would be to have a single location where uses could *start from* and then link to
other places.
The first step is to let the users « get started » with WildFly. That was the start of
this mail thread and I have a PoC for that at http://jmesnil.github.io/wildfly.org/
The « get started » page explains in 4 steps how to create, build and run a Jakarta EE
application with WildFly in less than 10 minutes (it’s using a Maven archetype that has
not been released yet).
Then what next for the user?
We could have a « guides" section in wildfly.org that gathers all these task-oriented
guides and let the user find the one they need to achieve their goals.
My PoC is doing that at http://jmesnil.github.io/wildfly.org/guides/
I’ve added a few guides to fill the content, the most realistic being
http://jmesnil.github.io/wildfly.org//guides/use-microprofile-config. After I read this, I
have been able to use MicroProfile Config with my app and I have learnt where I can find
next steps and addition information.
The source of these guides would be in
https://github.com/wildfly/wildfly/tree/main/docs/src/main/asciidoc. Having the doc being
closer to the source will incentivize developers to add and maintain them :)
When we release a version of WildFly, we take that content from the tag and copy it to the
web site.
We need to add a bit of metadata to display the guides with the right categories.
As an example, we recently had an article that explains how to use WildFly with Ansible at
https://www.wildfly.org/news/2023/01/10/ansible-wildfly/
We could use this content to create a task-oriented guide by adding a commit to WildFly:
https://github.com/wildfly/wildfly/commit/3fb997df3cb9c8617c0a6083cc8563b...
There is nothing really new here (and we could have a template such as
https://github.com/jmesnil/wildfly/blob/3fb997df3cb9c8617c0a6083cc8563bd3...
to make sure the structure is consistent)
Now, when we do a release of WildFly, we would take all this content and copy that to
github.com/wildfly/wildfly.org.
We would also add a bit of metadata to categorise the new guides.
For this example, we would commit something like
https://github.com/wildfly/wildfly.org/commit/63635ec1999cab416b933c062ab...
(Note that only the guide.yaml needs curating, all other content is copied verbatim from
the wildly repo without any modification.)
The web site will be published, the guides will be properly rendered with wildfly.org look
& feel and categorized:
http://jmesnil.github.io/wildfly.org//guides/automate-with-ansible
I looked at how https://quarkus.io/guides/ achieve this. They provide versioned guides
(although they are only providing specific Quarkus LTS version afaict) and we could do the
same.
But I’m not sure this is the right thing to do for guides if we multiply them for every
version without a good reason.
It needs more insight but we could keep all this content in doc.wildfly.org for every
version and make sure that wildfly.org would only provide the latest.
Who would be interested to work on this and bootstrap the effort?
Best regards,
Jeff
—
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
5:45 a.m.
Overall I think this looks great! It's a much cleaner look to documentation
IMO and keeps things looking consistent. More inline.
On Thu, Sep 7, 2023 at 3:04 AM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
I played a bit more around this task and I have something that might
be
worth showcasing as it impacts a lot of objectives we set for WildFly.
This revolves around having task-oriented guides that lets the user know
how they could achieve something for their applications.
For example, what does it take to use MicroProfile Config with WildFly?
How can I automate WildFly installations with Ansible? How can I build a
container image with my Jakarta EE application? How can I setup TLS on
Kubernetes?
All these informations are available at different places (GitHub projects,
blog posts on wildfly.org or other places, docs.wildfly.org) but it’s
very difficult to find them, make them consistent, and navigate from one to
another...
The idea would be to have a single location where uses could *start from*
and then link to other places.
The first step is to let the users « get started » with WildFly. That was
the start of this mail thread and I have a PoC for that at
http://jmesnil.github.io/wildfly.org/
The « get started » page explains in 4 steps how to create, build and run
a Jakarta EE application with WildFly in less than 10 minutes (it’s using a
Maven archetype that has not been released yet).
Then what next for the user?
We could have a « guides" section in wildfly.org that gathers all these
task-oriented guides and let the user find the one they need to achieve
their goals.
My PoC is doing that at http://jmesnil.github.io/wildfly.org/guides/
I’ve added a few guides to fill the content, the most realistic being
http://jmesnil.github.io/wildfly.org//guides/use-microprofile-config.
After I read this, I have been able to use MicroProfile Config with my app
and I have learnt where I can find next steps and addition information.
The source of these guides would be in
https://github.com/wildfly/wildfly/tree/main/docs/src/main/asciidoc.
Having the doc being closer to the source will incentivize developers to
add and maintain them :)
I actually think keeping these elsewhere makes more sense. They should
likely just live in https://github.com/wildfly/wildfly.org or a separate
repository all together. If we need to update a guide because it has an
error, how would we do that? If we just make a PR to the main WildFly repo,
we'd need a release to see the change.
When we release a version of WildFly, we take that content from the tag
and copy it to the web site.
We need to add a bit of metadata to display the guides with the right
categories.
As an example, we recently had an article that explains how to use WildFly
with Ansible at https://www.wildfly.org/news/2023/01/10/ansible-wildfly/
We could use this content to create a task-oriented guide by adding a
commit to WildFly:
https://github.com/wildfly/wildfly/commit/3fb997df3cb9c8617c0a6083cc8563b...
There is nothing really new here (and we could have a template such as
https://github.com/jmesnil/wildfly/blob/3fb997df3cb9c8617c0a6083cc8563bd3...
to make sure the structure is consistent)
Now, when we do a release of WildFly, we would take all this content and
copy that to github.com/wildfly/wildfly.org.
We would also add a bit of metadata to categorise the new guides.
For this example, we would commit something like
https://github.com/wildfly/wildfly.org/commit/63635ec1999cab416b933c062ab...
(Note that only the guide.yaml needs curating, all other content is copied
verbatim from the wildly repo without any modification.)
The web site will be published, the guides will be properly rendered with
wildfly.org look & feel and categorized:
http://jmesnil.github.io/wildfly.org//guides/automate-with-ansible
I looked at how https://quarkus.io/guides/ achieve this. They provide
versioned guides (although they are only providing specific Quarkus LTS
version afaict) and we could do the same.
But I’m not sure this is the right thing to do for guides if we multiply
them for every version without a good reason.
It needs more insight but we could keep all this content in
doc.wildfly.org for every version and make sure that wildfly.org would
only provide the latest.
Who would be interested to work on this and bootstrap the effort?
Best regards,
Jeff
—
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
--
James R. Perkins
JBoss by Red Hat
3:39 p.m.
On 7 Sep 2023, at 22:45, James Perkins <jperkins(a)redhat.com>
wrote:
>
> The source of these guides would be in
https://github.com/wildfly/wildfly/tree/main/docs/src/main/asciidoc. Having the doc being
closer to the source will incentivize developers to add and maintain them :)
I actually think keeping these elsewhere makes more sense. They should likely just live
in https://github.com/wildfly/wildfly.org or a separate repository all together. If we
need to update a guide because it has an error, how would we do that? If we just make a PR
to the main WildFly repo, we'd need a release to see the change.
Technically, we don’t need to release WildFly to push its content to wildfly.org, we would
just copy its content.
But this might be inappropriate if it picks up a guide for something that has not been
released yet.
I like your other approach and we can make it a seamless integration:
* have a dedicated github.com/wildfly/guides that contains the guides (in Asciidoc) as
well as the same web site L&F than wildfly.org
* use GitHub page to publish it to https://docs.wildfly.org/guides
With that setup, we could aded/update guides independently of WildFly releases.
Jeff
—
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
6:03 a.m.
On Thu, Sep 7, 2023 at 11:40 PM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
On 7 Sep 2023, at 22:45, James Perkins <jperkins(a)redhat.com> wrote:
>
> The source of these guides would be in
> https://github.com/wildfly/wildfly/tree/main/docs/src/main/asciidoc.
> Having the doc being closer to the source will incentivize developers to
> add and maintain them :)
>
I actually think keeping these elsewhere makes more sense. They should
likely just live in https://github.com/wildfly/wildfly.org or a separate
repository all together. If we need to update a guide because it has an
error, how would we do that? If we just make a PR to the main WildFly repo,
we'd need a release to see the change.
Technically, we don’t need to release WildFly to push its content to
wildfly.org, we would just copy its content.
But this might be inappropriate if it picks up a guide for something that
has not been released yet.
I like your other approach and we can make it a seamless integration:
* have a dedicated github.com/wildfly/guides that contains the guides (in
Asciidoc) as well as the same web site L&F than wildfly.org
* use GitHub page to publish it to https://docs.wildfly.org/guides
With that setup, we could aded/update guides independently of WildFly
releases.
I think this makes sense and I like this approach.
Along these lines, because I'm thinking about this for another project, is
for new feature guides maybe we have a dev branch or something that once
released we merge into the main branch. That way we can create guides for
new releases without affecting the current guides. The other option is just
labels and merging when released.
Jeff
—
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
--
James R. Perkins
JBoss by Red Hat
3:01 p.m.
It is Friday so I will go wild :) Having multiple sources on input and
generate text based on task definition sounds to me as ideal task for LLM :)
Most naive would be to provide Context URL, but even with that Bard
provides meaningful answers [1]. As more sophisticated that could probably
be to upload public wildfly embeddings on Hugging Face and reference that.
Or even something else, I am not an expert. But you see the point.
My idea is could that documentation aggregator on wildfly.org be one
prompt, which will be fed with wildfly specific context data. Calling some
open source friendly LLM?
[1]
- https://g.co/bard/share/8e83c3b46e44
- https://g.co/bard/share/a89a4b8a90f2
- https://g.co/bard/share/b70dd63db532
- https://g.co/bard/share/d99d5fca576b
On Thu, Sep 7, 2023 at 12:05 PM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
I played a bit more around this task and I have something that might
be
worth showcasing as it impacts a lot of objectives we set for WildFly.
This revolves around having task-oriented guides that lets the user know
how they could achieve something for their applications.
For example, what does it take to use MicroProfile Config with WildFly?
How can I automate WildFly installations with Ansible? How can I build a
container image with my Jakarta EE application? How can I setup TLS on
Kubernetes?
All these informations are available at different places (GitHub projects,
blog posts on wildfly.org or other places, docs.wildfly.org) but it’s
very difficult to find them, make them consistent, and navigate from one to
another...
The idea would be to have a single location where uses could *start from*
and then link to other places.
The first step is to let the users « get started » with WildFly. That was
the start of this mail thread and I have a PoC for that at
http://jmesnil.github.io/wildfly.org/
The « get started » page explains in 4 steps how to create, build and run
a Jakarta EE application with WildFly in less than 10 minutes (it’s using a
Maven archetype that has not been released yet).
Then what next for the user?
We could have a « guides" section in wildfly.org that gathers all these
task-oriented guides and let the user find the one they need to achieve
their goals.
My PoC is doing that at http://jmesnil.github.io/wildfly.org/guides/
I’ve added a few guides to fill the content, the most realistic being
http://jmesnil.github.io/wildfly.org//guides/use-microprofile-config.
After I read this, I have been able to use MicroProfile Config with my app
and I have learnt where I can find next steps and addition information.
The source of these guides would be in
https://github.com/wildfly/wildfly/tree/main/docs/src/main/asciidoc.
Having the doc being closer to the source will incentivize developers to
add and maintain them :)
When we release a version of WildFly, we take that content from the tag
and copy it to the web site.
We need to add a bit of metadata to display the guides with the right
categories.
As an example, we recently had an article that explains how to use WildFly
with Ansible at https://www.wildfly.org/news/2023/01/10/ansible-wildfly/
We could use this content to create a task-oriented guide by adding a
commit to WildFly:
https://github.com/wildfly/wildfly/commit/3fb997df3cb9c8617c0a6083cc8563b...
There is nothing really new here (and we could have a template such as
https://github.com/jmesnil/wildfly/blob/3fb997df3cb9c8617c0a6083cc8563bd3...
to make sure the structure is consistent)
Now, when we do a release of WildFly, we would take all this content and
copy that to github.com/wildfly/wildfly.org.
We would also add a bit of metadata to categorise the new guides.
For this example, we would commit something like
https://github.com/wildfly/wildfly.org/commit/63635ec1999cab416b933c062ab...
(Note that only the guide.yaml needs curating, all other content is copied
verbatim from the wildly repo without any modification.)
The web site will be published, the guides will be properly rendered with
wildfly.org look & feel and categorized:
http://jmesnil.github.io/wildfly.org//guides/automate-with-ansible
I looked at how https://quarkus.io/guides/ achieve this. They provide
versioned guides (although they are only providing specific Quarkus LTS
version afaict) and we could do the same.
But I’m not sure this is the right thing to do for guides if we multiply
them for every version without a good reason.
It needs more insight but we could keep all this content in
doc.wildfly.org for every version and make sure that wildfly.org would
only provide the latest.
Who would be interested to work on this and bootstrap the effort?
Best regards,
Jeff
—
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)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...
3:54 p.m.
On 8 Sep 2023, at 08:01, Martin Choma <mchoma(a)redhat.com> wrote:
It is Friday so I will go wild :) Having multiple sources on input and generate text
based on task definition sounds to me as ideal task for LLM :)
Most naive would be to provide Context URL, but even with that Bard provides meaningful
answers [1]. As more sophisticated that could probably be to upload public wildfly
embeddings on Hugging Face and reference that. Or even something else, I am not an expert.
But you see the point.
[I’m not a LLM expert either so take everything I write with a grain of salt]
I like the idea but the actual results are not good at the moment.
We need these task-oriented guides to be the « source of truth » of such LLM output. Their
current output goes from ok to plainly wrong. Relying on them from wildfly.org without the
ability to control and verify their correctness would be a disservice to our community.
* https://bard.google.com/share/b70dd63db532 is plainly wrong (non-existing
wildfly:29-alpine base image, using java -jar to run WildFly)
* https://bard.google.com/share/8e83c3b46e44 is not bad but uses an old
microprofile-config-smallrye XML schema and does not rely on the wildfly MicroProfile BOM
to manage the dependencies.
If we have in place the building block for our user tasks, then LLM could help aggregate
that in a complete scenario.
For example, "I want to read a K8S config map from a Jakarta EE application » could
be the aggregation of simple guides (« use microprofile config », « deploy WildFly on
Kubernetes » , « use configmaps and secrets with micro profile config »).
Best regards,
Jeff
—
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
6:35 p.m.
Hi,
In order to make progress on this feature and agree on its content, I opened WFLY-18428[1]
and its
wildfly-proposal at [2].
You can try this by installing locally Darran’s archetype (as explained in [2]) and then
follow the steps at http://jmesnil.github.io/wildfly.org/getstarted/
The intent of this is really to « get started » with WildFly. This will not cover all that
can be achieved with WildFly but gives just enough for a new or existing users to try
WildFly in a matter of minutes and start writing their code with it.
Best regards,
Jeff
[1] https://issues.redhat.com/browse/WFLY-18428
[2] https://github.com/wildfly/wildfly-proposals/pull/536
On 10 Aug 2023, at 10:18, Jeff Mesnil <jmesnil(a)redhat.com>
wrote:
> Having said that, another Step that would be very interesting to showcase would be to
run « mvn wildly:dev » make a tweak to the application codebase and see the changes in the
running app.
>
> This makes sense to me too. I'm not suggesting that we do this for the getting
started, but I do think using run or dev makes sense there.
As an idea, I added a « step 4. Continuous Development » to my PoC at
http://jmesnil.github.io/wildfly.org//getstarted/
That makes the experience a bit more playful and interactive.
jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
240
days inactive
273
days old
37 comments
7 participants
participants (7)
-
Brian Stansberry -
Darran Lofthouse -
Eduardo Martins -
James Perkins -
Jeff Mesnil -
Martin Choma -
Ranabir Chakraborty