2:32 a.m.
>>
>> 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
>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>