On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky <alexey.loubyansky(a)redhat.com&gt; 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);

- 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 wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Oct 21, 2016, at 9:20 AM, Alexey Loubyansky <alexey.loubyansky(a)redhat.com&gt; wrote: On 10/21/2016 03:50 PM, Brian Stansberry wrote: > >> On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky <alexey.loubyansky(a)redhat.com&gt; 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 >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev

> On Oct 21, 2016, at 10:03 AM, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: > > >> On Oct 21, 2016, at 9:20 AM, Alexey Loubyansky <alexey.loubyansky(a)redhat.com&gt; wrote: >> >> On 10/21/2016 03:50 PM, Brian Stansberry wrote: >>> >>>> On Oct 19, 2016, at 7:27 AM, Alexey Loubyansky <alexey.loubyansky(a)redhat.com&gt; 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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev