Hi all, Tomaž is helping me figure out how we could publish a WildFly feature pack when we do an Hibernate Search release. We already did publish "modules" in a zip format, uploaded to the Maven repository so that people could easily layer a bleeding edge version on top of a slightly outdated WildFly version. We have been doing this for a couple of years now. It's important for our users to have a little bit of flexibility on the exact versions. While it's great for the huge population of Hibernate users to find both Hibernate ORM and Hibernate Search "out of the box" in WildFly, for the minority of those power users which actually help us by contributing or testing each and every release they need to be able to continue "layering" the latest of our releases without waiting for a WildFly release. Not least, that's essential for us to be able to catch bugs ourselves and run every snapshot on integration tests on WildFly. Ales, Tomaž and myself were looking for a way to DRY on the module definitions: as we do far more integration tests of these modules in "upstream" Hibernate Search than what is feasible for us to maintain within the WildFly codebase, it recently happened that the modules in WildFly were lagging behind (structurally different) and not good enough for CapeDwarf purposes. Not an issue for the mass of Hibernate users, but still something we'd want to prevent from happening again. So one solution could be move all our integration tests into WildFly, but that will slow down your build, and still force us all to maintain two sets of identical modules. The other idea is for WildFly to download our feature pack during the assembly of the distribution, and rely on our integration tests. Tomaž actually has a nice branch showcasing how this could work already. But it looks like that if it's up to us to pre-package these modules in advance, we should be using the "main" slot for the modules, as they are copied "as is" into the distribution - while we always considered the usage of the "main" slot as a prerogative of components tightly coupled with the WildFly version. This would imply that when someone fetches our "latest" version and overlays it on WildFly, he would literally overwrite the bits which were shipped with Wildfly, I don't like that idea. Proposal: we'll publish feature packs which make use of the slot to qualify each distribution of our "upstream modules" with a version in format "major.minor"; the WildFly build should then download these and include them as-is, but also include an alias with slot "main" pointing to the exact version which is being included in the WildFly release. We're already using a similar approach between Infinispan and Hibernate Search versions - to use both qualified versions and aliases - as they both publish modules (in different cycles) and yet depend on each other. This approach made it feasible. WDYT? BTW we're paving the road with Hibernate Search, but consider it just an example as several other projects are interested to follow up with a similar scheme. Thanks, Sanne