Enabling dependabot on https://github.com/wildfly/wildfly-archetypes and other changes
by Jeff Mesnil
Hi,
I’ve been looking at our archetypes at https://github.com/wildfly/wildfly-archetypes as we could leverage them to improve the user experience of getting started with WildFly (see my previous mail).
The project could benefit from enabling dependabot updates:
* The archetypes would be automatically updated with new WildFly releases. Brian is always making sure that he creates a PR whenever a new version of WildFly is released but this can be automated by dependabot and we would only need to merge a PR instead of having to create the commit manually.
* More importantly, we can also automatically update the generated projects so they use the latest version of any plugins that we configure in their pom.xml
I’ll also take the opportunity to move its default branch to `main` instead of `master` before applying these changes and create a GitHub action to get minimal CI for this project.
Best regards,
jeff
--
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
2 years
SE 21 and 11
by Brian Stansberry
Java SE 21 is due to go GA next week, and SE 11 support from various
vendors is starting to ramp down a bit, so I'd like to discuss a bit plans
around SE.
For some context, please refer to the "Java SE Support" section in
https://www.wildfly.org/news/2023/07/21/WildFly29-Released/. A variant of
that section is part of every major/minor release announcement and I try
and wordsmith it carefully.
First, I'm definitely happy about how for a long time now we've been able
to use the kind of language I use there about SE 20 for each WF release
with respect to the most recent SE GA release. We've done a good job of
keeping up with SE. Kudos to Richard Opalka for keeping on top of that,
testing and applying fixes well ahead of time. Thanks too to Ken Wills for
keeping CI up to date.
It's looking good for being able to use the kind of language I used for SE
20 and WF 29 with SE 21 and WF 30. The nightly jobs on CI look good. And
we're actually running quite a few more of them than we do with most new SE
versions.
That said, my instinct is for WF 30 I should modify my standard "Our
recommendation is that you run WildFly on the most recent long-term support
Java SE release" language, as SE 21 will be too new and our experience too
limited to be able to make such a statement. Seems like we should stick to
SE 17 as the recommendation.
One reason for that is we should confirm with more of the component
projects we integrate how they feel about their own SE 21 support.
Thoughts?
Second topic is SE 11 support. I've signalled in the last couple release
announcements that our support for SE 11 will likely come to an end in the
next year. For WF 30 I'm tempted to say it will likely be the last release
where we support SE 11, phrased in a way to imply that supporting it in
January's WF 31 is possible.
I expect with the release of SE 21 we will start to see some of the
components we integrate move beyond SE 11, so we need to be ready.
As a bit of a hedge though I think for WF 31 we should stick with SE 11 as
the source level for WildFly, WildFly Core and various component projects
that are in the wildfly org. I don't have the sense that we have urgent
needs to move beyond that in the next few months,
Thoughts?
It's great to see the Java ecosystem continue to move forward.
Best regards,
--
Brian Stansberry
WildFly Project Lead
He/Him/His
2 years
Create a "get started" page on WildFly.org
by Jeff Mesnil
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/
2 years
