Hi Jason, all,
allow me to resuscitate this thread after a year and a half.
These directions have been very clear and useful, I was needing to
look them up again today. Wondering: would you give the same
Especially considering WildFly Swarm, should we still avoid making
Hibernate feature packs / fractions / patches ?
We would like to make sure that Hibernate users (ORM, OGM, Search,
...) could somewhat easily access our latest versions as soon as they
are released, without having to wait for several other "downstream"
projects to incorporate our latest.
On 3 August 2015 at 17:37, Jason Greene <jason.greene(a)redhat.com> wrote:
Recently there has been some confusion about how subsystems should be distributed, and
whether or not they should be part of the WildFly repository.
There are three primary use-cases for distributing a subsystem.
#1 - Inclusion in an official WildFly distribution
#2 - A user installable "add-on distribution" which can be dropped on top of a
WildFly Distribution (see [A])
#3 - A separate, independant, customized distribution, with a differing identity.
Possibly build but not required as a layer (see [A])
If you are after #1, then the subsystem source code (defined as the portion of code which
integrates with the server using the subsystem facilities) MUST be included in the WildFly
repo. This is because subsystems heavily impact the stability of the server and our
compliance with our strict management compatibility policy, and additionally it allows for
us to keep all included subsystems up to date with core infrastructure changes such as
capabilities and requirements, and the upcoming elytron security integration. Under this
approach, a feature-pack is unlikely to be used, as it would likely just be part of the
full feature-pack. It could very well be that we would introduce a different more
expansive feature-pack in the future defining a larger distribution foot-print, however,
there are currently no plans to do so.
If you are after #2, then you do not want a feature-pack, as feature-packs are just for
building custom server distributions. If your use-case is #2 you are by definition not a
custom server distribution, but rather a set of modules built the normal maven way.
If you are after #3, then you likely wish to use the feature-pack mechanism to make it
easy to produce your custom distribution. This facility would allow you to keep your
source repository limited to just the new subsystems you introduce, and pull the rest of
the server bits via a maven dep. It is important, that you change the identity of the
server (see [A]), such that patches for the official WildFly server are not accidentally
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
wildfly-dev mailing list