Eliminating 'subclassing' in feature pack config elements
by Brian Stansberry
I've been thinking some about how we can improve our flexibility in
producing different flavors of WildFly and one area that may help and
hopefully would be pretty simple is reducing / eliminating hard references
from one feature pack to another in the various configuration content that
ends up in the FP.
A concrete example is what I'm calling 'subclassing' where feature pack B
is taking something from feature pack A and 'extending' it in some way. A
concrete example:
https://github.com/wildfly/wildfly/blob/master/servlet-galleon-pack/src/m...
It would be nice to get rid of that kind of thing. (There may be better
examples; that was just the first one I noticed when randomly poking.)
I'm bringing this up somewhat to socialize the general topic of looser
coupling between codebases when producing feature packs, something I also
get into with https://issues.redhat.com/browse/GAL-319.
A high level view of what I'm thinking about is if I want to produce a
wildfly-ee feature pack, why does it need to depend on a wildfly-core
feature pack? It needs some configuration and package content from WildFly
Core, and it needs a dependency set (which it could override if wanted.)
But it shouldn't need the actual pack.
This is helpful when producing software, as it reduces the requirement to
do new releases. For example yesterday we could have dispensed with a
WildFly Core 12.0.1 release needed for WF 20 just to bring in a couple
component upgrades. WildFly could have simply overridden the component
versions.
It's also helpful for UX and general API control. If a wildfly-ee FP
depends on wildfly-servlet and wildfly-core FPs, then those FPs become
visible to end users, which is more complex and reduces the ability to
evolve things in the future.
As we work on things like doing an EE 9 variant of WF using a hierarchy of
feature packs is going to get significantly more so I think we need to get
beyond that.
Best regards,
Brian
3 years, 10 months
Release date for WF 20
by Brian Stansberry
Hi everyone,
I wanted to let you know that we decided to shift the WF 20.0.0.Final
release date from today to Monday. We decided to bring in a couple late
fixes. We could release tomorrow, but I prefer not to release on Fridays.
Best regards,
Brian
3 years, 10 months
Updating the wildfly.org site
by Brian Stansberry
You may recall that last year we advertised a likely refresh of the
https://wildfly.org site, and asked for input. The rollout of that refresh
took a back burner for a while, but Adela Arreola and James Cobb are
working on it now and I'd like to move over soon. So I encourage the
community to have a look and provide any feedback. (Note there's no need
to provide feedback about the beta content being behind the live site;
that's being addressed.)
The beta version of the revised site is at
https://www.stage.jboss.org/wildflysite/
If you'd like to report and issue, you can do so at
https://github.com/jbossorg/wildflysite/issues/new
Best regards,
Brian
3 years, 10 months
