We have a few projects where a multitude of semi-independent projects live in the same hippo project. We would love to split up both the webfiles and the site modules into their own maven modules. That way, we could model dependencies via Maven and have seperate development teams, while still deploying to a single Hippo instance.
How would we go about that? We would need to mark certain modules as webfiles and site modules.
we don’t support multiple site modules in one project. This may be something in our long term strategy but we don’t have any solution for the time being. You could split up the webfiles to various teams.
It is true that currently the product does not support this use case natively; however I can confirm that we are currently working on enhancing this part of the product and this improvement is due to be included within our upcoming major release of v13 later this year and will be available for our Enterprise Customers.
While of course this doesn’t help to resolve your challenges right now, it might be worth considering how this could affect your planning for the near future.
Product Management - BloomReach
Is this enhancement still on track for v13? And can you provide an updated ETA for that release?
In case you haven’t already discovered this yourself from our documentation and release announcements… 13.0 (and now 13.1) are now available to customers. We have built multiple site support into the core of the product, with separate site wars as the core unit of deployment. We also extended our configuration management system to allow a shared HST config to be reused across multiple sites with a straightforward maven-style, versioned dependency model.
I gave a talk about this at Connect AMS 2018. The video is here. Documentation is here.
If you don’t want to use the new separate-site-war style but just want to split up your config into smaller units, you can get part-way there with the basic config management stuff. The main limitation is that HST still only supports a single webfiles bundle per site. If all the teams are contributing to a single war, they have to coordinate more closely and contribute to a single deployable war artifact. You can put most of the config in separate modules, but use one webfiles bundle module that is subdivided into subdirectories per team, for example. It’s a bit awkward, but it can work.
I did another talk about the config management system and a lot of the details of how the dependency structure for config works at Connect AMS 2017. There’s a slides+audio version here.
brXM Platform Team Lead