what will happen if broken-page.js was edited by the user? then patching will override everything right?
On Wed, Feb 19, 2014 at 10:49 AM, Madhuka Udantha <[email protected]> wrote: > Hi, > > *Deploying patches * > > If we have meta file(/json file) in patch directory can be used as patch > meta holder/identification. Each time server start or patch module cycle > run we can do not need to add patch over again and again. Patch meta file > will have param that is it apply or not for app. > > *Patch folder structure.* > > > > Inside patch folder we can mirror app directory structure and do the > patching file. > > /app > > ---/includes > > ---/modules > > ---/controllers > > ----------/broken-page.js > > ----------/index.js > > ---/patches > > --------/controllers > > --------------/broken-page.js > > > > or we can store files in any structure inside patch folder (main will be > root) and use metafile to locate files in app. This will reduce folder > crawling. > > > > > > *Regard dependency* > > Dependency between jaggery patch and usual patch, we will have to handle > it manually. > > > > WDYT? > > > > > > On Tue, Feb 18, 2014 at 3:48 PM, Madhuka Udantha <[email protected]> wrote: > >> >> >> >> On Tue, Feb 18, 2014 at 3:42 PM, Ruchira Wageesha <[email protected]>wrote: >> >>> >>>>> >>>> But, if we go with a Jaggery module, then they will have to >>>>> explicitly engage/initialize the apps for patching via an init script. >>>>> >>>> If we follow jaggery module for patching then to apply patch, user have >>>> to update/add jaggery config file and init script. It is not much good in >>>> IMO >>>> If this feature come from jaggery core user only need to add the patch >>>> folder. It is bit easy and nice for jaggery app user/Dev. >>>> >>> Nope Madhuka, that's not what I meant. The complete patching process >>> will be implemented as Jaggery module and user's will have to make their >>> apps patchable via an init script. i.e. Patching can either be enabled or >>> disabled via an init script. After that, you will never need to edit >>> anything and patches will be automatically picked and deployed. >>> >>> +1, >> >>> As an example, assume you have a module named patcher with an init >>> method as below. >>> >>> var init = function(options) { >>> setInterval(function() { >>> //lookup patches directory and install new patches >>> }, options.interval); >>> }; >>> >>> Then, you can have following in your init script. >>> >>> var patcher = require('patcher'); >>> patcher.init({ >>> interval: 10000 >>> }); >>> >>> >>>> >>>>> WDYT? >>>>> >>>>> /Ruchira >>>>> >>>>> >>>>> >>>>> On Tue, Feb 18, 2014 at 11:17 AM, Chan <[email protected]> wrote: >>>>> >>>>>> Guys it would be awesome if you can describe how the patch directory >>>>>> in the app works (I mean in detail). Then everyone will be clear about >>>>>> it. >>>>>> >>>>>> Cheers~ >>>>>> >>>>>> >>>>>> On Tue, Feb 18, 2014 at 10:12 AM, Madhuka Udantha >>>>>> <[email protected]>wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Feb 17, 2014 at 8:56 PM, Nuwan Bandara <[email protected]>wrote: >>>>>>> >>>>>>>> Guys whats the verdict on this discussion ? Having a patch >>>>>>>> directory within the app seems to be a fine idea, which does not >>>>>>>> effect the >>>>>>>> platform patching or raise depsyc complications. >>>>>>>> >>>>>>> "patch directory" was most fine solution that we came across on this >>>>>>> thread and also same discussion had in few email threads[1] did not have >>>>>>> any conclusion for $subject. I too think $subject is essential for all >>>>>>> products that depend on jaggery apps >>>>>>> I am +1 for "patch directory" >>>>>>> >>>>>>> Shall we come to a conclusion and implement this. IMO this is vital >>>>>>>> to all the products that has jaggery applications. >>>>>>>> >>>>>>>> >>>>>>> [1] Webapp Patching Strategy @ [email protected] on 4/5/13 >>>>>>> >>>>>>>> Regards, >>>>>>>> /Nuwan >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jan 30, 2014 at 12:19 AM, Chan <[email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thursday, January 30, 2014, Tanya Madurapperuma <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jan 29, 2014 at 10:49 AM, Chan <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jan 29, 2014 at 10:43 AM, Chan <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jan 29, 2014 at 10:25 AM, Madhuka Udantha < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Jan 29, 2014 at 3:27 AM, Nuwan Bandara <[email protected]>wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jan 28, 2014 at 1:19 PM, Afkham Azeez <[email protected]>wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jan 28, 2014 at 11:06 PM, Nuwan Bandara >>>>>>>>>> <[email protected]>wrote: >>>>>>>>>> >>>>>>>>>> Hi All >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jan 28, 2014 at 11:33 AM, Manuranga Perera <[email protected] >>>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> The problem ultimately boils down to this common scenario: >>>>>>>>>> >>>>>>>>>> a) A customer has a Jaggery app in their environment. >>>>>>>>>> b) Some UI (images, css, headers, ect.) is customized >>>>>>>>>> c) Now they find a bug and ask for a patch >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> +1, the issue here is all others replied here against patching a >>>>>>>>>> jaggery app is because you think of a jaggery app as a "hello world" >>>>>>>>>> web >>>>>>>>>> app. But you should look at the jaggery code in products like APIM / >>>>>>>>>> AppFac >>>>>>>>>> / UES / ES / MDM. In all these products Jaggery app is the place >>>>>>>>>> that has >>>>>>>>>> the major business logic. In these products Carbon is just the >>>>>>>>>> hosting >>>>>>>>>> environment. These are full fledge applications that does all kinds >>>>>>>>>> of >>>>>>>>>> things, generate meta data, has its own configurations etc, and when >>>>>>>>>> we >>>>>>>>>> find a minor issue we cannot ask people to replace the entire app and >>>>>>>>>> reconfigure every thing from the beginning. >>>>>>>>>> >>>>>>>>>> Just try the application developers shoes for a moment here and >>>>>>>>>> get out of the midleware developer mindset; Imagine we have >>>>>>>>>> developed an >>>>>>>>>> application and thats our main product. Now how do you fix problems >>>>>>>>>> in this >>>>>>>>>> product ? will you be shipping new versions of the product always >>>>>>>>>> when you >>>>>>>>>> find an issue ? If that is the case we will be shipping new versions >>>>>>>>>> of AS >>>>>>>>>> every day ;) >>>>>>>>>> >>>>>>>>>> Also when there is a requirement we should not think about how it >>>>>>>>>> can be squeezed into the existing model with minimum headache. We >>>>>>>>>> should >>>>>>>>>> find a comfortable solution for the users not something comfortable >>>>>>>>>> to >>>>>>>>>> implement. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The requirement is to fix bugs in apps. The requirement is not, >>>>>>>>>> support patching of webapps. The solution is to update the app >>>>>>>>>> through patch file if the app is uses a textual scripting >>>>>>>>>> language, or redeploy changed or a new version, if the app is in a >>>>>>>>>> compiled/binary/bytecode form. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> +1, that should work, but we nee >>>>>>>>>> >>>>>>>>>> AFAIU this solution is not feasible as we have to maintain a >>>>>>>>>> separate git repo for each customer. >>>>>>>>>> >>>>>>>>> As far as I know - we do maintain code bases for customers. Plus >>>>>>>>> maintaining git repos for customers is realistically not a hard thing >>>>>>>>> to do >>>>>>>>> cause everything is scriptable in git. >>>>>>>>> >>>>>>>>>> It will become an issue when the number of customers grow. And >>>>>>>>>> also customers with lesser developer knowledge will face issues in >>>>>>>>>> resolving conflicts in merging etc. >>>>>>>>>> >>>>>>>>> If customers customize our jaggery apps which they will definitely >>>>>>>>> do - they will version control it anyway and most probably they will >>>>>>>>> use >>>>>>>>> git. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Patches approach is nice but thinking from an Application >>>>>>>>>> Developer stand point version controlling is the best way to handle >>>>>>>>>> this >>>>>>>>>> type of patches. Food for thought I guess. >>>>>>>>>> >>>>>>>>>> [1] - https://devcenter.heroku.com/articles/git >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jan 28, 2014 at 1:37 PM, Afkham Azeez <[email protected]>wrote: >>>>>>>>>> >>>>>>>>>> Cluster-wide patch distribution will be handle by the Operations >>>>>>>>>> Center. >>>>>>>>>> >>>>>>>>>> Azeez >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jan 28, 2014 at 12:40 PM, Ruchira Wageesha < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Tanya Madurapperuma >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Chan (Dulitha Wijewantha) >>>>>>>>> Software Engineer - Mobile Development >>>>>>>>> WSO2Mobile >>>>>>>>> Lean.Enterprise.Mobileware >>>>>>>>> * ~Email [email protected] <[email protected]>* >>>>>>>>> * ~Mobile +94712112165 <%2B94712112165>* >>>>>>>>> >>>>>>>>> * ~Website dulithawijewantha.com >>>>>>>>> <http://dulithawijewantha.com/> * >>>>>>>>> >>>>>>>>> * ~Blog blog.dulithawijewantha.com >>>>>>>>> <http://dulichan.github.io/chan/>* >>>>>>>>> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Architecture mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Thanks & Regards,Nuwan BandaraTechnical Lead; **WSO2 Inc. * >>>>>>>> *lean . enterprise . middleware | http://wso2.com >>>>>>>> <http://wso2.com> * >>>>>>>> >>>>>>>> *blog : http://nuwanbando.com <http://nuwanbando.com>; email: >>>>>>>> [email protected] <[email protected]>; phone: +1 812 606 7390 >>>>>>>> <%2B1%20812%20606%207390> * >>>>>>>> <http://www.nuwanbando.com/> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Madhuka* Udantha >>>>>>> Senior Software Engineer >>>>>>> Development Technologies >>>>>>> WSO2 Inc. : http://wso2.com >>>>>>> >>>>>>> *Mobile*: +94774066336 >>>>>>> *Blog*: http://madhukaudantha.blogspot.com/ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Chan (Dulitha Wijewantha) >>>>>> Software Engineer - Mobile Development >>>>>> WSO2Mobile >>>>>> Lean.Enterprise.Mobileware >>>>>> * ~Email [email protected] <[email protected]>* >>>>>> * ~Mobile +94712112165 <%2B94712112165>* >>>>>> >>>>>> * ~Website dulithawijewantha.com <http://dulithawijewantha.com/> * >>>>>> >>>>>> * ~Blog blog.dulithawijewantha.com >>>>>> <http://dulichan.github.io/chan/>* >>>>>> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Ruchira Wageesha**Associate Technical Lead* >>>>> *WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>>> <http://wso2.com>* >>>>> >>>>> *email: [email protected] <[email protected]>, blog: >>>>> ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>, >>>>> mobile: +94 77 5493444 <%2B94%2077%205493444>* >>>>> >>>> >>>> >>>> >>>> -- >>>> *Madhuka* Udantha >>>> Senior Software Engineer >>>> Development Technologies >>>> WSO2 Inc. : http://wso2.com >>>> >>>> *Mobile*: +94774066336 >>>> *Blog*: http://madhukaudantha.blogspot.com/ >>>> >>> >>> >>> >>> -- >>> >>> *Ruchira Wageesha**Associate Technical Lead* >>> *WSO2 Inc. - lean . enterprise . middleware | wso2.com >>> <http://wso2.com>* >>> >>> *email: [email protected] <[email protected]>, blog: >>> ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>, >>> mobile: +94 77 5493444 <%2B94%2077%205493444>* >>> >> >> >> >> -- >> *Madhuka* Udantha >> Senior Software Engineer >> Development Technologies >> WSO2 Inc. : http://wso2.com >> >> *Mobile*: +94774066336 >> *Blog*: http://madhukaudantha.blogspot.com/ >> > > > > -- > *Madhuka* Udantha > Senior Software Engineer > Development Technologies > WSO2 Inc. : http://wso2.com > > *Mobile*: +94774066336 > *Blog*: http://madhukaudantha.blogspot.com/ > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email [email protected] <[email protected]>* * ~Mobile +94712112165* * ~Website dulithawijewantha.com <http://dulithawijewantha.com/>* * ~Blog blog.dulithawijewantha.com <http://dulichan.github.io/chan/>* * ~Twitter @dulitharw <https://twitter.com/dulitharw>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
