Re: [Dev] [Architecture] Maintaining IS-Archetypes

[Inthirakumaaran Tharmakulasingham]

Hi Darshana,

Currently we don't have an archetype for that.

Regards,
Kumaaran


On Tue, 24 Dec 2019, 20:17 Darshana Gunawardana,  wrote:

> Do we have an archetype for PostAuthenticationHandlers?
>
> On Wed, Oct 9, 2019 at 3:37 PM Inthirakumaaran Tharmakulasingham <
> inthirakumaa...@wso2.com> wrote:
>
>> Hi all,
>>
>> We had an offline discussion with  @Darshana Gunawardana
>>  @Omindu Rathnaweera  @Jayanga
>> Kaushalya  @Yasara Yasawardhana  @Janak
>> Amarasena  @Pulasthi Mahawithana .
>> 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 <
>> inthirakumaa...@wso2.com> 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 <
>>> kanapr...@wso2.com> wrote:
>>>
 Hi Shankar,

 On Wed, Aug 7, 2019 at 4:56 PM Selvaratnam Uthaiyashankar <
 shan...@wso2.com> wrote:

>
>
> On Wed, Aug 7, 2019 at 2:23 PM Tharindu Bandara 
> 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 

Re: [Dev] [Architecture] Maintaining IS-Archetypes

[Darshana Gunawardana]

Do we have an archetype for PostAuthenticationHandlers?

On Wed, Oct 9, 2019 at 3:37 PM Inthirakumaaran Tharmakulasingham <
inthirakumaa...@wso2.com> wrote:

> Hi all,
>
> We had an offline discussion with  @Darshana Gunawardana
>  @Omindu Rathnaweera  @Jayanga
> Kaushalya  @Yasara Yasawardhana  @Janak
> Amarasena  @Pulasthi Mahawithana .
> 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 <
> inthirakumaa...@wso2.com> 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 <
>> kanapr...@wso2.com> wrote:
>>
>>> Hi Shankar,
>>>
>>> On Wed, Aug 7, 2019 at 4:56 PM Selvaratnam Uthaiyashankar <
>>> shan...@wso2.com> wrote:
>>>


 On Wed, Aug 7, 2019 at 2:23 PM Tharindu Bandara 
 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] 

Re: [Dev] [Architecture] Maintaining IS-Archetypes

[Inthirakumaaran Tharmakulasingham]

Hi all,

We had an offline discussion with  @Darshana Gunawardana 
 @Omindu Rathnaweera  @Jayanga Kaushalya
 @Yasara Yasawardhana  @Janak Amarasena
 @Pulasthi Mahawithana . 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 <
inthirakumaa...@wso2.com> 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 <
> kanapr...@wso2.com> wrote:
>
>> Hi Shankar,
>>
>> On Wed, Aug 7, 2019 at 4:56 PM Selvaratnam Uthaiyashankar <
>> shan...@wso2.com> wrote:
>>
>>>
>>>
>>> On Wed, Aug 7, 2019 at 2:23 PM Tharindu Bandara 
>>> 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
>> 
>>
>> Thanks
>>
>>>
>>>
>>>

 Shall we finalize on the approach to maintain the archetypes? This
 would be helpful to proceed with 

Re: [Dev] [Architecture] Maintaining IS-Archetypes

[Inthirakumaaran Tharmakulasingham]

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 
wrote:

> Hi Shankar,
>
> On Wed, Aug 7, 2019 at 4:56 PM Selvaratnam Uthaiyashankar <
> shan...@wso2.com> wrote:
>
>>
>>
>> On Wed, Aug 7, 2019 at 2:23 PM Tharindu Bandara 
>> 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
> 
>
> 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 <
>>> kanapr...@wso2.com> 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 

Re: [Dev] [Architecture] Maintaining IS-Archetypes

[Selvaratnam Uthaiyashankar]

On Wed, Aug 7, 2019 at 2:23 PM Tharindu Bandara  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?

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?



>
> 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 <
> kanapr...@wso2.com> 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
>> 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
>> 
>>
>> Thanks
>> Kanapriya Kuleswararajan
>> Senior Software Engineer
>> Mobile : - 0774894438
>> Mail: - kanapr...@wso2.com
>> LinkedIn : - https://www.linkedin.com/in/kanapriya-kules-94712685/
>> WSO2, Inc.
>> lean. enterprise. middleware
>>
>>
>
> --
> *Tharindu Bandara*
> Software Engineer | WSO2
>
> Email : tharin...@wso2.com
> Mobile : +94 714221776
> web : http://wso2.com
> 
>
> https://wso2.com/signature
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*S.Uthaiyashankar* | SVP Engineering | WSO2 Inc. 
(M)+94 774895474 | (E) shan...@wso2.com

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev