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>
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev
