[wildfly-dev] Feature packs and slots

[Stuart Douglas]

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 at hibernate.org>
wrote:

> On 15 January 2018 at 07:32, Stuart Douglas <stuart.w.douglas at 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 at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180116/7eb5510b/attachment.html