7:26 a.m.
Hi all,
I'm trying to learn how to make proper use of the
`wildfly-feature-pack-build-maven-plugin` to replace our usage of the
assembly plugin.
We extensively use the module slots, and I need to keep the
"{$module.slot}" as a build parameter.
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?
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?
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?
Thanks,
Sanne
11:34 p.m.
On Wed, Jan 10, 2018 at 12:26 AM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
Hi all,
I'm trying to learn how to make proper use of the
`wildfly-feature-pack-build-maven-plugin` to replace our usage of the
assembly plugin.
We extensively use the module slots, and I need to keep the
"{$module.slot}" as a build parameter.
Just out of curiosity what is the use case for this?
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.
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.
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?
You can use whatever slots you want, but at the moment the assumption is
that you will know what those slots are in advance.
Stuart
Thanks,
Sanne
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:55 a.m.
Hi Stuart, thank you so much for the comments! Very helpful.
inline for some answers:
On 11 January 2018 at 05:34, Stuart Douglas <stuart.w.douglas(a)gmail.com> wrote:
On Wed, Jan 10, 2018 at 12:26 AM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
>
> Hi all,
>
> I'm trying to learn how to make proper use of the
> `wildfly-feature-pack-build-maven-plugin` to replace our usage of the
> assembly plugin.
>
> We extensively use the module slots, and I need to keep the
> "{$module.slot}" as a build parameter.
Just out of curiosity what is the use case for this?
I was hoping to spare you all the details, but since you ask :)
In a nutshell, the need to be able to work at different release cycle
/ pace than you all. Decoupling of projects.
The same feature pack is consumed by multiple products / layers which
have an independent release cycle, hence occasionally need to use
diffefrent versions.
For example I'm trying to make a feature pack of our Apache Lucene
modules; these are included in both the WildFly "traditional" server
and in Infinispan Server, which builds on the WildFly server releases;
while we try hard to use the same version, so that often in practice
this won't be necessary, there have been several situations in which
Infinispan would need the ability to include significantly newer
versions of the same modules. This is all compounded by having
different release dates, different purposes as a product and even
different support strategies.. while I understand we have to try hard
to not have multiple copies of the same dependency it's often the only
practical solution.
A big deal is that products layering on top of WildFly might schedule
a different *major* release than other products based on WildFly - so
while you might need to veto a major component upgrade for the reasons
of one, it's the only chance to include such an upgrade for another.
Even before reaching the phase of mature products, our projects often
release intermediate milestones which we need to test among such
projects in various combinations: such major component upgrades don't
happen overnight; for example to prepare the next version of Hibernate
OGM, we need a WildFly server with a bleeding edge updated version of
Hibernate ORM, the very latest Hibernate Search, override the JPA API,
and include the latest "Infinispan modules for WildFly" - yet without
having the bandwith (and capability) to also update all components
which would depend on such components normally, such as the clustering
system of the server. Still we might need the clustering features to
work during such prototype development, which implies the need to
"add" additional copies rather than replace the existing modules to
evolve one aspect at a time.
In some other cases we just need such additional modules to verify the
feasability of running multiple different versions of the same
framework on the WildFly server; for example I need to make sure we
can eventually include both Hibernate ORM 5.1 and Hibernate ORM 6.0 in
the same WildFly server and allow the end users to choose [flawless
backwards compatibility] vs [best performance and latest features].
>
> 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.
>
> 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.
> 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?
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
1: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
>
>
6:59 a.m.
On 15 January 2018 at 07:32, Stuart Douglas <stuart.w.douglas(a)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(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
9:49 p.m.
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.
Stuart
On Mon, Jan 15, 2018 at 11:59 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
On 15 January 2018 at 07:32, Stuart Douglas
<stuart.w.douglas(a)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(a)lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>
>
2540
days inactive
2547
days old
5 comments
2 participants
participants (2)
-
Sanne Grinovero -
Stuart Douglas