Details
-
Bug
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
-
None
-
Turing Sprint 171
Description
I have a use case where a downstream project needs to enhance some HST parts. We need to access two different Spring child addon modules from the HST. For this, we need a module.xml with two different parents. That is currently not allowed. This means we need two separate hst
mvn modules for the downstream project : One jar that has a module.xml with parent1 and the other with parent2. This is very undesirable in the downstream project and shouldn't be needed.
First I was thinking to see in the HST if we could support next to module.xml also modules.xml, as follows:
<modules>
<module>
<name>x.y.z</name>
<parent>org.hippoecm.hst.pagecomposer</parent>
<config-locations>
<config-location>classpath*:META-INF/hst-assembly/addon/x/y/z/*.xml</config-location>
</config-locations>
</module>
<module>
<name>a.b.c</name>
<parent>org.hippoecm.hst.cmsrest</parent>
<config-locations>
<config-location>classpath*:META-INF/hst-assembly/addon/a/b/c/*.xml</config-location>
</config-locations>
</module>
</modules>
However, it could be achieved easier if we support <module> to also be able to be an 'envelope' only because the <module> already supports child modules. I decided that to make a <module> an envelope item, all that is needed is to not specify a <name> element. The above can thus be achieved in module.xml as follows:
<module xmlns="http://www.onehippo.org/schema/hst/hst-addon-module_1_0.xsd">
<modules>
<module>
<name>x.y.z</name>
<parent>org.hippoecm.hst.pagecomposer</parent>
<config-locations>
<config-location>classpath*:META-INF/hst-assembly/addon/x/y/z/*.xml</config-location>
</config-locations>
</module>
<module>
<name>a.b.c</name>
<parent>org.hippoecm.hst.cmsrest</parent>
<config-locations>
<config-location>classpath*:META-INF/hst-assembly/addon/a/b/c/*.xml</config-location>
</config-locations>
</module>
</modules>
</module>