This is an automated email from the ASF dual-hosted git repository.
cziegeler pushed a commit to branch master
in repository
https://gitbox.apache.org/repos/asf/sling-org-apache-sling-feature.git
The following commit(s) were added to refs/heads/master by this push:
new fffdaa2 Add second proposal
fffdaa2 is described below
commit fffdaa2bab6b301e4894c6cc3698426329febc19
Author: Carsten Ziegeler <[email protected]>
AuthorDate: Tue Jul 31 14:13:04 2018 +0200
Add second proposal
---
appconf.md | 23 +++++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/appconf.md b/appconf.md
index 745c825..d495541 100644
--- a/appconf.md
+++ b/appconf.md
@@ -1,18 +1,26 @@
# Provisioning Applications Proposal
-There are use case where you want to describe a whole application based on
features. In addition some parts might to be optional.
+There are use case where you want to describe a whole application based on
features. In addition some parts might to be optional. In the below proposal we
use the term "option" and "choice" which in the past is referred to as a
runmode in the Sling world. To distinguish these, we use more general terms in
this proposal.
+
+The two proposals basically differ in where the knowledge whether a feature
should be included is stored: does the feature itself know when it should be
included (proposal 2) or is this knowledge outside of the feature (proposal 1).
+
+## Proposal 1 : Additional Configuration
A application configuration for such use cases could look like this:
{
+ // this is a list of required features
"application" : [
"org.apache.sling:org.apache.sling.launchpad:10"
],
+ // this is a list of optional features
"repository" : [
"org.apache.sling:org.apache.sling.portal:1.0."
],
+ // choices provide two or more names which are mutually exclusive
+ // like "author" and "publish" in the example below
"choices" : [
- [
+ [
{
"name" : "author",
"features" : [
@@ -38,12 +46,15 @@ A application configuration for such use cases could look
like this:
]
"options" : {
"jsp" : {
+ // this feature is only included if the jsp option is selected
"features" : [
"org.apache.sling:org.apache.sling.scripting.jsp:1.0.0"
]
},
"samplecontent" : {
"choices" : {
+ // the key refers to a comma separated list of choices
that need to be selected in order to
+ // include the below features
"author" : {
"features" : [
"org.apache.sling:org.apache.sling.samples.author:1.0.0"
@@ -72,3 +83,11 @@ The options section contains labeled options. An option has
a list of features a
An option can also set additional variables - which in turn can be used within
the included features.
The defaults section specifies the options activated by default and the
framework section defines the framework to be used.
+
+## Proposal 2 : Requirements Based
+
+Instead of maintaining an additional configuration a feature could itself
define when it should be activated. Therefore for example a feature which
should be bound to the author could have a requirement on the "option"
"author". Similar with publish based features. As there is no limit on
requirements, a feature can have a requirement on more than one option. These
options could be set through some runtime switch similar to how we enable run
modes today.
+
+If a 3rd party feature should be used in this way but does not declare such a
requirement, the inheritance mechanism could be used to create a new feature
inheriting that one and adding the requirement.
+
+It would still be beneficial to have a variable mechanism as shown with
proposal 1 to set a variable to either "author" or "publish" to be reused
within a feature.
