Peace~
---
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [email protected]
  ~Mobile     +94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw

On November 28, 2013 at 2:01:50 AM, Ruchira Wageesha ([email protected]) wrote:

Hi Dulitha,

What I see is, every Jaggery app should be a p2 feature which can be installed 
into whatever product they want. You guys will always use either a released app 
or the snapshot. In both cases, you will have to build app feature first and 
your product next, where you get it up to date.
Yes - but this is the way to package it. Let’s think from scratch. I am 
building a new store (a photo store) on top of ES. I create my own carbon 
server - adding ES as a feature. With that I do get the store. But then I have 
to depend on Build-time to get the Store app. What I will do is - I will have a 
copy of the Store app and add my photo store sources to that. Suppose now I 
want to get changes for the Store app alone - I am stuck. Either I have to do a 
Diff copy or get a new store app and add my sources to that. My point is - p2 
features is not the solution for jaggery apps (in the context of store). 

Now let’s think from a Enterprise Store point of view. I want to connect all my 
stores together. That would require me to isolate my sources to a folder. This 
can be done with the current store app implementation. Having the store app as 
a module solves - as I see all the problems from a store builder’s point of 
view. 



At the moment, those apps have a few dependencies to other carbon features etc. 
and you will have to get those changes as well with the up to date Jaggery 
sources. Hence, just having a git sub module will not work as expected and 
correct model is to have self contained features.
That will come from the ES feature.



As I had mentioned in one of my previous mails, whole store has bundled as a 
feature now, where you can install it using p2 and get everything up to date, 
not just the app sources. 

Further, that feature contains both publisher and store apps, but if it's 
needed we can make them as separate features.


On Wed, Nov 27, 2013 at 8:30 AM, Dulitha Wijewantha <[email protected]> wrote:
Hi guys,
What do you think about having git submodules for apps? For an example in the 
Store project it has the apps in the jaggeryapps folder. If we have a separate 
git project for each app (publisher git repo) it would easy for people to get 
changes of the particular jaggery app. 

An example would be - I am having the store jaggery app in the mobile server. I 
want to get the latest changes from the generic store. Right now I have to get 
a copy of the generic store and put my features into that. If we have a 
separate git project for the generic store app I can do a git pull and auto 
merge the generic store changes. 

WDYT? 
--
Chan (Dulitha Wijewantha) 
Software Engineer - Mobile Development
WSO2Mobile 
Lean.Enterprise.Mobileware
  ~Email       [email protected]
  ~Mobile     +94712112165
  ~Website   dulithawijewantha.com
  ~Blog         blog.dulithawijewantha.com
  ~Twitter     @dulitharw



--
Ruchira Wageesha
Associate Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: [email protected],   blog: ruchirawageesha.blogspot.com,   mobile: +94 77 
5493444
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to