OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] Commented: (CAMP-63) TypeDefinitions for CAMP-defined types

    [ http://tools.oasis-open.org/issues/browse/CAMP-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36406#action_36406 ] 

Gilbert Pilz commented on CAMP-63:

1.) I don't know what file you are referring to. There is no file named "typeDefinitions.json" in the latest ZIP. I grepped all the .json files for "nCAMP" and couldn't find anything.

2.) I can update the proposal with a version of the main spec that has such a link.

3.) I can update the proposal with a version of the main spec that has these changes in Section 5.

4.) These files aren't "pseudo JSON", they are valid JSON objects. The various URIs are local and self-consistent. A CAMP platform developer should be able to unzip these files to "the appropriate" location and have them work.

> TypeDefinitions for CAMP-defined types
> --------------------------------------
>                 Key: CAMP-63
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-63
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>          Components: Spec
>            Reporter: Gilbert Pilz
>            Priority: Minor
> In WD08 Section 5.20.1 (description of TypeDefinitions.typeDefinitionLinks) it reads:
> "This attribute contains Links to TypeDefinition resources that contain information about resource types supported by the Platform. If the Platform does not extend this Specification to add new resource types then the array can be empty. If the array is non-empty, for every resource type that the Platform supports, there MUST be a TypeDefinition resource Link that represents such a resource type."
> If I understand this correctly, this means that if I were to add a new resource type (e.g. org.example.apache:TomcatServer) not only would I have to create a TypeDefinition resource that describes it (along with all its AttribueDefinition resources) but I would also be required to create TypeDefinition resources for Platform, Assembly Template, Application Component Template, Platform Component Template, etc. All this just because I wanted to add one resource type! If I were a developer I would not be at all enthused about having to write all the details of CAMP-defined resource as a prerequisite to defining my own resource type.
> I think the CAMP spec should contain annex that provides the TypeDefinition trees for each of the CAMP-defined resources. Not only would this save developers time, it would also ensure uniformity of the TypeDefinition trees across CAMP implementations. In addition to this, it would provide a style guide for devs that create their own resource types.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]