Hi, If we are going with patching directory model, then following are my initial thoughts.
- We will have a directory named .patches(or a better name) in the app root - Patches will have to be copied into that with directories named 0, 1, 2 ... n - We can either ask them to restart the server or we can simply hot deploy/undeploy the patches by listening to the .patch directory of the app Another doubt that I have is, whether we need to offer it as a part of Jaggery core itself or to offer it as a Jaggery module. If it is included in the core, then Jaggery server itself will be looking at the directories and deploy the patches. But, if we go with a Jaggery module, then they will have to explicitly engage/initialize the apps for patching via an init script. 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*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
