About plugin and platform version control. I heard a lot about that, and confused why you think that everybody would like to remove ./plugins and ./platforms folders from source control. I do agree that this is most likely the case for the simple applications and for the maybe 99% of current Cordova users, but I don't believe that this is truly important for the Cordova as the ecosystem for the cross-platform of the mobile development.
Let me explain why I think that keep ./platforms and ./plugins under source control very important. I would base my reasoning on my current project needs. I currently develop 2 similar products for different clients from the same domain. I understand that in future I will have another clients from same problem domain which would like to have similar applications, just with different design. So I take the route of having 1 product line and customization of that product line for each client, depends on their needs. This is client facing application, so I would like to cover as much mobile platforms as possible with minimum amount of efforts. Currently I support only Android and iOS platforms, but envision that my clients will expand to the Windows Phone soon, and maybe I will force them to support Tizen in next year if that platform would be world-wide popular. I position my self as a) heavy Cordova user b) middle/low platform specific development. (I have to go deep in each platform, but that's not priority for me as Cordova users) I maintain 3 Git branches. 1 branch for core product and 2 branches for each client. In each branch I keep, platform specific code for the application (cordova-platform-ios/android code), Cordova plugins code + plugins developed specifically to this application. I definitely sure that I will need to add some functionality to the core platforms, either iOS or Android which will benefit the my application. I would try to push to the core Cordova as much as I can, but possible that not all contribution would be useful for the Cordova. Either way I plan for update to next version of Cordova (3.4, or 3.5 whenether). To keep my changes, which I add to current version of Cordova (3.3) and make update to 3.4 and later easier I keep all code in the source control to make all my future merges easier. Same rules apply to the plugins,maybe I add some code/fixes to plugins, or not don't matter - I have to plan for that. I would like to contribute to Cordova everything what will benefit the community to meet my selfish goals: I want to make my upgrade path as straightforward as possible, for platform code and for plugins code. Maybe I was too verbose, but that was just to explain that I plan to align my long-term goals with Cordova's long-term goals. I try to gave more explanation, so you guys could plan not only for people which create projects which are working on the specific version of Cordova, but also for the guys which want to nurture their product together with Cordova. I plainly don't see: a) how I could work on my product not keeping ./platforms and ./plugins directories in the source control, and b) why I should don't use Cordova CLI to update contents of my ./platforms and ./plugins folders. I think that these tool has a good fit for basic housekeeping of the files/plugins. Don't want to manually fiddle with content of plugins for each platform and use plugman/cordova executables to do the job. Hopefully I was enough verbose to explain why I have needs what I have now, and not too verbose so you flood in details. To summarize my input is: 1. Keep tools that way, that it could work either when ./plugins, ./platforms in source control, or when these folders not in the VCS. 2. Take into account that people may want to customize Cordova distribution and have path to future upgrades. 3. I want to take responsibility for some burden which this way could potentially create for you guys, Andrey Kurdyumov. 2014/1/7 Braden Shepherdson <bra...@chromium.org> > I've wanted to add Cordova plugin dependencies to the app's top-level > config.xml for a long time, but it's never reached the top of my > priorities. I think with that support, we can avoid checking in ./plugins/ > and ./platforms altogether for 99% of app developers. If it doesn't solve > anyone's use case, I'd love to hear about it. > > Braden > > > On Tue, Dec 31, 2013 at 2:03 PM, Ross Gerbasi <rgerb...@gmail.com> wrote: > > > CB-4624 is exactly what I am looking for. I am not sure if it should be > > config.xml or some other config file, it probably doesn't matter much > when > > it comes down to it. Is there any rules currently in place, like CLI > > doesn't touch config.xml? > > > > > > On Tue, Dec 31, 2013 at 12:27 PM, Andrew Grieve <agri...@chromium.org > > >wrote: > > > > > I think https://issues.apache.org/jira/browse/CB-4624 is the relevant > > > issue > > > here. Please add comments to it if it's not spec'ed or good enough. > > > > > > Also related is https://issues.apache.org/jira/browse/CB-5006 - meant > to > > > address local repos of plugins. > > > > > > > > > On Tue, Dec 31, 2013 at 3:02 AM, Andrey Kurdumov < > > kant2...@googlemail.com > > > >wrote: > > > > > > > Hi all, > > > > > > > > Would be very helpful if you change formatting of the plugins > manifest > > > > files (android.json, ios.json). Currently it is print all JSON string > > to > > > > the big single line, which difficult to merge when needed. > > > > > > > > > >
