Hi Sameera, On Wed, Dec 17, 2014 at 3:22 PM, Geeth Munasinghe <[email protected]> wrote: > > Hi > > > On Wed, Dec 17, 2014 at 2:23 PM, Isuruwan Herath <[email protected]> > wrote: >> >> [moved to architecture] >> >> Hi Sameera, >> >> Please see the comments inline. >> >> On Mon, Dec 15, 2014 at 11:00 PM, Sameera Kannangara <[email protected]> >> wrote: >>> >>> Hi all, >>> >>> $Subject refers to the functionality required to fulfill the following >>> scenario in G-Reg 5.0.0. [1] >>> >>> Scenario: >>> >>> >>> >> IIRC, this was discussed sometime ago and the idea was to have a "copy" button next to the "save" button of a governance artifact(any rxt). The idea back then was to extent the RXT configuration language so that a user can define actions(buttons in UI) and add his/her own custom implementation of that action. As an example, the default 2 actions for a governance artifact is "save" and "clear". With the above mentioned change, a user can define a new action "copy" in the RXT configuration and then add his implementation of that(like we have done for custom executors in lifecycles)
> >>> User should be able to copy existing resource to new version. Lets say a >>> user has a service in GREG which is attached with a life cycle, and the >>> service is in production life cycle state. User develops a new version of >>> the same service, and he wants to add those meta data to the GREG. Rather >>> than adding them from the beginning, He should be able to copy the existing >>> resource and it's associations to a new version, except life cycle state, >>> life cycle state should be the first state of the associated life cycle. >>> >>> >>> >>> >> IIRC, we only have versions from "Testing" state onward and the "Development" state only has one version which is the "trunk". So the lifecycle state should not be the first state of the lifecyle. Hence the copy functionality should prompt for the new version that needs to be created and we should place it in a different state. Please define the usecases clearly so that we can understand the exact usages of this functionality. > >> In current service LC functionality, the copy executor will anyway create >> a new artifact with next version. Hence, if this clone functionality is >> required to access an copy of certain life cycle state it will exist >> anyway. Otherwise, if this copy function is used to refer a new service >> with similar metadata, then, is correct to have the same associations and >> dependencies (with same versions) in the cloned artifact? >> > Is this the copy executor or the service version executor? AFAIK, the copy executor does not do any version change and only the service version executor(which does a copy of an artifact to a new location and changes its version too) does that functionality. Thanks, Janaka > >> > > IMO there should not be a copy executor, because executors run in the life > cycle events. I don't think there is a use case to change the version of > the resource within the life cycle. If resource changes the version, then > it should be a new life cycle. In the current copy executor it changes the > version in the within the life cycle (Ex: Version of the service can be > changed to new version using executor when life cycle state of the resource > changes from dev to test). IMO having this copy functionality in the life > cycle is wrong. > >> >>> Rationale for this requirement is that it reduces the time and effort >>> required to create a new version of an existing service, by removing >>> the time and effort needed to fill all the detail necessary to create the >>> service. >>> >>> This functionality is not supported by the G-Reg's existing copy >>> functionality as it operates on generic resource level. >>> >>> As this requirement is related to governance artifacts (more >>> specifically regarding services) I'm checking how this can be implemented, >>> how user can invoke this functionality and to which package the new >>> functionality should be added. >>> >>> Regarding the scope of this functionality, >>> >>> What are the Extension types which should support this functionality >>> other than "Service"? >>> >> > I think this must be a generic functionality and should be associated with > all extension types. This copy functionality should copy the resource and > all it's associated resources to new version. > > >> Is this functionality a generic one associated with any extension type >>> that has a version field? >>> >> IMO, we can allow this functionality for any artifact types with a >> version, if we make this available for "Service". >> > >>> >>> Thank you, >>> SameeraK. >>> >>> [1] https://redmine.wso2.com/issues/2751 >>> >>> -- >>> *Sameera Kannangara* >>> Software Engineer >>> Platform TG; WSO2 Inc. http://wso2.com >>> Contact: >>> phone: +94719541577 >>> Lean . Enterprise . Middleware >>> >> >> >> -- >> Isuruwan Herath >> Technical Lead >> >> Contact: +94 776 273 296 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Janaka Ranabahu* Senior Software Engineer; WSO2 Inc.; http://wso2.com *E-mail: [email protected] <http://wso2.com>**M: **+94 718370861* Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
