On 15 January 2018 at 07:32, Stuart Douglas <stuart.w.douglas@gmail.com> wrote:
>
>> >>
>> >> It looks like the Feature Pack plugin is expecting the module.xml
>> >> files to be statically committed into the same directory structure as
>> >> were they need to end up, but since the slot id needs to be part of
>> >> such path, looks like I can't use it? Should I pre-process the module
>> >> resources with the assembly plugin?
>> >
>> >
>> > 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.
>>
>> Right, I'm aware that WildFly uses "main" consistently, but since I'm
>> having the impression these tools have a wider scope, I guess such
>> features might be introduced?
>>
>> If I were able to package all the Hibernate libraries and our
>> dependencies into feature packs that should also simplify and speedup
>> the build of WildFly itself, but I need the slots too for the above
>> reasons.
>>
>> For the record, the slots system - and the aliases as well - have been
>> extremely useful for many of our other projects, so thanks again for
>> that.
>>
>
> 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.
>
>>
>> >>
>> >> I was hoping for the feature-pack-build.xml to have a way to define
>> >> modules by giving it an identifier (possibly having parameters), point
>> >> them to a template xml (optionally filtered), and not having to deal
>> >> with the copy-to paths explicitly. It seems odd to have to copy the
>> >> jar files and other resources into a matching structure, maybe this
>> >> could be automated by the plugin?
>> >
>> >
>> > 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.
>>
>> I'm quite confused on how that's working, where it's inferring the
>> details from; I guess I'll experiment a bit more but I'm not
>> understanding how the tool would know which jars I mean to include in
>> each module.
>
>
> 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:
>
>         <artifact name="${org.hibernate:hibernate-core}"/>
>
> 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:
>
> - Replace the name with the actual GAV if this is a 'thin' server
> - Replace the artifact tag with a <resource> tag and copy the relevant jar
> into the directory if it is a fat server

Thanks, that helped. For the record, I was using
<scope>provided</scope> for all our dependencies and that somehow
prevented the plugin to figure it out.

May I suggest to not exlude the "provided" dependencies if there is no
strong reason for that?

It's also nicer for consumers of the feature pack, as they won't have
to exclude "*", but primarily I'm suggesting this as it caused me some
confusion. If you need to maintain the current behaviour I'd suggest
an explicit error so other people won't have to debug the plugin.

Thanks,
Sanne

>
>>
>>
>> >> Or perhaps I should look at the whole "feature pack" way of doing
>> >> things in a different way; are we supposed to only ever use the "main"
>> >> slot in a feature pack, and allow the consumer to override/filter such
>> >> ids at provisioning time?
>
>
> The slot should not matter, there is nothing really special about the main
> slot from the point of view of the plugin.
>
> Stuart
>
>>
>> >
>> >
>> > You can use whatever slots you want, but at the moment the assumption is
>> > that you will know what those slots are in advance.
>>
>> Sounds great, I'll go on digging a bit deeper :) Is there some guide
>> beyond the README? All I know is based on the readme and the usage I
>> found in the wildfly/wildfly repository, but that's way more complex
>> than what I'm trying to build.
>>
>> Thanks!
>> Sanne
>>
>> >
>> > Stuart
>> >
>> >>
>> >>
>> >> Thanks,
>> >> Sanne
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev@lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>
>