[wildfly-dev] selecting packages from feature-packs

[Alexey Loubyansky]

Thanks! I'm going with the proposal 1.

Alexey

On 10/21/2016 05:31 PM, Brian Stansberry wrote:
>
>> On Oct 21, 2016, at 10:03 AM, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>>
>>
>>> On Oct 21, 2016, at 9:20 AM, Alexey Loubyansky <alexey.loubyansky at redhat.com> wrote:
>>>
>>> On 10/21/2016 03:50 PM, Brian Stansberry wrote:
>>>>
>>>>> On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky <alexey.loubyansky at redhat.com> wrote:
>>>>>
>>>>> Me and Stuart have been thinking about how to express feature-pack
>>>>> package selection in an XML. Each one came up with a proposal but we
>>>>> appear to have slightly different preferences. In case anybody has an
>>>>> opinion or a better suggestion, please, share.
>>>>>
>>>>> Brief description: feature-pack consists of packages. A package is a
>>>>> unit of content. So a set of packages determines the target installation
>>>>> content-wise. Feature-pack has a set of default packages. These are the
>>>>> packages that get installed by default, i.e. when the user installs the
>>>>> feature-pack w/o specifying any package preferences. In addition to the
>>>>> default ones a feature-pack may contains non-default packages, these are
>>>>> present in the feature-pack but will be installed only if the user
>>>>> explicitly asks for them.
>>>>> So, the question is how to express these package preferences in an XML.
>>>>>
>>>>> Proposal 1.
>>>>>
>>>>> - include-default flag (element or attribute) which defaults to true
>>>>> (meaning the default packages will be included by default);
>>>>>
>>>>
>>>> Th “include” element is still supported here, right? So, I can get all the default ones and then use include elements to pull in additional ones.
>>>
>>> Right.
>>>
>>>>> - if include-default is false (meaning nothing is installed by default),
>>>>> then 'include' element can be used to pick the specific packages
>>>>> (default and non-default ones) to be installed;
>>>>>
>>>>> - otherwise (when include-default is true) 'exclude' element can be used
>>>>> to exclude specific undesired default packages.
>>>>>
>>>>
>>>> Can “exclude” be used to exclude dependencies? So I want “a” but not its dependency “b”? If the answer is yes for optional dependencies, what if the dependency isn’t optional?
>>>
>>> Yes, it can be used to exclude dependencies. If a required (non-optional) dependency is excluded, that'll be an error.
>>>
>>>>> Proposal 2.
>>>>>
>>>>> - exclude element - applicable to any package and means do not install
>>>>> the package (and its dependencies);
>>>>>
>>>>> - include element - applicable to non-default packages and means do
>>>>> install the non-default package (and its dependencies);
>>>>>
>>>> What happens if it’s used for a default package? The tool forgives this, right?
>>>
>>> That would be redundant, of course. We could ignore that or issue a warning.
>>
>> That question was kind of a tangent. I asked because I could imagine a case where a package is not default in version 1, so the user adds an “include”. Then in a later version the package is now a default one. You don’t want to break the user for no good reason.
>>
>>>
>>>>> - pick element - applicable to any package and means install only the
>>>>> picked package(s)
>>>>
>>>> and it’s dependencies? If yes, all its dependencies or only non-optional?
>>>
>>> No, the dependencies would have to be picked explicitly. Otherwise, we have to allow exclude and include to be used in combination with pick which will look too confusing.
>>>
>>
>> Ok, then assuming that in Proposal 1 an “include” element always means pull in dependencies, I prefer Proposal 1. Forcing people to list everything just to get a subset of the default packages is painful and will likely break things if the feature-pack adds a new dependency in a later version.
>
> I realize my response didn’t account for the fact that in the Proposal 1 section you answered one of my questions by stating that excluding a non-optional dependency is an error.
>
> If the general rule is non-optional dependencies can’t be excluded, I see no reason why “pick” shouldn’t automatically bring them in. And then the only things a user would want to “exclude” in the context of a “pick” are optional dependencies. Which means always excluding them and forcing the user to include them via additional “pick” elements is less terrible.
>
> I still prefer Proposal 1, but not as strongly as I did.
>
>>
>> But…
>>
>> There are cases where people do want to explicitly list things and not have unexpected things brought in. See discussion on https://issues.apache.org/jira/browse/MNG-2315 (for which I voted). I do think it’s good to account for that kind of use case.
>>
>>>>> ignoring other default and non-default ones. pick
>>>>> cannot be used in combination with exclude and include.
>>>>>
>>>>>
>>>>> Basically, 'include' and 'exclude' in both proposals are practically the
>>>>> same. The difference is how the picking is expressed. In the first one,
>>>>> everything is explicitly excluded and then the desired ones are
>>>>> explicitly included, in the second one the desired ones are simply
>>>>> explicitly picked.
>>>>>
>>>>
>>>> The answers to my questions on Proposal 1 impact the semantics of include/exclude in different cases, so I’ll defer expressing an opinion for now. :)
>>>
>>> Thanks,
>>> Alexey
>>>
>>>>
>>>>>
>>>>> Thanks,
>>>>> Alexey
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> JBoss by Red Hat
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>