[ANNOUNCE] Rename jboss/metadata "master" branch to "main"
by Emmanuel Hugonnet
Hello,
With the JakartEE 10 migration complete, we take the opportunity to change the default branch for jboss/metadata from "master" to "main".
Once the switch is done, I’ll send another mail to inform each contributor with the steps to update their local environment.
Regards
Emmanuel
2 years, 1 month
Dependency exclusion management
by Jason Lee
This may be more of a general maven question, but I have a question about
exclusion management in our POMs: Where do the exclusions need to be
listed? For my parts of the system, I have an inconsistent mix of declaring
the exclusions in, say, boms/, ee-feature-pack/, and my individual
extension modules. That seems like overkill, though, and is certainly not
dry. Is it enough to declare the exclusions in the dependencyManagement
section of the BOM, then just declare the (versionless) dependency in the
other Maven modules that might need it?
I don't want to repeat that large block of XML over and over, but I know we
also don't want to ship any jars that we don't explicitly want.
Jason Lee
Principal Software Engineer
Red Hat JBoss EAP
2 years, 1 month
Importing 3rd Party Boms?
by Jason Lee
Do we have a policy on importing third party boms (in
boms/common-ee/pom.xml, for example)? The OpenTelemetry project provides a
BOM to help synchronize artifact versions. I'm currently declaring
dependency with explicit versions (controlled by a Maven property, of
course) for each dependency. Things get tricky for otel as some artifacts
are $VERSION and some are ${VERSION}-alpha. Using a BOM would make that
transparent (as well as making the eventual transition from -alpha to ga
transparent).
I don't see any BOMs being imported, so I thought I'd ask before I tried to
be first. :)
Jason Lee
Principal Software Engineer
Red Hat JBoss EAP
2 years, 1 month
Better synergies for WildFly Container images
by Jean-Frederic Mesnil
Hi,
To run WildFly on a Cloud with a container image, you have 2 approaches:
* Use the “docker” image that provides a downloaded installation of WildFly, put your deployment in it and deploy on your container platform.
* Use the “s2i” images to build an application with S2I (Source-to-image) on OpenShift, put it in a runtime image and deploy it on OpenShift.
Both approaches have their own strength and weaknesses and evolved at their own pace without any coordination.
However in the last few months, the activity on the docker image slowed down due to external factor (hub.docker constraints) and our lack of attention to it…
Meanwhile, we have ramped up the activity on the S2I images and provided a whole new architecture that relies on Maven to assemble the application runtime (WildFly + deployments) instead of hiding that assembly in the S2I process.
I just wrote down an article on wildfly.org explaining how WildFly users that uses the “docker” image can adapt their workflow to the new architecture (without having to switch to S2I!)
https://www.wildfly.org/news/2022/08/04/wildfly-maven-docker/
The target audience for this article is the “docker” users so that they can keep their workflow (I build my deployment, I create a container image from a Dockerfile) and benefit from all the work done around WildFly provisioning (feature packs, layers, packaging scripts, etc.)
While writing this article and looking at the issues for the docker image, I spotted a few themes shared between all these images:
* We want to consume more recent versions of JDK (17 in particular)
* We want to run on linux/arm64 (in addition to Intel arch)
* We want to trim the image size / reduce the surface area of security attacks
* We want better image health index
I think the investment we made on the S2I bundler and runtime images can benefit to the docker image and vice versa.
In particular, we are dedicated to provide a runtime image that contains all it needs to run WildFly (ie OpenJDK + a few more bits) with a good health index.
On the docker image, the base-jdk image we are using is lagging behind and I wonder if we should not take the opportunity to use the WildFly runtime image as the base for the docker image (after all, its sole purpose is to run WildFly!)
I’ve started a Board to list the synergies and feature gap we have in our images:
https://trello.com/b/QGnEci3i/willdfly-image-alignments
I think that using the runtime image as the base image for the docker image would be an enabler for a lot of this work and would ensure that WildFly is in better shape to run on containers.
As I wrote in the article, we will continue to deliver the Docker image for WildFly but we are focusing on the new architecture and the new images to expand the capabilities of WildFly.
We are looking forward to our users trying this new approach and validates how it improves their workflow.
I’ve opened this thread to gather input on this alignment to make sure we get all the requirement in place before putting this in action.
I’m looking forward to hearing your ideas on it.
Best regards,
Jeff
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
2 years, 1 month
