[wildfly-dev] Feature packs and slots

[Sanne Grinovero]

Hi Stuart, thank you so much for the comments! Very helpful.

inline for some answers:

On 11 January 2018 at 05:34, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
>
>
> On Wed, Jan 10, 2018 at 12:26 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Hi all,
>>
>> I'm trying to learn how to make proper use of the
>> `wildfly-feature-pack-build-maven-plugin` to replace our usage of the
>> assembly plugin.
>>
>> We extensively use the module slots, and I need to keep the
>> "{$module.slot}" as a build parameter.
>
>
> Just out of curiosity what is the use case for this?

I was hoping to spare you all the details, but since you ask :)

In a nutshell, the need to be able to work at different release cycle
/ pace than you all. Decoupling of projects.

The same feature pack is consumed by multiple products / layers which
have an independent release cycle, hence occasionally need to use
diffefrent versions.

For example I'm trying to make a feature pack of our Apache Lucene
modules; these are included in both the WildFly "traditional" server
and in Infinispan Server, which builds on the WildFly server releases;
while we try hard to use the same version, so that often in practice
this won't be necessary, there have been several situations in which
Infinispan would need the ability to include significantly newer
versions of the same modules. This is all compounded by having
different release dates, different purposes as a product and even
different support strategies.. while I understand we have to try hard
to not have multiple copies of the same dependency it's often the only
practical solution.

A big deal is that products layering on top of WildFly might schedule
a different *major* release than other products based on WildFly - so
while you might need to veto a major component upgrade for the reasons
of one, it's the only chance to include such an upgrade for another.

Even before reaching the phase of mature products, our projects often
release intermediate milestones which we need to test among such
projects in various combinations: such major component upgrades don't
happen overnight; for example to prepare the next version of Hibernate
OGM, we need a WildFly server with a bleeding edge updated version of
Hibernate ORM, the very latest Hibernate Search, override the JPA API,
and include the latest "Infinispan modules for WildFly" - yet without
having the bandwith (and capability) to also update all components
which would depend on such components normally, such as the clustering
system of the server. Still we might need the clustering features to
work during such prototype development, which implies the need to
"add" additional copies rather than replace the existing modules to
evolve one aspect at a time.

In some other cases we just need such additional modules to verify the
feasability of running multiple different versions of the same
framework on the WildFly server; for example I need to make sure we
can eventually include both Hibernate ORM 5.1 and Hibernate ORM 6.0 in
the same WildFly server and allow the end users to choose [flawless
backwards compatibility] vs [best performance and latest features].

>>
>> It looks like the Feature Pack plugin is expecting the module.xml
>> files to be statically committed into the same directory structure as
>> were they need to end up, but since the slot id needs to be part of
>> such path, looks like I can't use it? Should I pre-process the module
>> resources with the assembly plugin?
>
>
> Yes, at the moment there is no way to handle this. In general in WF we just
> use the slot main, and we don't vary any part of a module name based on a
> build parameter.

Right, I'm aware that WildFly uses "main" consistently, but since I'm
having the impression these tools have a wider scope, I guess such
features might be introduced?

If I were able to package all the Hibernate libraries and our
dependencies into feature packs that should also simplify and speedup
the build of WildFly itself, but I need the slots too for the above
reasons.

For the record, the slots system - and the aliases as well - have been
extremely useful for many of our other projects, so thanks again for
that.

>>
>> I was hoping for the feature-pack-build.xml to have a way to define
>> modules by giving it an identifier (possibly having parameters), point
>> them to a template xml (optionally filtered), and not having to deal
>> with the copy-to paths explicitly. It seems odd to have to copy the
>> jar files and other resources into a matching structure, maybe this
>> could be automated by the plugin?
>
>
> You don't have to copy the jar files, the plugin does it automatically. They
> are laid out the way they are at the moment because it just seemed to be the
> simplest way to do it at the time. We did not need another layer of
> indirection as generally each module has its own unique module.xml so if we
> used a templating approach each template would be unique anyway.

I'm quite confused on how that's working, where it's inferring the
details from; I guess I'll experiment a bit more but I'm not
understanding how the tool would know which jars I mean to include in
each module.

>> Or perhaps I should look at the whole "feature pack" way of doing
>> things in a different way; are we supposed to only ever use the "main"
>> slot in a feature pack, and allow the consumer to override/filter such
>> ids at provisioning time?
>
>
> You can use whatever slots you want, but at the moment the assumption is
> that you will know what those slots are in advance.

Sounds great, I'll go on digging a bit deeper :) Is there some guide
beyond the README? All I know is based on the readme and the usage I
found in the wildfly/wildfly repository, but that's way more complex
than what I'm trying to build.

Thanks!
Sanne

>
> Stuart
>
>>
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>