FIXED - CSD03 - Support of secured repositories for artifacts

I am proposing two options for the discussion and would love to hear more. Examples of both options are available in the working document https://www.oasis-open.org/apps/org/workgroup/tosca/document.php?document_id=53454 Option-1 (Preferred by me) The first option consists on TOSCA standards with additional root keynames "repositories" and "repository_types" to describe external repositories (see option-1.zip). The same as any TOSCA element, these elements can reside within the same service template file or can also be extracted to an additional dedicated file (e.g. option1-repositories.yaml.ste) in order to keep it decoupled from the rest of the service template. Each repository element will contain a list of the artifacts it holds. Pros: • Reuse existing parsing mechanism. • Reuse existing inputs mechanism. • Does not break current TOSCA implementation: repositories implementation is decoupled. (Node-template artifacts are searched by key in repository artifacts) Cons: • The repositories info does not really belong to the service template as it is more related to the env the application is deployed on (We tried to address this issue by placing the "repositories" section in a separate file and making the reference from the repository to the artifact instead of from the artifact to its repository). Option-2 The second option uses an archive’s MANIFEST.MF file to describe deployment’s external repositories (see MANIFEST.MF). While this alternative does not break TOSCA implementation (see option2.yaml.ste) it does makes an abnormal use of MANIFEST.MF file which meant to describe an archive contents only. MANIFEST.MF also forces its own syntax and is not flexible as yaml is. Generating MANIFEST.MF file is most likely automated and additional properties will either need to be added manually or by a dedicated framework. Pros: • Very clear decoupling of repositories from TOSCA service template. • One central place to describe all of an application artifacts. Cons: • Abnormal use of MANIFEST.MF file. • Dedicated MANIFEST.MF parser (on top of java.util.jar.Manifest) is required. • Dedicated inputs mechanism will need to be developed.