I see two issues here ...
1. For Keycloak we are targetting previous wildfly / eap versions as well. Feature packs
functionality targets Wildfly 9+ IIUC so we can't use it for previous versions.
2. We support distribution packaging we call overlay distribution ... where all we provide
is modules + configuration resources which users simply unzip into existing wildfly / eap
directory. I'm not sure feature packs support this at all. For example, can I do a
feature pack that only produces a set of modules, and where I can specify which
jboss-modules version to target?
Currently we use old school modules generation (ant plugin, build.xml, lib.xml) for
previous versions of wildfly / eap, and feature pack for Wildfly 9 where we cheat for
overlay distributions by doing full pack and only copy modules from it into our
distribution archive.
----- Original Message -----
On 6/16/2015 8:36 AM, Tomaž Cerar wrote:
A feature-pack can extend another feature pack,
I am sure you guys know that.
so you could have "keycloak-base" feature pack that all other 3 extend.
the base would than have all common modules defined.
and other 3 extra specializations.
That's an OK approach if there is a well-defined base of modules that several
projects use. But that's really not the case.
In any feature pack I should be able to just list the artifacts I'm using and
it provides a default module.xml file for that.
--
tomaz
On Tue, Jun 16, 2015 at 2:18 PM, Stan Silvert < ssilvert(a)redhat.com > wrote:
Cross-posting to wildfly-dev.
It sounds like we need a way to standardize module.xml definitions
across projects and have them accessible from maven GAV's. These
module.xml files are rarely different between projects and it doesn't
make sense for each feature pack to define its own copy.
On 6/15/2015 4:08 PM, Bill Burke wrote:
> Module definition is now done in 3 places? Copies of one another?
>
> eap6-service-overlay
> server-feature-pack
> adapter-feature-pack
>
> This is very very error prone guys. I guarantee somebody will forget to
> update something.
>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev