Issue 8212: RAS FTF: add support for Activity Parameters (ras-ftf) Source: International Business Machines (Mr. Grant Larsen, gjlarsen@us.ibm.com) Nature: Uncategorized Issue Severity: Summary: Default Profile Change Request: Activity Parameters Table of Contents 1. Introduction 4 2. References 4 3. Design Requirements 4 4. Design Constraints 4 5. Issues 4 5.1 Specifying parameters for an Activity is very difficult 4 5.1.1 Description 4 6. Considered Approaches 4 6.1 Preferred Approach - Add class ActivityParameter to the metamodel 4 6.1.1 Description 4 6.1.2 Pros 5 6.1.3 Cons 5 6.2 Alternate Approach 1 – Include the Parameters in an Activity attribute 5 6.2.1 Description 5 6.2.2 Pros 5 6.2.3 Cons 5 6.3 Alternate Approach 2 – Expand the class VariabilityPointBinding 5 6.3.1 Description 5 6.3.2 Pros 6 6.3.3 Cons 6 7. Design Artifacts 6 7.1 Figure 1 6 7.2 Figure 2 7 7.3 Figure 3 7 7.4 Example 1 8 8. Future Considerations 9 9. Draft Reviews Threads 9 1. Introduction This document describes the issues the RAS Aurora Program development team has experienced while trying to write tooling to effectively exploit the activity element in the RAS default profile. It also contains a proposal to help alleviate these issues. 2. References · Reusable Asset Specification(04-06-06.pdf) 3. Design Requirements · Provide a mechanism to easily associate parameters with an activity · Concretely define the relationship between activities and their parameters at the metamodel level 4. Design Constraints · Require only minor changes to the current default profile metamodel 5. Issues 5.1 Specifying parameters for an Activity is very difficult 5.1.1 Description It’s quite common to include asset or artifact activities in a RAS manifest that are interrogated by clients during some part of the asset’s lifecycle. Often the activity requires additional pieces of information that’s used by the client to help execute the activity in one manner or another during processing. For example, IBM’s Eclipse based RAS implementation provides an activity to build a deployable project that’s processed during asset packaging. The RAS manifest author has the option to build that project with or without source and package the binaries in different formats. In today’s default profile metamodel, there doesn’t appear to be a clear, simple way to specify the options. Ideally the metamodel should provide a way to express the parameters for an activity in an unambiguous way. Below are a few approaches we considered including a preferred approach to resolving this issue. We are open to other suggestions as well. 6. Considered Approaches 6.1 Preferred Approach - Add class ActivityParameter to the metamodel 6.1.1 Description Our preferred approach is to add a new class called ActivityParameter to the metamodel for the default profile that extends the class Descriptor. This new class would contain one attribute named defaultValue that would provide the ability to specify for the parameter exactly what the name implies…a default value. The name and value attributes inherited from the Descriptor class would provide the mechanism for defining the parameters and their values. See Figure 1 and Example 1. 6.1.2 Pros · Concretely defines the relationship between activities and their parameters in a clear, straight forward manner. · Client will not have to interrogate the attributes of other elements to try to determine if they are the parameters for activity. · The parameters will not have to be included in one of the attributes of the activity. 6.1.3 Cons · New class and relationships must be added to the metamodel 6.2 Alternate Approach 1 – Include the Parameters in an Activity attribute 6.2.1 Description Include the parameters as part of one of the existing activity attributes. Use special characters to denote the parameters and their values so that they can be specified and accessed by clients. 6.2.2 Pros · Requires no changes to the current default profile metamodel 6.2.3 Cons · No clear relationship between the activity and the parameters · Adds confusing extraneous information to activity attributes that doesn’t apply to the attribute. · Clients must know which attribute contains the parameters and how to specify/access them 6.3 Alternate Approach 2 – Expand the class VariabilityPointBinding 6.3.1 Description Add a new attribute to the class VariabilityPointBinding. This will provide a way to associate the parameters with the activity using an existing metamodel relationship. See Figure 2 or Figure 3.. 6.3.2 Pros · Requires no new classes to be added to the metamodel · Provides a mechanism to associate parameters to an activity through an existing relationship. 6.3.3 Cons · No clear relationship between the activity and the parameters. The binding rules will have to be interrogated to find a particular binding rule and then process it. · Using the VariabilityPointBinding class for this purpose doesn’t really seem like what the intended purpose is according to the RAS spec. It’s tied to a VariabilityPoint which doesn’t necessarily apply. · A new attribute must be added to the VariabilityPointBinding class. 7. Design Artifacts 7.1 Figure 1 7.2 Figure 2 7.3 Figure 3 7.4 Example 1 An example expansion of the XML in a RAS manifest for an activity with parameters for the preferred solution: <artifactActivity artifact="//@solution/@artifact.0"> <activity task="Build Deployable Project" role="com.ibm.xtools.ras.export" taskType="com.ibm.xtools.ras.BuildDeployableProject"> <activityParameter name="includeSource" value="true" defaultValue="false" /> </activity> </artifactActivity> Thanks, Grant ----------------------------------------------------------- Grant Larsen STSM IBM Rational software Voice: (303) 932-7368 Mobile: (303) 601-1257 Fax: (303) 932-6963 Notes: Grant J Larsen/Denver/IBM E-mail: gjlarsen@us.ibm.com RAS FTF add support for Activi.gif RAS FTF add support for Activi1.gif RAS FTF add support for Activi2.gif Resolution: Revised Text: Resolution: In the voting on this issue, please indicate the "preferred" approach, alternate 1, or alternate 2. The "preferred" approach is to add a new class called ActivityParameter to the metamodel for the default profile that extends the class Descriptor. This new class would contain one attribute named defaultValue that would provide the ability to specify for the parameter exactly what the name implies…a default value. The name and value attributes inherited from the Descriptor class would provide the mechanism for defining the parameters and their values. The figure below illustrates the change to the model being proposed by this approach. The activityParameter node in the XML snippet below is the new element that would be added. <artifactActivity artifact="//@solution/@artifact.0"> <activity task="Build Deployable Project" role="com.ibm.xtools.ras.export" taskType="com.ibm.xtools.ras.BuildDeployableProject"> <activityParameter name="includeSource" value="true" defaultValue="false" /> </activity> </artifactActivity> Pros · Concretely defines the relationship between activities and their parameters in a clear, straight forward manner. · Client will not have to interrogate the attributes of other elements to try to determine if they are the parameters for activity. · The parameters will not have to be included in one of the attributes of the activity. Cons · New class and relationships must be added to the metamodel Alternate Approach 1 - Include the Parameters in an Activity attribute Description Include the parameters as part of one of the existing activity attributes. Use special characters to denote the parameters and their values so that they can be specified and accessed by clients. Pros · Requires no changes to the current default profile metamodel Cons · No clear relationship between the activity and the parameters · Adds confusing extraneous information to activity attributes that doesn't apply to the attribute. · Clients must know which attribute contains the parameters and how to specify/access them Alternate Approach 2 - Expand the class VariabilityPointBinding Description Add a new attribute to the class VariabilityPointBinding. This will provide a way to associate the parameters with the activity using an existing metamodel relationship. The figures below capture the model changes for this approach. Pros · Requires no new classes to be added to the metamodel · Provides a mechanism to associate parameters to an activity through an existing relationship. Cons · No clear relationship between the activity and the parameters. The binding rules will have to be interrogated to find a particular binding rule and then process it. · Using the VariabilityPointBinding class for this purpose doesn't really seem like what the intended purpose is according to the RAS spec. It's tied to a VariabilityPoint which doesn't necessarily apply. · A new attribute must be added to the VariabilityPointBinding class. Actions taken: February 2, 2005: received issue August 1, 2005: closed issue Discussion: End of Annotations:===== ubject: RAS FTF: add support for Activity Parameters X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Grant J Larsen Date: Wed, 2 Feb 2005 06:24:09 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 02/02/2005 06:24:16, Serialize complete at 02/02/2005 06:24:16 Default Profile Change Request: Activity Parameters Table of Contents 1. Introduction 4 2. References 4 3. Design Requirements 4 4. Design Constraints 4 5. Issues 4 5.1 Specifying parameters for an Activity is very difficult 4 5.1.1 Description 4 6. Considered Approaches 4 6.1 Preferred Approach - Add class ActivityParameter to the metamodel 4 6.1.1 Description 4 6.1.2 Pros 5 6.1.3 Cons 5 6.2 Alternate Approach 1 . Include the Parameters in an Activity attribute 5 6.2.1 Description 5 6.2.2 Pros 5 6.2.3 Cons 5 6.3 Alternate Approach 2 . Expand the class VariabilityPointBinding 5 6.3.1 Description 5 6.3.2 Pros 6 6.3.3 Cons 6 7. Design Artifacts 6 7.1 Figure 1 6 7.2 Figure 2 7 7.3 Figure 3 7 7.4 Example 1 8 8. Future Considerations 9 9. Draft Reviews Threads 9 1. Introduction This document describes the issues the RAS Aurora Program development team has experienced while trying to write tooling to effectively exploit the activity element in the RAS default profile. It also contains a proposal to help alleviate these issues. 2. References · Reusable Asset Specification(04-06-06.pdf) 3. Design Requirements · Provide a mechanism to easily associate parameters with an activity · Concretely define the relationship between activities and their parameters at the metamodel level 4. Design Constraints · Require only minor changes to the current default profile metamodel 5. Issues 5.1 Specifying parameters for an Activity is very difficult 5.1.1 Description It.s quite common to include asset or artifact activities in a RAS manifest that are interrogated by clients during some part of the asset.s lifecycle. Often the activity requires additional pieces of information that.s used by the client to help execute the activity in one manner or another during processing. For example, IBM.s Eclipse based RAS implementation provides an activity to build a deployable project that.s processed during asset packaging. The RAS manifest author has the option to build that project with or without source and package the binaries in different formats. In today.s default profile metamodel, there doesn.t appear to be a clear, simple way to specify the options. Ideally the metamodel should provide a way to express the parameters for an activity in an unambiguous way. Below are a few approaches we considered including a preferred approach to resolving this issue. We are open to other suggestions as well. 6. Considered Approaches 6.1 Preferred Approach - Add class ActivityParameter to the metamodel 6.1.1 Description Our preferred approach is to add a new class called ActivityParameter to the metamodel for the default profile that extends the class Descriptor. This new class would contain one attribute named defaultValue that would provide the ability to specify for the parameter exactly what the name implies.a default value. The name and value attributes inherited from the Descriptor class would provide the mechanism for defining the parameters and their values. See Figure 1 and Example 1. 6.1.2 Pros · Concretely defines the relationship between activities and their parameters in a clear, straight forward manner. · Client will not have to interrogate the attributes of other elements to try to determine if they are the parameters for activity. · The parameters will not have to be included in one of the attributes of the activity. 6.1.3 Cons · New class and relationships must be added to the metamodel 6.2 Alternate Approach 1 . Include the Parameters in an Activity attribute 6.2.1 Description Include the parameters as part of one of the existing activity attributes. Use special characters to denote the parameters and their values so that they can be specified and accessed by clients. 6.2.2 Pros · Requires no changes to the current default profile metamodel 6.2.3 Cons · No clear relationship between the activity and the parameters · Adds confusing extraneous information to activity attributes that doesn.t apply to the attribute. · Clients must know which attribute contains the parameters and how to specify/access them 6.3 Alternate Approach 2 . Expand the class VariabilityPointBinding 6.3.1 Description Add a new attribute to the class VariabilityPointBinding. This will provide a way to associate the parameters with the activity using an existing metamodel relationship. See Figure 2 or Figure 3.. 6.3.2 Pros · Requires no new classes to be added to the metamodel · Provides a mechanism to associate parameters to an activity through an existing relationship. 6.3.3 Cons · No clear relationship between the activity and the parameters. The binding rules will have to be interrogated to find a particular binding rule and then process it. · Using the VariabilityPointBinding class for this purpose doesn.t really seem like what the intended purpose is according to the RAS spec. It.s tied to a VariabilityPoint which doesn.t necessarily apply. · A new attribute must be added to the VariabilityPointBinding class. 7. Design Artifacts 7.1 Figure 1 7.2 Figure 2 7.3 Figure 3 7.4 Example 1 An example expansion of the XML in a RAS manifest for an activity with parameters for the preferred solution: Thanks, Grant ----------------------------------------------------------- Grant Larsen STSM IBM Rational software Voice: (303) 932-7368 Mobile: (303) 601-1257 Fax: (303) 932-6963 Notes: Grant J Larsen/Denver/IBM E-mail: gjlarsen@us.ibm.com RAS FTF add support for Activi.gif RAS FTF add support for Activi1.gif Subject: RE: issue 8212 -- RAS FTF issue Date: Sun, 13 Feb 2005 06:25:36 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 8212 -- RAS FTF issue Thread-Index: AcUQfJrENR9KieLgR2uMjp20v/WSTwBP5nNg From: "Pete Rivett" To: "Grant J Larsen" Cc: "Juergen Boldt" X-Virus-Scanned: by amavisd-new at sentraliant.com Hi Grant The diagrams are not visible here: in general the OMG's issue management is very basic and does not cope well with anything except plain text (e.g. if people try to access the issue form the OMG site). I suggest you upload the document to the RAS FTP site and refer to it from the issue. There is no section 8 or 9 as promised in the contents page. Pete BTW what's happening about the first ballot - recall my email that the Ballot must be formally launched and numbered with a specific start and end date? Pete Rivett (mailto:pete.rivett@adaptive.com) CTO, Adaptive Inc. Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448 http://www.adaptive.com -------------------------------------------------------------------------------- From: Juergen Boldt [mailto:juergen@omg.org] Sent: Friday, February 11, 2005 8:44 PM To: issues@omg.org; ras-ftf@omg.org Subject: issue 8212 -- RAS FTF issue To: issues@omg.org Subject: RAS FTF: add support for Activity Parameters X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Grant J Larsen Date: Wed, 2 Feb 2005 06:24:09 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V70_M4_01112005 Beta 3|January 11, 2005) at 02/02/2005 06:24:16, Serialize complete at 02/02/2005 06:24:16 Default Profile Change Request: Activity Parameters Table of Contents 1. Introduction 4 2. References 4 3. Design Requirements 4 4. Design Constraints 4 5. Issues 4 5.1 Specifying parameters for an Activity is very difficult 4 5.1.1 Description 4 6. Considered Approaches 4 6.1 Preferred Approach - Add class ActivityParameter to the metamodel 4 6.1.1 Description 4 6.1.2 Pros 5 6.1.3 Cons 5 6.2 Alternate Approach 1 . Include the Parameters in an Activity attribute 5 6.2.1 Description 5 6.2.2 Pros 5 6.2.3 Cons 5 6.3 Alternate Approach 2 . Expand the class VariabilityPointBinding 5 6.3.1 Description 5 6.3.2 Pros 6 6.3.3 Cons 6 7. Design Artifacts 6 7.1 Figure 1 6 7.2 Figure 2 7 7.3 Figure 3 7 7.4 Example 1 8 8. Future Considerations 9 9. Draft Reviews Threads 9 1. Introduction This document describes the issues the RAS Aurora Program development team has experienced while trying to write tooling to effectively exploit the activity element in the RAS default profile. It also contains a proposal to help alleviate these issues. 2. References · Reusable Asset Specification(04-06-06.pdf) 3. Design Requirements · Provide a mechanism to easily associate parameters with an activity · Concretely define the relationship between activities and their parameters at the metamodel level 4. Design Constraints · Require only minor changes to the current default profile metamodel 5. Issues 5.1 Specifying parameters for an Activity is very difficult 5.1.1 Description It.s quite common to include asset or artifact activities in a RAS manifest that are interrogated by clients during some part of the asset.s lifecycle. Often the activity requires additional pieces of information that.s used by the client to help execute the activity in one manner or another during processing. For example, IBM.s Eclipse based RAS implementation provides an activity to build a deployable project that.s processed during asset packaging. The RAS manifest author has the option to build that project with or without source and package the binaries in different formats. In today.s default profile metamodel, there doesn.t appear to be a clear, simple way to specify the options. Ideally the metamodel should provide a way to express the parameters for an activity in an unambiguous way. Below are a few approaches we considered including a preferred approach to resolving this issue. We are open to other suggestions as well. 6. Considered Approaches 6.1 Preferred Approach - Add class ActivityParameter to the metamodel 6.1.1 Description Our preferred approach is to add a new class called ActivityParameter to the metamodel for the default profile that extends the class Descriptor. This new class would contain one attribute named defaultValue that would provide the ability to specify for the parameter exactly what the name implies.a default value. The name and value attributes inherited from the Descriptor class would provide the mechanism for defining the parameters and their values. See Figure 1 and Example 1. 6.1.2 Pros · Concretely defines the relationship between activities and their parameters in a clear, straight forward manner. · Client will not have to interrogate the attributes of other elements to try to determine if they are the parameters for activity. · The parameters will not have to be included in one of the attributes of the activity. 6.1.3 Cons · New class and relationships must be added to the metamodel 6.2 Alternate Approach 1 . Include the Parameters in an Activity attribute 6.2.1 Description Include the parameters as part of one of the existing activity attributes. Use special characters to denote the parameters and their values so that they can be specified and accessed by clients. 6.2.2 Pros · Requires no changes to the current default profile metamodel 6.2.3 Cons · No clear relationship between the activity and the parameters · Adds confusing extraneous information to activity attributes that doesn.t apply to the attribute. · Clients must know which attribute contains the parameters and how to specify/access them 6.3 Alternate Approach 2 . Expand the class VariabilityPointBinding 6.3.1 Description Add a new attribute to the class VariabilityPointBinding. This will provide a way to associate the parameters with the activity using an existing metamodel relationship. See Figure 2 or Figure 3.. 6.3.2 Pros · Requires no new classes to be added to the metamodel · Provides a mechanism to associate parameters to an activity through an existing relationship. 6.3.3 Cons · No clear relationship between the activity and the parameters. The binding rules will have to be interrogated to find a particular binding rule and then process it. · Using the VariabilityPointBinding class for this purpose doesn.t really seem like what the intended purpose is according to the RAS spec. It.s tied to a VariabilityPoint which doesn.t necessarily apply. · A new attribute must be added to the VariabilityPointBinding class. 7. Design Artifacts 7.1 Figure 1 7.2 Figure 2 7.3 Figure 3 7.4 Example 1 An example expansion of the XML in a RAS manifest for an activity with parameters for the preferred solution: Thanks, Grant ----------------------------------------------------------- Grant Larsen STSM IBM Rational software Voice: (303) 932-7368 Mobile: (303) 601-1257 Fax: (303) 932-6963 Notes: Grant J Larsen/Denver/IBM E-mail: gjlarsen@us.ibm.com ================================= Jürgen Boldt Director, Member Services Object Management Group 250 First Avenue, Suite 100 Needham, MA 02494 Tel. +1 781 444 0404 ext. 132 Fax: +1 781 444 0320 email: juergen@omg.org www www.omg.org RAS FTF add support for Activi2.gif