Hi Darshana, Currently we don't have an archetype for that.
Regards, Kumaaran On Tue, 24 Dec 2019, 20:17 Darshana Gunawardana, <[email protected]> wrote: > Do we have an archetype for PostAuthenticationHandlers? > > On Wed, Oct 9, 2019 at 3:37 PM Inthirakumaaran Tharmakulasingham < > [email protected]> wrote: > >> Hi all, >> >> We had an offline discussion with @Darshana Gunawardana >> <[email protected]> @Omindu Rathnaweera <[email protected]> @Jayanga >> Kaushalya <[email protected]> @Yasara Yasawardhana <[email protected]> @Janak >> Amarasena <[email protected]> @Pulasthi Mahawithana <[email protected]>. >> There we decided the following >> >> - Regarding Maintenance: >> - Have a separate repo for IS-archetypes. We planned to go with >> the name *archetypes-is* for the repo >> - Go with four-digit release >> - major -- product release >> - minor -- addition of a new archetype >> - patch -- improve >> - 4th digit -- track archetype life >> - For each product version, a branch will be created and >> compatible archetypes for that versions will be maintained there >> - Archetype Structure: >> - The structure in the above mail is acceptable. >> - Within comments, have the sample codes for the methods. >> - Have the data holder pattern. But according to the situation, we >> can drop this. >> - The component name will be taken as input and appended as a >> prefix. >> - eg for user operation event listener -- >> {listener-name}UserOperationEventListener.java >> >> Please share your thoughts on this >> >> Thanks and Regards >> kumaaran >> >> On Wed, Sep 11, 2019 at 9:20 PM Inthirakumaaran Tharmakulasingham < >> [email protected]> wrote: >> >>> Hi all, >>> >>> We have updated the dependency of user-event-listener-archetype[1] and >>> now it can work on IS 5.8.0. While deciding on where to put these >>> archetypes, let's try to finalize the format of archetypes by analyzing the >>> user-event-listener-archetype. >>> >>> Following is the structure of this archetype. >>> >>> carbon-user-operation-eventListener-archetype >>>> └── src >>>> ├── main >>>> │ └── resources >>>> │ ├── META-INF >>>> │ │ └── maven >>>> │ │ └── archetype-metadata.xml >>>> │ └── archetype-resources >>>> │ ├── pom.xml >>>> │ └── src >>>> │ └── main >>>> │ └── java >>>> │ ├── >>>> __listener-name-prefix__UserOperationEventListener.java >>>> │ └── internal >>>> │ └── >>>> __listener-name-prefix__UserOperationEventListenerServiceComponent.java >>>> └── test >>>> └── resources >>>> └── projects >>>> └── basic >>>> ├── archetype.properties >>>> └── goal.txt >>> >>> >>> We have to think of the components we can add to this archetypes. Eg we >>> can add data-holder class which could help the user to customize these >>> archetypes. >>> >>> Then we have to consider the naming as well, eg what group id should be >>> given for which archetype or how the classes in the archetype should be >>> named whether to add a suffix or have a fixed name >>> >>> Please share your thoughts on this >>> >>> [1]https://github.com/wso2-extensions/archetypes/pull/26 >>> >>> On Wed, Aug 7, 2019 at 7:25 PM Kanapriya Kuleswararajan < >>> [email protected]> wrote: >>> >>>> Hi Shankar, >>>> >>>> On Wed, Aug 7, 2019 at 4:56 PM Selvaratnam Uthaiyashankar < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Aug 7, 2019 at 2:23 PM Tharindu Bandara <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Find the best approach to maintain the archetypes (in a single repo >>>>>>> or inside the feature repo). >>>>>> >>>>>> >>>>> I didn't understand what do we meant by feature repo here. Still it is >>>>> going to be single repo right? >>>>> >>>> >>>> The feature repo means, we thought to maintain the archetype in the >>>> same repository where the feature is in. In that way, if we upgrade the >>>> product or any feature component with the latest dependencies, we can >>>> update the archetypes and can maintain the releases for archetypes as well >>>> (we may need to maintain the old archetype version as there can be users >>>> who still use the old product versions with lower dependency versions). >>>> >>>>> >>>>> When we created the extensions, we make a conscious decision to have a >>>>> separate repo for each extension. Each extension has its own release >>>>> cycle. >>>>> archetypes are also considered extensions. The version of the archetypes >>>>> doesn't need to have a matching product version. >>>>> >>>>> Any difficulty we are facing by keeping them in separate repositories? >>>>> >>>> >>>> I don't think any other difficulties in having each archetype in a >>>> separate repo except the maintenance. Because, we have a couple of >>>> archetypes in repo [1], but it's not in a stable state to use in latest >>>> product versions as we (Developer) forget to update the archetype along >>>> with the dependency upgrades. IMO, this may lead to a separate effort to >>>> maintain each archetype if we have it in the separate repos? >>>> >>>> WDYT? >>>> >>>> [1] https://github.com/wso2-extensions/archetypes >>>> <https://www.google.com/url?q=https://github.com/wso2-extensions/archetypes&sa=D&source=hangouts&ust=1564833739149000&usg=AFQjCNFopSwDYqHH3VV8GZORIXe7CmhGTQ> >>>> >>>> Thanks >>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Shall we finalize on the approach to maintain the archetypes? This >>>>>> would be helpful to proceed with the effort [1]. >>>>>> >>>>>> [1] "[IS] Maven Archetype for Custom Event Handlers" >>>>>> >>>>>> Thanks, >>>>>> Tharindu. >>>>>> >>>>>> On Mon, Aug 5, 2019 at 10:40 AM Kanapriya Kuleswararajan < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> In the repo [1] we have archetypes for IS extensions and seems they >>>>>>> are outdated as it still uses the old dependency of carbon-identity. >>>>>>> This >>>>>>> need to be improved/refactor in order to make this to a stable with the >>>>>>> latest product version. >>>>>>> >>>>>>> BTW, we couldn't see any specific reason to have all archetypes here >>>>>>> under the repo [1]. Hence we thought to move all the IS-related >>>>>>> archetypes >>>>>>> >>>>>>> - To a separate repo? But here we have to decide, how we are >>>>>>> going to maintain the releases (major or minor) if we have all the >>>>>>> archetypes in the same repo? In this way, there can be chances that >>>>>>> some >>>>>>> archetypes get released unnecessary (ie, without any changes). >>>>>>> - Or else we can keep the archetypes inside the feature repo >>>>>>> itself? >>>>>>> >>>>>>> Appreciate your valuable suggestions on the above? >>>>>>> >>>>>>> Further, In this effort, we (myself and @Inthi) are planning the >>>>>>> following as the initial step: >>>>>>> >>>>>>> - Refactor the existing archetypes and Making that to work with >>>>>>> IS 5.8.0 for now. >>>>>>> - Find the best approach to maintain the archetypes (in a single >>>>>>> repo or inside the feature repo). >>>>>>> - Add more archetypes as part of this effort. We could see a >>>>>>> couple of archetypes already developed, but that need to be reviewed >>>>>>> and we >>>>>>> have to add those to the specific repo. @Inthirakumaaran >>>>>>> Tharmakulasingham <[email protected]> will share the >>>>>>> details on this. >>>>>>> - Generate guidance for creating an archetype. >>>>>>> >>>>>>> Please share your thoughts and suggestions about this effort, that >>>>>>> will be very helpful to us to continue on this :) >>>>>>> >>>>>>> [1] https://github.com/wso2-extensions/archetypes >>>>>>> <https://www.google.com/url?q=https://github.com/wso2-extensions/archetypes&sa=D&source=hangouts&ust=1564833739149000&usg=AFQjCNFopSwDYqHH3VV8GZORIXe7CmhGTQ> >>>>>>> >>>>>>> Thanks >>>>>>> Kanapriya Kuleswararajan >>>>>>> Senior Software Engineer >>>>>>> Mobile : - 0774894438 >>>>>>> Mail: - [email protected] >>>>>>> LinkedIn : - https://www.linkedin.com/in/kanapriya-kules-94712685/ >>>>>>> WSO2, Inc. >>>>>>> lean. enterprise. middleware >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> *Tharindu Bandara* >>>>>> Software Engineer | WSO2 >>>>>> >>>>>> Email : [email protected] >>>>>> Mobile : +94 714221776 >>>>>> web : http://wso2.com >>>>>> <https://www.google.com/url?q=http://wso2.com&sa=D&ust=1517653383990000&usg=AFQjCNFggB4bSJTKmdqKcBV0VY9xx1ABKg> >>>>>> >>>>>> https://wso2.com/signature >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>> >>>>> >>>>> -- >>>>> *S.Uthaiyashankar* | SVP Engineering | WSO2 Inc. <http://wso2.com/> >>>>> (M)+94 774895474 | (E) [email protected] >>>>> <https://wso2.com/signature> >>>>> >>>> >>> >>> -- >>> *Inthirakumaaran* >>> Software Engineer | WSO2 >>> >>> E-mail:[email protected] >>> Mobile:+94775558050 >>> Web:https://wso2.com >>> >>> <http://wso2.com/signature> >>> >>> >>> >> >> -- >> *Inthirakumaaran* >> Software Engineer | WSO2 >> >> E-mail:[email protected] >> Mobile:+94775558050 >> Web:https://wso2.com >> >> <http://wso2.com/signature> >> >> >> > > -- > Regards, > > > *Darshana Gunawardana*Technical Lead > WSO2 Inc.; http://wso2.com > > *E-mail: [email protected] <[email protected]>* > *Mobile: +94718566859*Lean . Enterprise . Middleware >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
