[wildfly-dev] Subsystem Inclusion Policy & Role of Feature Packs & Add-ons

[Sanne Grinovero]

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
directions today?

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.

Thanks,
Sanne

On 3 August 2015 at 17:37, Jason Greene <jason.greene at redhat.com> wrote:
> Hello Everyone,
>
> 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 installed.
>
> Thanks!
>
> [A] https://developer.jboss.org/wiki/LayeredDistributionsAndModulePathOrganization
>
>
>
>
>
>
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev