<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
>><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>
><br>
><br>
> Yes, at the moment there is no way to handle this. In general in WF we just<br>
> use the slot main, and we don't vary any part of a module name based on a<br>
> build parameter.<br>
<br>
</span>Right, I'm aware that WildFly uses "main" consistently, but since I'm<br>
having the impression these tools have a wider scope, I guess such<br>
features might be introduced?<br>
<br>
If I were able to package all the Hibernate libraries and our<br>
dependencies into feature packs that should also simplify and speedup<br>
the build of WildFly itself, but I need the slots too for the above<br>
reasons.<br>
<br>
For the record, the slots system - and the aliases as well - have been<br>
extremely useful for many of our other projects, so thanks again for<br>
that.<br>
<span class="gmail-"><br></span></blockquote><div><br></div><div>There is nothing stopping you from using slots, its just that at the moment there is no support for the slot name to be dynamic.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
>><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>
><br>
><br>
> You don't have to copy the jar files, the plugin does it automatically. They<br>
> are laid out the way they are at the moment because it just seemed to be the<br>
> simplest way to do it at the time. We did not need another layer of<br>
> indirection as generally each module has its own unique module.xml so if we<br>
> used a templating approach each template would be unique anyway.<br>
<br>
</span>I'm quite confused on how that's working, where it's inferring the<br>
details from; I guess I'll experiment a bit more but I'm not<br>
understanding how the tool would know which jars I mean to include in<br>
each module.<br></blockquote><div><br></div><div>It traverses the modules directory, and looks at each module.xml. Each module lists its resource as a maven group and artifact property, somthing like:</div><div><div><br></div><div> <artifact name="${org.hibernate:hibernate-core}"/></div></div><div><br></div><div>When it assembles the feature pack it looks for the version of hibernate core that is declared in the pom, and inserts that version into the feature pack. At provisioning time it will either:</div><div><br></div><div>- Replace the name with the actual GAV if this is a 'thin' server</div><div>- Replace the artifact tag with a <resource> tag and copy the relevant jar into the directory if it is a fat server</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><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></span></blockquote><div><br></div><div>The slot should not matter, there is nothing really special about the main slot from the point of view of the plugin.</div><div><br></div><div>Stuart</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
><br>
><br>
> You can use whatever slots you want, but at the moment the assumption is<br>
> that you will know what those slots are in advance.<br>
<br>
</span>Sounds great, I'll go on digging a bit deeper :) Is there some guide<br>
beyond the README? All I know is based on the readme and the usage I<br>
found in the wildfly/wildfly repository, but that's way more complex<br>
than what I'm trying to build.<br>
<br>
Thanks!<br>
<span class="gmail-HOEnZb"><font color="#888888">Sanne<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
><br>
> Stuart<br>
><br>
>><br>
>><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>
><br>
><br>
</div></div></blockquote></div><br></div></div>