Dan, Ross. I complexly agree with both of you. My workflow - my problems. I wrote about it just so you have background about needs of developers like me. When I read about number 99% CLI developers, I understand that I am from the not mentioned 1%. And tone of the discussion for me sounds like that 1% would not be taken into consideration.
Right now I have 2 small issues which would be important for you only if you keep you ./plugins, ./platforms source code in VCS. Don't think that they are valuable enough for you when you main use-case is keep ./plugins and ./platforms outside of VCS, so I better implement them myself and contribute back to the Cordova. What is not clear to me, are such contributions would be welcome or not, since it is for only 1% of people? Andrey K. 2014/1/7 Ross Gerbasi <rgerb...@gmail.com> > Hey Andrey, > > Much like you said 99% of the users will want to ignore platforms and > plugins from version control. Making this work properly would not stop > someone from including them if they wanted to. If your workflow is better > including those folders you would have no problem doing so. > > Ideally though if you can keep your custom code off in plugins, even if > they are not public plugins, would be ideal. Also as Dan mentioned you can > look into hooks to help modify platforms as needed. > > Again though if you find checking everything in easier thats cool but the > CLI should be setup in a way that we do not need to. > > > > On Mon, Jan 6, 2014 at 6:59 PM, Dan Moore <moore...@yahoo.com> wrote: > > > 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. > > > > > > > > > > > > > > > > > > > > >
