<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 10, 2018 at 12:26 AM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@hibernate.org" target="_blank">sanne@hibernate.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I'm trying to learn how to make proper use of the<br>
`wildfly-feature-pack-build-<wbr>maven-plugin` to replace our usage of the<br>
assembly plugin.<br>
<br>
We extensively use the module slots, and I need to keep the<br>
"{$module.slot}" as a build parameter.<br></blockquote><div><br></div><div>Just out of curiosity what is the use case for this? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It looks like the Feature Pack plugin is expecting the module.xml<br>
files to be statically committed into the same directory structure as<br>
were they need to end up, but since the slot id needs to be part of<br>
such path, looks like I can't use it? Should I pre-process the module<br>
resources with the assembly plugin?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I was hoping for the feature-pack-build.xml to have a way to define<br>
modules by giving it an identifier (possibly having parameters), point<br>
them to a template xml (optionally filtered), and not having to deal<br>
with the copy-to paths explicitly. It seems odd to have to copy the<br>
jar files and other resources into a matching structure, maybe this<br>
could be automated by the plugin?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Or perhaps I should look at the whole "feature pack" way of doing<br>
things in a different way; are we supposed to only ever use the "main"<br>
slot in a feature pack, and allow the consumer to override/filter such<br>
ids at provisioning time?<br></blockquote><div><br></div><div>You can use whatever slots you want, but at the moment the assumption is that you will know what those slots are in advance.</div><div><br></div><div>Stuart</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Sanne<br>
______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a><br>
</blockquote></div><br></div></div>