selecting packages from feature-packs

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

selecting packages from feature-packs

Alexey Loubyansky
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);

- 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.


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);

- pick element - applicable to any package and means install only the
picked package(s) 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.


Thanks,
Alexey
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: selecting packages from feature-packs

Brian Stansberry

> On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky <[hidden email]> 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.

> - 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?

>
> 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?

> - 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?

> 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
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: selecting packages from feature-packs

Alexey Loubyansky
On 10/21/2016 03:50 PM, Brian Stansberry wrote:

>
>> On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky <[hidden email]> 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.

>> - 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.

>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: selecting packages from feature-packs

Brian Stansberry

> On Oct 21, 2016, at 9:20 AM, Alexey Loubyansky <[hidden email]> wrote:
>
> On 10/21/2016 03:50 PM, Brian Stansberry wrote:
>>
>>> On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky <[hidden email]> 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.

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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: selecting packages from feature-packs

Brian Stansberry

> On Oct 21, 2016, at 10:03 AM, Brian Stansberry <[hidden email]> wrote:
>
>
>> On Oct 21, 2016, at 9:20 AM, Alexey Loubyansky <[hidden email]> wrote:
>>
>> On 10/21/2016 03:50 PM, Brian Stansberry wrote:
>>>
>>>> On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> JBoss by Red Hat
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat




_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> wrote:
>>
>>
>>> On Oct 21, 2016, at 9:20 AM, Alexey Loubyansky <[hidden email]> wrote:
>>>
>>> On 10/21/2016 03:50 PM, Brian Stansberry wrote:
>>>>
>>>>> On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky <[hidden email]> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> JBoss by Red Hat
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev