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: >> >> 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. >> > > 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? > 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
