<div dir="ltr">I am not sure why the provided dependencies were not being resolved, internally this works by just calling org.apache.maven.project.MavenProject#getArtifacts(), and then building a map from the result. I can't see anything in the docs that would suggest that provided deps would not be resolved.<div><br></div><div>Stuart</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 15, 2018 at 11:59 PM, 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"><div class="HOEnZb"><div class="h5">On 15 January 2018 at 07:32, Stuart Douglas <<a href="mailto:stuart.w.douglas@gmail.com">stuart.w.douglas@gmail.com</a>> wrote:<br>
><br>
>> >><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<br>
>> > just<br>
>> > use the slot main, and we don't vary any part of a module name based on<br>
>> > a<br>
>> > build parameter.<br>
>><br>
>> 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>
>><br>
><br>
> There is nothing stopping you from using slots, its just that at the moment<br>
> there is no support for the slot name to be dynamic.<br>
><br>
>><br>
>> >><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.<br>
>> > They<br>
>> > are laid out the way they are at the moment because it just seemed to be<br>
>> > 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<br>
>> > we<br>
>> > used a templating approach each template would be unique anyway.<br>
>><br>
>> 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>
><br>
><br>
> It traverses the modules directory, and looks at each module.xml. Each<br>
> module lists its resource as a maven group and artifact property, somthing<br>
> like:<br>
><br>
> <artifact name="${org.hibernate:<wbr>hibernate-core}"/><br>
><br>
> When it assembles the feature pack it looks for the version of hibernate<br>
> core that is declared in the pom, and inserts that version into the feature<br>
> pack. At provisioning time it will either:<br>
><br>
> - Replace the name with the actual GAV if this is a 'thin' server<br>
> - Replace the artifact tag with a <resource> tag and copy the relevant jar<br>
> into the directory if it is a fat server<br>
<br>
</div></div>Thanks, that helped. For the record, I was using<br>
<scope>provided</scope> for all our dependencies and that somehow<br>
prevented the plugin to figure it out.<br>
<br>
May I suggest to not exlude the "provided" dependencies if there is no<br>
strong reason for that?<br>
<br>
It's also nicer for consumers of the feature pack, as they won't have<br>
to exclude "*", but primarily I'm suggesting this as it caused me some<br>
confusion. If you need to maintain the current behaviour I'd suggest<br>
an explicit error so other people won't have to debug the plugin.<br>
<br>
Thanks,<br>
Sanne<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>><br>
>><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>
><br>
><br>
> The slot should not matter, there is nothing really special about the main<br>
> slot from the point of view of the plugin.<br>
><br>
> Stuart<br>
><br>
>><br>
>> ><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>
>> 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>
>> Sanne<br>
>><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>
><br>
><br>
</div></div></blockquote></div><br></div>