[Architecture] Same feature with different versions in different runtimes
Hi all, When I was creating a custom product using carbon-kernel version 5.2.0-alpha[1] the following issue aroused. In a scenario where a product is build with 2 runtimes called runtimeA and runtimeB. runtimeA contains the below feature among it's other features pax.exam.feature v5.2.0.0 sample-bundle2 v5.2.0.0 log-bundle v1.5.0 while runtmeB contains the below feature among it's other features sample.feature v5.2.0.1 sample-bundle1 v5.2.0.0 monitor-bundle v1.5.0 pax.exam.feature v5.2.0.1 As shown above since there is a dependency to the `pax.exam.feature,v5.2.0.1` from the `sample.feature,v5.2.0.1`, to have both versions of `pax.exam.feature` to be installed into the separate runtimes of the product, it is required to define dependency information of each `pax.exam.feature` versions (v5.2.0.0 and v5.2.0.1) under the tag in the pom.xml file. But during the build process, maven will only pick one version of that dependency and omit the other versions to avoid any conflicts using the *"nearest in the dependency tree"* strategy (already asked in stackoverflow [1]). This will results in a build failure as if the build process resolves dependency of `pax.exam.feature` v5.2.0.0`, the version v5.2.0.1 will not be available during build and vice versa. Is this a legitimate case that we should address? IMO it will be a best practise to use the newest versions of the features available when creating runtimes than using the older versions which in turn will resolve this issue. Your comments are highly appreciated. [1] https://github.com/wso2/carbon-kernel/tree/v5.2.0-alpha [2] https://stackoverflow.com/questions/24962607/multiple-versions-of-the-same-dependency-in-maven Thanks -- *Regards,* *Kasun Siyambalapitiya* *Software Engineer* WSO2 Inc. - http://wso2.com/ lean . enterprise . middleware Tel : 0715523466 E mail : kasu...@wso2.com Blog: https://medium.com/@kasunsiyambalapitiya <https://wso2.com/signature> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Same feature with different versions in different runtimes
Hi Niranjan, The build fails before successful generation of the p2-repo by giving the following error [ERROR] Failed to execute goal org.wso2.carbon.maven:carbon-f > eature-plugin:3.1.1:generate-repo (p2-repo-generation) on project > wso2carbon-kernel: Feature org.wso2.carbon.pax.exam.feature_5.2.0.1 not > found -> [Help 1] Since in the new C5 model the p2-repo containing all the features required for all the runtimes of the product, is generated at a single specified directory(by default the target directory) multiple version of the same feature cannot be generated as maven build will pick only one version of the dependency due to the use of "nearest in the dependency tree" strategy as shown in above mail. As a result although we can have multiple versions at the p2-repo per feature due to the above nature of maven, runtimes with different feature versions cannot be created in C5. This problem was not there in the previous C4 model as the profiles(runtime in C5 wording) were generated at separate locations and their respective p2-repos were created at their own locations(where the profile is created) [1] IMO this issue can be avoided by always using the newest feature version available when creating runtimes in C5 products. WDYT? [1] https://github.com/wso2/product-ei/tree/v6.2.0-m2/p2-profile On Wed, Aug 16, 2017 at 3:51 PM, Niranjan Karunanandham wrote: > Hi Kasun, > > On Wed, Aug 16, 2017 at 3:30 PM, Kasun Siyambalapitiya > wrote: > >> Hi all, >> >> When I was creating a custom product using carbon-kernel version >> 5.2.0-alpha[1] the following issue aroused. >> In a scenario where a product is build with 2 runtimes called runtimeA >> and runtimeB. >> >> runtimeA contains the below feature among it's other features >> >> pax.exam.feature v5.2.0.0 >> sample-bundle2 v5.2.0.0 >> log-bundle v1.5.0 >> >> >> while runtmeB contains the below feature among it's other features >> >> sample.feature v5.2.0.1 >> sample-bundle1 v5.2.0.0 >> monitor-bundle v1.5.0 >> pax.exam.feature v5.2.0.1 >> >> >> >> As shown above since there is a dependency to the >> `pax.exam.feature,v5.2.0.1` from the `sample.feature,v5.2.0.1`, to have >> both versions of `pax.exam.feature` to be installed into the separate >> runtimes of the product, it is required to define dependency information of >> each `pax.exam.feature` versions (v5.2.0.0 and v5.2.0.1) under the >> tag in the pom.xml file. >> >> But during the build process, maven will only pick one version of that >> dependency and omit the other versions to avoid any conflicts using the >> *"nearest >> in the dependency tree"* strategy (already asked in stackoverflow [1]). >> This will results in a build failure as if the build process resolves >> dependency of `pax.exam.feature` v5.2.0.0`, the version v5.2.0.1 will not >> be available during build and vice versa. >> >> Is this a legitimate case that we should address? >> IMO it will be a best practise to use the newest versions of the features >> available when creating runtimes than using the older versions which in >> turn will resolve this issue. >> >> Your comments are highly appreciated. >> > > As per the offline discussion, this issue is for generating the p2-repo. > You will need to check whether both versions of the feature are there in > the p2-repo that is being generated. If it does not exist then we would > need to fix it there. > > >> >> [1] https://github.com/wso2/carbon-kernel/tree/v5.2.0-alpha >> [2] https://stackoverflow.com/questions/24962607/multiple-ve >> rsions-of-the-same-dependency-in-maven >> >> Thanks >> >> -- >> *Regards,* >> >> *Kasun Siyambalapitiya* >> *Software Engineer* >> WSO2 Inc. - http://wso2.com/ >> lean . enterprise . middleware >> Tel : 0715523466 >> E mail : kasu...@wso2.com >> Blog: https://medium.com/@kasunsiyambalapitiya >> <https://wso2.com/signature> >> > > Regards, > Nira > > -- > > > *Niranjan Karunanandham* > Associate Technical Lead - WSO2 Inc. > WSO2 Inc.: http://www.wso2.com > > -- *Regards,* *Kasun Siyambalapitiya* *Software Engineer* WSO2 Inc. - http://wso2.com/ lean . enterprise . middleware Tel : 0715523466 E mail : kasu...@wso2.com Blog: https://medium.com/@kasunsiyambalapitiya <https://wso2.com/signature> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Same feature with different versions in different runtimes
Hi Niranjan,
When generating the p2-repository using `carbon-maven-plugin version 3.x`
this issue arises due to the fact that it resolves dependencies for each
given feature with the dependencies we defined in the pom itself (note that
the effective pom is used for the resolving). Since maven picks only one
version of a given dependency due the use of `nearest in the dependency
tree` strategy, a p2-repo with multiple versions of the same feature can
not be created by using the current `carbon-maven-plugin version 3.1.3`.
But in the case of `carbon-maven-plugin version 1.5.x` this is possible as
the dependencies of each feature is defined in a string form as below
org.apache.axis2.transport:org.apache.axis2.transport.jms.feature:
> ${axis2-transports.wso2.version.1.1.0.wso2v17}
and the version `${axis2-transports.wso2.version.1.1.0.wso2v17}` is
replaced with the value of the relevant property we defined in the pom.xml.
Since there are no restrictions like above in defining properties in
pom.xml this works.
Thanks.
On Thu, Aug 17, 2017 at 10:39 AM, Niranjan Karunanandham
wrote:
> Hi Kasun,
>
> On Thu, Aug 17, 2017 at 10:04 AM, Kasun Siyambalapitiya
> wrote:
>
>> Hi Niranjan,
>>
>> The build fails before successful generation of the p2-repo by giving the
>> following error
>>
>> [ERROR] Failed to execute goal org.wso2.carbon.maven:carbon-f
>>> eature-plugin:3.1.1:generate-repo (p2-repo-generation) on project
>>> wso2carbon-kernel: Feature org.wso2.carbon.pax.exam.feature_5.2.0.1 not
>>> found -> [Help 1]
>>
>>
>>
>> Since in the new C5 model the p2-repo containing all the features
>> required for all the runtimes of the product, is generated at a single
>> specified directory(by default the target directory) multiple version of
>> the same feature cannot be generated as maven build will pick only one
>> version of the dependency due to the use of "nearest in the dependency
>> tree" strategy as shown in above mail. As a result although we can have
>> multiple versions at the p2-repo per feature due to the above nature of
>> maven, runtimes with different feature versions cannot be created in C5.
>> This problem was not there in the previous C4 model as the profiles(runtime
>> in C5 wording) were generated at separate locations and their respective
>> p2-repos were created at their own locations(where the profile is created)
>> [1]
>>
>> IMO this issue can be avoided by always using the newest feature version
>> available when creating runtimes in C5 products. WDYT?
>>
> The profiles that were used in C4 were used to install features, but only
> one p2-repo is created. In the case of EI, they have created separate
> modules (folders for each profile) and then they are handling it. In the
> case of AS 5.3.0, we had a single pom to create a distribution with
> multiple profiles. Wilkes p2-repo is generated using the
> carbon-feature-repository [1], here in the pom, the p2-repo is generated
> with different versions of the same feature. Similarly for C5, it should
> follow the same. We need to look into the carbon-maven-plugins version
> 1.5.x [2] and 3.x [3].
>
>
>>
>> [1] https://github.com/wso2/product-ei/tree/v6.2.0-m2/p2-profile
>>
>> On Wed, Aug 16, 2017 at 3:51 PM, Niranjan Karunanandham <
>> niran...@wso2.com> wrote:
>>
>>> Hi Kasun,
>>>
>>> On Wed, Aug 16, 2017 at 3:30 PM, Kasun Siyambalapitiya >> > wrote:
>>>
>>>> Hi all,
>>>>
>>>> When I was creating a custom product using carbon-kernel version
>>>> 5.2.0-alpha[1] the following issue aroused.
>>>> In a scenario where a product is build with 2 runtimes called runtimeA
>>>> and runtimeB.
>>>>
>>>> runtimeA contains the below feature among it's other features
>>>>
>>>> pax.exam.feature v5.2.0.0
>>>> sample-bundle2 v5.2.0.0
>>>> log-bundle v1.5.0
>>>>
>>>>
>>>> while runtmeB contains the below feature among it's other features
>>>>
>>>> sample.feature v5.2.0.1
>>>> sample-bundle1 v5.2.0.0
>>>> monitor-bundle v1.5.0
>>>> pax.exam.feature v5.2.0.1
>>>>
>>>>
>>>>
>>>> As shown above since there is a dependency to the
>>>> `pax.exam.feature,v5.2.0.1` from the `sample.feature,v5.2.0.1`, to have
>>>> both versions of `pax.exam.feature` to be installed into the separate
>>>> runtimes of the product, it is required to define dependency information of
>>>> each `pax.exam.feature` versions (
Re: [Architecture] Same feature with different versions in different runtimes
Hi Dilan and all,
Pardon me for the late reply. Yes, I agree with your point due to the fact
that different feature versions including slight or major differences in
their implementation has been released as compatible features for WSO2
Carbon 4.4.x (Wilkes) [1] products,
For example,
1.
org.wso2.carbon.identity.application.authentication.framework.server_4.5.6.jar
/ org.wso2.carbon.identity.application.authentication.
framework.server_5.7.5.jar
2. org.wso2.carbon.directory.service.mgr.server_4.5.6.jar
/ org.wso2.carbon.directory.service.mgr.server_5.7.5.jar
3. rg.wso2.carbon.forum.server_2.0.0.jar / org.wso2.carbon.forum.
server_6.1.66.jar
4. org.wso2.carbon.identity.core.server_4.5.5.jar
/ org.wso2.carbon.identity.core.server_5.7.5.jar
5. org.wso2.carbon.identity.core.ui_4.5.5.jar
/ org.wso2.carbon.identity.core.ui_5.7.5.jar
Since all the jars mentioned above have major implementational changes
which are not backward compatible (as indicated by the major version no
change) there is a huge possibility of having a functional inconsistency in
the system if multiple versions of the same feature are used in different
runtimes. For example the format of data inserted and queried out from db
from previous version may differ from the how it is done in the latest
version leaving to inconsistencies in DB. IMO I think either we should
restrict to one version of a certain feature or allow up to it's next major
version. WDYT?
[1] http://product-dist.wso2.com/p2/carbon/releases/wilkes/features/
Thanks.
On Fri, Aug 18, 2017 at 8:39 AM, Dilan Udara Ariyaratne
wrote:
> Hi Kasun and All,
>
> Let me raise a different, but fundamental concern to this issue. Please
> correct me if I am wrong.
>
> It's perfectly valid to have the same feature on different run-times (or
> profiles) of a product, but if that same feature appears in "different
> versions",
> meaning, with slight or major differences of their implementations, at
> different run-times of the product, wouldn't that open up any possibilities
> of functional inconsistencies or even failures to the overall system ?
>
> Thanks,
> Dilan.
>
> *Dilan U. Ariyaratne*
> Senior Software Engineer
> WSO2 Inc. <http://wso2.com/>
> Mobile: +94766405580 <%2B94766405580>
> lean . enterprise . middleware
>
>
> On Thu, Aug 17, 2017 at 8:19 PM, Kasun Siyambalapitiya
> wrote:
>
>> Hi Niranjan,
>>
>> When generating the p2-repository using `carbon-maven-plugin version 3.x`
>> this issue arises due to the fact that it resolves dependencies for each
>> given feature with the dependencies we defined in the pom itself (note that
>> the effective pom is used for the resolving). Since maven picks only one
>> version of a given dependency due the use of `nearest in the dependency
>> tree` strategy, a p2-repo with multiple versions of the same feature can
>> not be created by using the current `carbon-maven-plugin version 3.1.3`.
>>
>> But in the case of `carbon-maven-plugin version 1.5.x` this is possible
>> as the dependencies of each feature is defined in a string form as below
>>
>> org.apache.axis2.transport:org.apache.axis2.transport.jms.feature:
>>> ${axis2-transports.wso2.version.1.1.0.wso2v17}
>>
>>
>> and the version `${axis2-transports.wso2.version.1.1.0.wso2v17}` is
>> replaced with the value of the relevant property we defined in the pom.xml.
>> Since there are no restrictions like above in defining properties in
>> pom.xml this works.
>>
>> Thanks.
>>
>> On Thu, Aug 17, 2017 at 10:39 AM, Niranjan Karunanandham <
>> niran...@wso2.com> wrote:
>>
>>> Hi Kasun,
>>>
>>> On Thu, Aug 17, 2017 at 10:04 AM, Kasun Siyambalapitiya <
>>> kasu...@wso2.com> wrote:
>>>
>>>> Hi Niranjan,
>>>>
>>>> The build fails before successful generation of the p2-repo by giving
>>>> the following error
>>>>
>>>> [ERROR] Failed to execute goal org.wso2.carbon.maven:carbon-f
>>>>> eature-plugin:3.1.1:generate-repo (p2-repo-generation) on project
>>>>> wso2carbon-kernel: Feature org.wso2.carbon.pax.exam.feature_5.2.0.1
>>>>> not found -> [Help 1]
>>>>
>>>>
>>>>
>>>> Since in the new C5 model the p2-repo containing all the features
>>>> required for all the runtimes of the product, is generated at a single
>>>> specified directory(by default the target directory) multiple version of
>>>> the same feature cannot be generated as maven build will pick only one
>>>> version of the dependency due to the use of "nearest in
Re: [Architecture] Same feature with different versions in different runtimes
Hi Niranjan,
Thank you for pointing it out, created an issue regarding the above.
Thanks.
On Fri, Sep 8, 2017 at 8:35 AM, Niranjan Karunanandham
wrote:
> Hi Kasun,
>
> Have we created a git issue for the carbon-maven-plugins with regard to
> not able to download two versions of the same feature to create a p2-repo?
>
> Regards,
> Nira
>
> On 8 Sep 2017 5:13 a.m., "Kasun Siyambalapitiya" wrote:
>
>> Hi Dilan and all,
>>
>> Pardon me for the late reply. Yes, I agree with your point due to the
>> fact that different feature versions including slight or major differences
>> in their implementation has been released as compatible features for WSO2
>> Carbon 4.4.x (Wilkes) [1] products,
>>
>> For example,
>>
>>
>>1.
>> org.wso2.carbon.identity.application.authentication.framework.server_4.5.6.jar
>>/ org.wso2.carbon.identity.application.authentication.framewor
>>k.server_5.7.5.jar
>>2. org.wso2.carbon.directory.service.mgr.server_4.5.6.jar /
>>org.wso2.carbon.directory.service.mgr.server_5.7.5.jar
>>3. rg.wso2.carbon.forum.server_2.0.0.jar
>>/ org.wso2.carbon.forum.server_6.1.66.jar
>>4. org.wso2.carbon.identity.core.server_4.5.5.jar
>>/ org.wso2.carbon.identity.core.server_5.7.5.jar
>>5. org.wso2.carbon.identity.core.ui_4.5.5.jar
>>/ org.wso2.carbon.identity.core.ui_5.7.5.jar
>>
>> Since all the jars mentioned above have major implementational changes
>> which are not backward compatible (as indicated by the major version no
>> change) there is a huge possibility of having a functional inconsistency in
>> the system if multiple versions of the same feature are used in different
>> runtimes. For example the format of data inserted and queried out from db
>> from previous version may differ from the how it is done in the latest
>> version leaving to inconsistencies in DB. IMO I think either we should
>> restrict to one version of a certain feature or allow up to it's next major
>> version. WDYT?
>>
>>
>> [1] http://product-dist.wso2.com/p2/carbon/releases/wilkes/features/
>>
>> Thanks.
>>
>> On Fri, Aug 18, 2017 at 8:39 AM, Dilan Udara Ariyaratne
>> wrote:
>>
>>> Hi Kasun and All,
>>>
>>> Let me raise a different, but fundamental concern to this issue. Please
>>> correct me if I am wrong.
>>>
>>> It's perfectly valid to have the same feature on different run-times (or
>>> profiles) of a product, but if that same feature appears in "different
>>> versions",
>>> meaning, with slight or major differences of their implementations, at
>>> different run-times of the product, wouldn't that open up any possibilities
>>> of functional inconsistencies or even failures to the overall system ?
>>>
>>> Thanks,
>>> Dilan.
>>>
>>> *Dilan U. Ariyaratne*
>>> Senior Software Engineer
>>> WSO2 Inc. <http://wso2.com/>
>>> Mobile: +94766405580 <%2B94766405580>
>>> lean . enterprise . middleware
>>>
>>>
>>> On Thu, Aug 17, 2017 at 8:19 PM, Kasun Siyambalapitiya >> > wrote:
>>>
>>>> Hi Niranjan,
>>>>
>>>> When generating the p2-repository using `carbon-maven-plugin version
>>>> 3.x` this issue arises due to the fact that it resolves dependencies for
>>>> each given feature with the dependencies we defined in the pom itself (note
>>>> that the effective pom is used for the resolving). Since maven picks only
>>>> one version of a given dependency due the use of `nearest in the dependency
>>>> tree` strategy, a p2-repo with multiple versions of the same feature can
>>>> not be created by using the current `carbon-maven-plugin version 3.1.3`.
>>>>
>>>> But in the case of `carbon-maven-plugin version 1.5.x` this is possible
>>>> as the dependencies of each feature is defined in a string form as below
>>>>
>>>> org.apache.axis2.transport:org.apache.axis2.transport.jms.feature:
>>>>> ${axis2-transports.wso2.version.1.1.0.wso2v17}
>>>>
>>>>
>>>> and the version `${axis2-transports.wso2.version.1.1.0.wso2v17}` is
>>>> replaced with the value of the relevant property we defined in the pom.xml.
>>>> Since there are no restrictions like above in defining properties in
>>>> pom.xml this works.
>>>>
>>>> Thanks.
>>>>
>>>> On Thu, Aug 17, 2017 at 10:39 AM, Niran
[Architecture] Location for .m2 repo of a daemon maven
Hi all, I am currently working on a `go lang` application which will be used to provision a server (written in `Java`) by building a given `pom.xml` file. Since `Java` is required for running the server, we can assume that the running system is already having `Java` installed, but it could or could not have `maven` installed. So without installing `maven` or setting `M2_HOME` in `$PATH` variable of the running system, the `go` application is written in such a way that it uses a exploded `maven` distribution in a specific location for performing the build. Although `maven` build runs as a daemon process in the above scenario, it creates the `.m2` repo at the current user's home by default. What will be best option for location of `.m2` repo out of following, 1. Place `.m2` repo at the place where the application runs (can be configured using `settings.xml`) 2. Place `.m2` repo at the current user's home. Your thoughts on the above are highly appreciated. Thanks -- *Regards,* *Kasun Siyambalapitiya* *Software Engineer* WSO2 Inc. - http://wso2.com/ lean . enterprise . middleware Tel : 0715523466 E mail : kasu...@wso2.com Blog: https://medium.com/@kasunsiyambalapitiya <https://wso2.com/signature> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Location for .m2 repo of a daemon maven
Hi all, Please do note that, as with the offline discussion had with Azeez, Niranjan and myself, it was decided to keep the `.m2` repo used by the above application at a separate location without intrusively modifying the user's home directory. Thanks On Mon, Nov 13, 2017 at 9:28 AM, Niranjan Karunanandham > wrote: > Hi Kasun, > > On Fri, Nov 10, 2017 at 6:01 PM, Kasun Siyambalapitiya > wrote: > >> Hi all, >> >> I am currently working on a `go lang` application which will be used to >> provision a server (written in `Java`) by building a given `pom.xml` file. >> Since `Java` is required for running the server, we can assume that the >> running system is already having `Java` installed, but it could or could >> not have `maven` installed. >> >> So without installing `maven` or setting `M2_HOME` in `$PATH` variable of >> the running system, the `go` application is written in such a way that it >> uses a exploded `maven` distribution in a specific location for performing >> the build. >> >> Although `maven` build runs as a daemon process in the above scenario, it >> creates the `.m2` repo at the current user's home by default. What will be >> best option for location of `.m2` repo out of following, >> >>1. Place `.m2` repo at the place where the application runs (can be >>configured using `settings.xml`) >>2. Place `.m2` repo at the current user's home. >> >> It would be better to go with option 2 where we use .m2 repo configured > by the user. The reason for this, there is only one m2 repo in the user's > machine. If the user wants to change the m2 location use by your > application, then IMO there should be a configuration to set this. > > >> Your thoughts on the above are highly appreciated. >> >> Thanks >> >> -- >> *Regards,* >> >> *Kasun Siyambalapitiya* >> *Software Engineer* >> WSO2 Inc. - http://wso2.com/ >> lean . enterprise . middleware >> Tel : 0715523466 >> E mail : kasu...@wso2.com >> >> Blog: https://medium.com/@kasunsiyambalapitiya >> <https://wso2.com/signature> >> > > Regards, > Nira > > -- > > > *Niranjan Karunanandham* > Associate Technical Lead - WSO2 Inc. > WSO2 Inc.: http://www.wso2.com > > -- *Regards,* *Kasun Siyambalapitiya* *Software Engineer* WSO2 Inc. - http://wso2.com/ lean . enterprise . middleware Tel : 0715523466 E mail : kasu...@wso2.com Blog: https://medium.com/@kasunsiyambalapitiya <https://wso2.com/signature> -- *Regards,* *Kasun Siyambalapitiya* *Software Engineer* WSO2 Inc. - http://wso2.com/ lean . enterprise . middleware Tel : 0715523466 E mail : kasu...@wso2.com Blog: https://medium.com/@kasunsiyambalapitiya <https://wso2.com/signature> ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
