[PROPOSAL] Changing the FeaturesService.installFeatures() API...

[James Carman <ja...@carmanconsulting.com>]

When implementing the fix for KARAF-4642, I noticed that the
FeaturesService's installFeatures() method takes a Set<String>
(Set<Feature> in 3.0.x).  I propose we change that when we can to
Iterable<String> to indicate that we will iterate through what they give us
and install them *in order*.  It would be a source compatible change, but
not a binary compatible change (existing folks will need to rebuild their
code).  This will allow the BootFeaturesInstaller to pass in a List<String>
instead of Set<String>.  The main issue here is that order is definitely
important when installing features.  What do you guys think?

James

Re: [PROPOSAL] Changing the FeaturesService.installFeatures() API...

["Jamie G." <ja...@gmail.com>]

It makes sense to me. I've always understood the boot features as
having been an ordered list.

Cheers,
Jamie

On Mon, Aug 1, 2016 at 5:02 PM, James Carman <ja...@carmanconsulting.com> wrote:
> When implementing the fix for KARAF-4642, I noticed that the
> FeaturesService's installFeatures() method takes a Set<String>
> (Set<Feature> in 3.0.x).  I propose we change that when we can to
> Iterable<String> to indicate that we will iterate through what they give us
> and install them *in order*.  It would be a source compatible change, but
> not a binary compatible change (existing folks will need to rebuild their
> code).  This will allow the BootFeaturesInstaller to pass in a List<String>
> instead of Set<String>.  The main issue here is that order is definitely
> important when installing features.  What do you guys think?
>
> James