How about WSO2 Commons projects, E.g Siddhi ? Currently its in commons and under dependencies/commons
Where should we have this? I believe projects like Siddhi also need to be top level repos may be "commons-siddhi" and it don't need be in dependencies/commons anymore. WDYT? Suho On Tue, Jan 21, 2014 at 3:13 PM, Eranda Sooriyabandara <[email protected]>wrote: > Hi All > Please find the updated governance component in [1]. > > thanks > Eranda > > [1]. https://github.com/wso2/carbon-governance > > > On Tue, Jan 21, 2014 at 2:56 PM, Shariq Muhammed <[email protected]> wrote: > >> On Tue, Jan 21, 2014 at 2:42 PM, Eranda Sooriyabandara >> <[email protected]>wrote: >> >>> Hi Shariq, >>> Yeah, we may not needed those to be build again and again. So let's add >>> related stubs to service-stubs directory in each repo. >>> >> >> Yea lets structure it that way. >> >> >>> >>> thanks >>> Eranda >>> >>> >>> On Tue, Jan 21, 2014 at 12:51 PM, Shariq Muhammed <[email protected]>wrote: >>> >>>> On Tue, Jan 21, 2014 at 12:38 PM, Kishanthan Thangarajah < >>>> [email protected]> wrote: >>>> >>>>> Yes, we don't need to separately say "service-stubs", it should be >>>>> under the components level as just another component. >>>>> >>>> >>>> Initially we extracted out the service stubs because it doesn't change >>>> frequently. So we can reduce the build time because we don't need to do >>>> wsdl2java in each build cycle. Looks like we are going to add it back? >>>> >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jan 21, 2014 at 12:30 PM, Eranda Sooriyabandara < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Kicha, >>>>>> There will be no service stubs directory it will be a additional >>>>>> component in the same level as BE + FE components. >>>>>> >>>>>> thanks >>>>>> Eranda >>>>>> >>>>>> >>>>>> On Tue, Jan 21, 2014 at 11:41 AM, Kishanthan Thangarajah < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Eranda, >>>>>>> >>>>>>> Where have you put the service-stubs related to governance >>>>>>> component? It should come under the same repo as carbon-component- >>>>>>> governance. >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 21, 2014 at 12:29 AM, Eranda Sooriyabandara < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> As a PoC I just completed the carbon-component-governance. Please >>>>>>>> find it in [1] and let me know your comments and suggestions. Please >>>>>>>> keep >>>>>>>> in mind that this is not in a buildable state since other >>>>>>>> components need to build before this. >>>>>>>> >>>>>>>> thanks >>>>>>>> Eranda >>>>>>>> >>>>>>>> [1] https://github.com/wso2/carbon-component-governance >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jan 17, 2014 at 9:26 PM, Afkham Azeez <[email protected]>wrote: >>>>>>>> >>>>>>>>> [Sorry for the very long mail. I want to document all that I had >>>>>>>>> in mind & the stuff we discussed. I would recommend all devs to >>>>>>>>> take some time to read this] >>>>>>>>> >>>>>>>>> >>>>>>>>> I would like to summarize he discussion we had a couple of days >>>>>>>>> back. >>>>>>>>> >>>>>>>>> *The Problems* >>>>>>>>> The problems we are trying to solve are as follows: >>>>>>>>> >>>>>>>>> 1. Trunk & branches structures being completely different >>>>>>>>> 2. Branches containing directories with version numbers >>>>>>>>> 3. It is impossible to move to GitHub with the current structure >>>>>>>>> because of #2 >>>>>>>>> 4. It is very easy to break the build by changing already released >>>>>>>>> code. The room for human error is high. >>>>>>>>> 5. Bamboo builds are eternally broken because the build fails at >>>>>>>>> some point & Bamboo cannot continue any further >>>>>>>>> 6. When we branch, the trunk quickly becomes obsolete, and >>>>>>>>> remains in that broken state until the next major platform release. >>>>>>>>> 7. Everybody has to build all components/features, even if those >>>>>>>>> are not related to their products >>>>>>>>> 8. Fixed versions in branches instead of using SNAPSHOT versions. >>>>>>>>> This makes it impossible to upload build artifacts to Maven/Nexus >>>>>>>>> repos. This leads to #7. >>>>>>>>> 9. Impossible to integrate code quality tools such as EraInsight >>>>>>>>> because of #5 >>>>>>>>> >>>>>>>>> *Proposed solution* >>>>>>>>> We have come up with the following solution after much >>>>>>>>> deliberation & thought. >>>>>>>>> >>>>>>>>> Rationale: >>>>>>>>> We started looking at other open source projects out there. We >>>>>>>>> took Axis2 as an example. Axis2 had many dependencies includingAxiom, >>>>>>>>> XmlSchema, Woden, WSS4J etc. Those 3rd party dependencies were >>>>>>>>> also developed by some Axis2 contributors, but we never branched all >>>>>>>>> of >>>>>>>>> those together and brought them into the same code branch. We used to >>>>>>>>> start >>>>>>>>> what we used to call a release train, where the upstream code would >>>>>>>>> have to >>>>>>>>> be released first before the downstream code such as Axis2 & Synapse >>>>>>>>> could >>>>>>>>> be released. This way, we never had any of the problems outlined >>>>>>>>> above. >>>>>>>>> >>>>>>>>> If you look at the WSO2 product releases, again, the scenario is >>>>>>>>> not that much different from the Axis2/Synapse releases. Components & >>>>>>>>> features are simply dependencies of the products. In order to get >>>>>>>>> product >>>>>>>>> releases out, we first need releases of those >>>>>>>>> dependencies (components/features). So the proposal is to identify >>>>>>>>> the top >>>>>>>>> level components/features, and first release that code before doing >>>>>>>>> product >>>>>>>>> releases. Each of those components will have a GitHub repo. All >>>>>>>>> active development will be done on the main branch of those >>>>>>>>> components, and >>>>>>>>> will be branched when they are close to the release. Instead of >>>>>>>>> granting >>>>>>>>> commit rights to all, we could only allow the primary developersof >>>>>>>>> those components to commit, and others can send pull requests, which >>>>>>>>> will be merged in by the primary owners after reviewing. These >>>>>>>>> component >>>>>>>>> teams could even have an internal Git repo or clone, and commit >>>>>>>>> to that, run all tests, and when they are satisfied that the code is >>>>>>>>> in a >>>>>>>>> good state to be merged into the main branch, they can send a pull >>>>>>>>> request >>>>>>>>> & merge the changes. We would run Bamboo which would build the >>>>>>>>> components >>>>>>>>> several times a day & deploy them to the Nexus repo. That way, >>>>>>>>> you would not have to build code that is not directly related to what >>>>>>>>> you >>>>>>>>> are working on, which would save 100s of valuable dev hours. >>>>>>>>> >>>>>>>>> In the majority of the cases, the P2 features correspond to one or >>>>>>>>> more related components. So we would keep the feature close to the >>>>>>>>> component. There are some cases where these components & features >>>>>>>>> belong >>>>>>>>> in the product itself. AppFactory components are a good example. >>>>>>>>> >>>>>>>>> Products will also have their own GitHub repos. We will have >>>>>>>>> separate GitHub repos for platform integration tests. Products >>>>>>>>> such as API Manager may opt to have the API Management feature in >>>>>>>>> the product itself. We would have a separate P2-repo GitHub repo >>>>>>>>> which would build & deploy the compatible set of P2 features. >>>>>>>>> >>>>>>>>> We will have Bamboo plans at multiple levels; components, >>>>>>>>> products, platform, p2-repo and so on. >>>>>>>>> >>>>>>>>> We will not change any package structures at this time. We would >>>>>>>>> defer that to Carbon 5 (if necessary). We will get rid of the chunk >>>>>>>>> based >>>>>>>>> release model. Continuous delivery is our ultimate aim & for that to >>>>>>>>> happen, we have to release a compatible set of features. We are going >>>>>>>>> to >>>>>>>>> rely heavily on automation, automated builds & deploys to Maven. The >>>>>>>>> developers will do the majority of the QA (just like the Apache >>>>>>>>> Stratos >>>>>>>>> team is doing now). >>>>>>>>> >>>>>>>>> We will use the Maven release plugin to create releases & upload >>>>>>>>> them to the Maven repo. >>>>>>>>> >>>>>>>>> *Implications to WSO2 code developers* >>>>>>>>> 1. Life becomes easier because you don't have to spend a lot of >>>>>>>>> time building unrelated stuff >>>>>>>>> 2. General development would happen in the main branch. >>>>>>>>> 3. Close to a release, branches would be cut. >>>>>>>>> 4. Once release branches are cut, fixes would be done in the main >>>>>>>>> branch, and pull requests would be sent to the branch & merged in. >>>>>>>>> This >>>>>>>>> will be easy because we no longer have the trunk & branch structure >>>>>>>>> being >>>>>>>>> different. >>>>>>>>> >>>>>>>>> >>>>>>>>> *Implications to users* >>>>>>>>> Users will not see any difference in the components & features >>>>>>>>> because we are not changing packages or binary structure. In fact, we >>>>>>>>> would >>>>>>>>> have a P2 repo with compatible features which all work together. >>>>>>>>> >>>>>>>>> Senaka, Isuruwan & Harshana have already started working on a PoC. >>>>>>>>> >>>>>>>>> Thoughts welcome. Those who were in these discussions, please add >>>>>>>>> anything I may have missed. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Afkham Azeez* >>>>>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>>>>>>> Member; Apache Software Foundation; http://www.apache.org/ >>>>>>>>> * <http://www.apache.org/>* >>>>>>>>> *email: **[email protected]* <[email protected]> >>>>>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * >>>>>>>>> *http://blog.afkham.org* <http://blog.afkham.org> >>>>>>>>> * twitter: >>>>>>>>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>>>>>>>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez >>>>>>>>> <http://lk.linkedin.com/in/afkhamazeez>* >>>>>>>>> >>>>>>>>> *Lean . Enterprise . Middleware* >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Eranda Sooriyabandara*Senior Software Engineer; >>>>>>>> Integration Technologies Team; >>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>> Lean . Enterprise . Middleware >>>>>>>> >>>>>>>> E-mail: eranda AT wso2.com >>>>>>>> Mobile: +94 716 472 816 >>>>>>>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >>>>>>>> Blog: http://emsooriyabandara.blogspot.com/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Kishanthan Thangarajah* >>>>>>> Senior Software Engineer, >>>>>>> Platform Technologies Team, >>>>>>> WSO2, Inc. >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> Mobile - +94773426635 >>>>>>> Blog - *http://kishanthan.wordpress.com >>>>>>> <http://kishanthan.wordpress.com>* >>>>>>> Twitter - *http://twitter.com/kishanthan >>>>>>> <http://twitter.com/kishanthan>* >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> [email protected] >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Eranda Sooriyabandara*Senior Software Engineer; >>>>>> Integration Technologies Team; >>>>>> WSO2 Inc.; http://wso2.com >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>>> E-mail: eranda AT wso2.com >>>>>> Mobile: +94 716 472 816 >>>>>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >>>>>> Blog: http://emsooriyabandara.blogspot.com/ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Kishanthan Thangarajah* >>>>> Senior Software Engineer, >>>>> Platform Technologies Team, >>>>> WSO2, Inc. >>>>> lean.enterprise.middleware >>>>> >>>>> Mobile - +94773426635 >>>>> Blog - *http://kishanthan.wordpress.com >>>>> <http://kishanthan.wordpress.com>* >>>>> Twitter - *http://twitter.com/kishanthan >>>>> <http://twitter.com/kishanthan>* >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks, >>>> M. S. M. Shariq. >>>> Senior Software Engineer >>>> Phone: +94 777 202 225 >>>> >>> >>> >>> >>> -- >>> >>> *Eranda Sooriyabandara*Senior Software Engineer; >>> Integration Technologies Team; >>> WSO2 Inc.; http://wso2.com >>> Lean . Enterprise . Middleware >>> >>> E-mail: eranda AT wso2.com >>> Mobile: +94 716 472 816 >>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >>> Blog: http://emsooriyabandara.blogspot.com/ >>> >>> >>> >>> >>> >> >> >> -- >> Thanks, >> M. S. M. Shariq. >> Senior Software Engineer >> Phone: +94 777 202 225 >> > > > > -- > > *Eranda Sooriyabandara*Senior Software Engineer; > Integration Technologies Team; > WSO2 Inc.; http://wso2.com > Lean . Enterprise . Middleware > > E-mail: eranda AT wso2.com > Mobile: +94 716 472 816 > Linked-In: http://www.linkedin.com/in/erandasooriyabandara > Blog: http://emsooriyabandara.blogspot.com/ > > > > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *S. Suhothayan* Associate Technical Lead, *WSO2 Inc. *http://wso2.com * <http://wso2.com/>* lean . enterprise . middleware *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter: http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in: http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
