+1 on emulating node/npm "cordova install" reads cordova.json or cordova section of package.json (which contains all dependencies for plugins and platforms) to download and add from heaven (oops I meant the cloud :-) )
On Tue, Jan 7, 2014 at 1:33 PM, Brian LeRoux <b...@brian.io> wrote: > we may want to emulate node/npm here > > `npm install` > > > On Tue, Jan 7, 2014 at 10:20 AM, Andrew Grieve <agri...@chromium.org> > wrote: > > > Definitely a config.xml thing. > > > > I don't think anyone's fiddling. If you want to take it on, that'd be > > awesome. Mark the issue as assigned to yourself (just gave you JIRA > perms) > > and have at it! :) > > > > Idea for implementing this: > > 1. Get "cordova plugin add" at add a <dependency> tag to config.xml > > 2. Add a "cordova plugin sync" command that adds/removes plugins based on > > what's in config.xml > > > > > > > > On Tue, Jan 7, 2014 at 9:12 AM, Ross Gerbasi <rgerb...@gmail.com> wrote: > > > > > Sooooo I think we are all cool on this. Adding this feature does not > stop > > > anyone from checking in those folders if they desire. > > > > > > How can I help make this happen? Or is someone already fiddling with > > this? > > > Last activity on the issue was a month ago ( > > > https://issues.apache.org/jira/browse/CB-4624) > > > > > > Then again does this still require some choices to be made? I know > there > > is > > > a lot of talk of config.xml and cordova.json and what goes where but I > am > > > assuming this is a config.xml thing. > > > > > > > > > On Tue, Jan 7, 2014 at 11:03 AM, Braden Shepherdson < > bra...@chromium.org > > > >wrote: > > > > > > > I think we're talking somewhat at cross purposes. > > > > > > > > One of my goals with the CLI is to make the ./platforms and ./plugins > > > > directories build artifacts, meaning that you could delete them (or > > check > > > > out a new copy of your project that does not include them) and > restore > > > them > > > > fully with a couple of commands. > > > > > > > > Currently the two commands would have to be: cordova platform add > <all > > > your > > > > platforms> and cordova plugin add <all your plugins>. The latter is > > > > unfortunately long, and we hope to fix that by allowing you to > specify > > > > required plugins for the project in the top-level app config.xml > file, > > so > > > > that the second command becomes simply "cordova plugin add" or > "cordova > > > > plugin add --deps" or whatever we decide it should be. > > > > > > > > Why I say we're talking at cross purposes is that there's nothing > about > > > any > > > > of this that stops people from checking some or all of the > ./platforms > > > > directory into their source control. They'll have to spend some > effort > > > > maintaining it, as Cordova updates various files, but that's the case > > if > > > > you have custom edits to the native code whether you put it in > version > > > > control or not. > > > > > > > > I mention the 99% of Cordova users because at some point it becomes > > > > impractical to support 100% with the tool. There's always going to be > > > some > > > > esoteric use cases that will require some hand-holding to work with > the > > > > CLI. > > > > > > > > We have tried to extract most of the things that used to require > tweaks > > > to > > > > the DroidGap/CordovaActivity subclass, AppDelegate.m, etc. into > > > preferences > > > > that can be set from config files. If there are tweaks that are > needed > > by > > > > more than a few users and are not covered by preferences, then they > > > should > > > > be added as new preferences. > > > > > > > > Braden > > > > > > > > > > > > On Tue, Jan 7, 2014 at 6:14 AM, Andrey Kurdumov < > > kant2...@googlemail.com > > > > >wrote: > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Carlos Santana <csantan...@gmail.com>
