Re: [Dev] [Architecture] Maintaining IS-Archetypes
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
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]
