Hi Andrey, I have worked on two small, simple Cordova applications, but we still at times had to modify platform specific code. Not much, but some (AppDelegate.m for the iOS app, and the DroidGap subclass for Android--this is a 2.9.x project for now).
Here's my solutions to your issues. * if you need to modify native plugin code, you should fork the repo and manage your changes via a git project, not in your project. If you use a recent enough version of Cordova, you can even pull plugins off git branches ( see https://issues.apache.org/jira/browse/CB-4981 ) so you could have different versions of your apps for different clients pull different branches of the same plugin. * if you need to modify code under platforms, use an after_platform_add hook, and keep your customized platform files elsewhere in your project tree. This way, you aren't version controlling everything, just what you've had to change. Of course, when the Cordova platform changes underneath you (perhaps a new method is added to AppDelegate.m, and the version you have in source control overwrites that), you need to check these files carefully. But when you version control everything and you upgrade, you have to merge in your custom changes into the new Cordova code in the same careful manner, plus you are carrying around everything else under platforms. Of course, I'm a big believer in the CLI, having everyone use the entire CLI toolchain, and treating everything under platforms and plugins as derived code that you can replace at any time. If this isn't how you develop (if you prefer the 'native project dev' workflow, for example), then this may not work for you. Thanks. Dan PS Can you explain how keeping all the code in source control makes your merges as you move from Cordova version to Cordova version easier? To me, that would seem to make them more difficult. On Monday, January 6, 2014 5:38 PM, Andrey Kurdumov <kant2...@googlemail.com> wrote: 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. > > > > > > > > > >
