To plugman or not to plugman, that is the question. Or
Different styles of plugin management. John M. Wargo > On Oct 18, 2013, at 3:03 PM, "Steven Gill" <stevengil...@gmail.com> wrote: > > I think SinplePlatform vs MultiPlatform is misleading because you can use > the CLI to do single platform development. > > >> On Fri, Oct 18, 2013 at 11:51 AM, Jesse <purplecabb...@gmail.com> wrote: >> >> SinglePlatform vs MultiPlatform makes the most sense to me. >> >> SinglePlatform = Focus on a single platform, and use plugman and the >> platform scripts directly. Useful when you only have that particular device >> to test on, or only have access to that device's marketplace. Also useful >> for platform developers who are focused primarily on the native code. >> ( aka DivideAndConquer ) >> >> MultiPlatform = Build your app for a bunch of platforms at the same time. >> Great for when you know you are targeting multiple stores/devices. >> ( aka DucksInARow or MagicBullet ) >> >> I tend to lean towards the SinglePlatform, so maybe someone else could >> enumerate more Multi benefits. >> >> >> @purplecabbage >> risingj.com >> >> >> On Fri, Oct 18, 2013 at 11:28 AM, Steven Gill <stevengil...@gmail.com >>> wrote: >> >>> John: If you decided to take a stab a blogging about it, please think >> about >>> blogging on the cordova site! We can all review it before publishing it >>> too! >>> >>> Erik: that video was awesome! Let me know when Gorkem does a release and >> I >>> can post it on the cordova twitter feed. >>> >>> Michal: Could just be CLI vs Plugman workflow >>> >>> >>> On Fri, Oct 18, 2013 at 10:21 AM, Michal Mocny <mmo...@chromium.org> >>> wrote: >>> >>>> I wonder if we should not work out better names for the two workflows. >>>> Both are kinda command-line-based so saying "CLI" vs "old" is >> confusing. >>>> As is saying "the bin/ script flow" confusing. Not sure if "multi" vs >>>> "single" platform flow is any better, since you can use both flows for >>> one >>>> or more platforms. >>>> >>>> Anyway, if we have more obvious/catchy names, then we can be more clear >>> in >>>> our communications which flow our answers are relevant to. i.e., "use >>>> plugman to ... (only for ___ flow)". i.e., "Be carefully when editing >> in >>>> IDE ... (only for ___ flow)". >>>> >>>> -Michal >>>> >>>> >>>>> On Fri, Oct 18, 2013 at 1:14 PM, Anis KADRI <anis.ka...@gmail.com> >>>> wrote: >>>> >>>>> Erik that's great! Where can we download it? >>>>> On Oct 18, 2013 8:01 AM, "Andrew Grieve" <agri...@chromium.org> >> wrote: >>>>> >>>>>> Awesome video!! >>>>>> >>>>>> >>>>>> On Fri, Oct 18, 2013 at 3:43 AM, Erik Jan de Wit < >> ede...@redhat.com> >>>>>> wrote: >>>>>> >>>>>>> On the topic of IDE support my collage Gorkem has made a nice >>> wizard >>>> in >>>>>>> eclipse that mimics the CLI have a look at this video >>>>>>> >>>>>>> http://www.youtube.com/watch?v=QUyUUtmTYok >>>>>>> >>>>>>>> On 18 Oct,2013, at 4:29 , Maxime LUCE <max...@somatic.fr> wrote: >>>>>>>> >>>>>>>> Great Bryan >>>>>>>> Totally agree !!! >>>>>>>> >>>>>>>> Cordialement. >>>>>>>> ------------------------------- >>>>>>>> Maxime LUCE - Somatic >>>>>>>> maxime.l...@somatic.fr >>>>>>>> 06 28 60 72 34 >>>>>>>> ________________________________ >>>>>>>> De : Brian LeRoux<mailto:b...@brian.io> >>>>>>>> Envoyé : 18/10/2013 01:48 >>>>>>>> À : dev@cordova.apache.org<mailto:dev@cordova.apache.org> >>>>>>>> Objet : Re: config.xml discussion, we need to talk >>>>>>>> >>>>>>>> I don't really appreciate comments that we don't talk to our >>> users, >>>>> or >>>>>>> build apps in anger. Neither of those assertions are true. The >>>> origins >>>>> of >>>>>>> these initiatives are based on both community feedback, and >> direct >>>>>>> experience. >>>>>>>> >>>>>>>> Keeping your focus on just pure platform side of a project is >>> fine, >>>>> of >>>>>>> course, since the CLI delegates to the platform. This was also a >>>>>> deliberate >>>>>>> learning from MANY attempts at an architecture that satisfies >> both >>>>>>> approaches. It separates the concerns and respects the platform >>> will >>>> be >>>>>>> canonical for the common workflows supported. This is a very real >>>>> example >>>>>>> of Conway's Law btw. [1] >>>>>>>> >>>>>>>> Anyhow. Deep breath! Software has bugs, people will report >> them, >>>> and >>>>>>> we'll continue to improve. This is a very large group with a very >>>>> diverse >>>>>>> community that spans regular old hackers to the humble web >>> designers. >>>>> We >>>>>>> need to respect that, and maybe be a little more compassionate to >>>> each >>>>>>> other too. All software is fucked up, and at the end of the day, >> it >>>> is >>>>>> our >>>>>>> perpetual job to make it a little less fucked up. >>>>>>>> >>>>>>>> [1] http://en.wikipedia.org/wiki/Conway's_law >>>>>>>> >>>>>>>> >>>>>>>> [Inline image 1] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Oct 17, 2013 at 1:16 PM, Tommy Williams < >>>> to...@devgeeks.org >>>>>>> <mailto:to...@devgeeks.org>> wrote: >>>>>>>> Late to the party due to timezone fun, but I just want to chime >>> in >>>> in >>>>>>>> support of the CLI. >>>>>>>> >>>>>>>> As a dev working on an actual nontrivial "real world" app, I >>> would >>>>> like >>>>>>> to >>>>>>>> let it be known that we (SpiderOak) have been heavy drinkers of >>> the >>>>> CLI >>>>>>>> Kool-Aid since its infancy. >>>>>>>> >>>>>>>> We have even managed to get to the point where ./platforms/**/* >>> is >>>>>> just a >>>>>>>> build artefact (mostly by using hooks and tying the whole thing >>>>>> together >>>>>>>> with Grunt). >>>>>>>> >>>>>>>> We have a fast and fairly complex app (both many core plugins >> as >>>> well >>>>>>> and a >>>>>>>> few custom/third party ones), that even includes the ability to >>>> white >>>>>>> label >>>>>>>> it with relative ease. >>>>>>>> >>>>>>>> I feel pretty strongly in favour of the CLI and strongly >> advocate >>>> its >>>>>> use >>>>>>>> when asked in the #phonegap IRC channel. >>>>>>>> >>>>>>>> Just my opinion, but thought it was important to add to the >>>>> discussion. >>>>>>>> >>>>>>>> - tommy / devgeeks >>>>>>>> On 18 Oct 2013 04:44, "Anis KADRI" <anis.ka...@gmail.com >> <mailto: >>>>>>> anis.ka...@gmail.com>> wrote: >>>>>>>> >>>>>>>>> Sweet. So I think we all agree (expect Joe perhaps?) that both >>>>>>>>> approaches should be supported :-) >>>>>>>>> >>>>>>>>> On Thu, Oct 17, 2013 at 10:31 AM, Carlos Santana < >>>>>> csantan...@gmail.com >>>>>>> <mailto:csantan...@gmail.com>> >>>>>>>>> wrote: >>>>>>>>>> I meant in addition of ".cordova/lib" also allow also to do >>>>> something >>>>>>>>> like >>>>>>>>>> "cordova platform add ios >>>> --path="./cordova_components/cordova-ios" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Oct 17, 2013 at 1:28 PM, Carlos Santana < >>>>>> csantan...@gmail.com >>>>>>> <mailto:csantan...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> ++1 "to install from a given directory instead of >>>> .cordova/libs." >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Oct 17, 2013 at 12:10 PM, Viras < >>>>>> vi...@users.sourceforge.net >>>>>>> <mailto:vi...@users.sourceforge.net> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> This might be true - it took me quite some time to figure >> out >>>> how >>>>>> the >>>>>>>>> CLI >>>>>>>>>>>> actually works - despite also having to fix one or two bugs >>> for >>>>> the >>>>>>> WPX >>>>>>>>>>>> implementation of the CLI code (as well as the Windows 8 >> CLI >>>>> code). >>>>>>> But >>>>>>>>>>>> still I would hate to see the CLI go, since I think once >> you >>>> are >>>>>> used >>>>>>>>> to >>>>>>>>>>>> it, it saves you quite a lot of time (I still have those >> old >>>>>>> documents >>>>>>>>>>>> which guide me through the setup of the IDE projects for >> the >>>>>>> different >>>>>>>>>>>> platforms - which is now mostly obsolete). >>>>>>>>>>>> >>>>>>>>>>>> So I guess supporting both methods is the way to go... :) >>>>>>>>>>>> >>>>>>>>>>>> Best, >>>>>>>>>>>> Wolfgang >>>>>>>>>>>> >>>>>>>>>>>> Am 2013-10-17 16:13, schrieb Michal Mocny: >>>>>>>>>>>> >>>>>>>>>>>> Thanks so much for chiming in, I'm very happy to see that >>>> you've >>>>>>>>> figured >>>>>>>>>>>>> out how to leverage the benefits and avoid the drawbacks >> of >>>> the >>>>>> new >>>>>>>>>>>>> workflow, and that it has led to increased productivity >> for >>>> you. >>>>>>>>>>>>> >>>>>>>>>>>>> I do think that perhaps it is still too difficult for >> every >>>>>>> developer >>>>>>>>> to >>>>>>>>>>>>> learn what you already have. >>>>>>>>>>>>> >>>>>>>>>>>>> -Michal >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Oct 17, 2013 at 12:13 AM, Viras < >>>>>>> vi...@users.sourceforge.net<mailto:vi...@users.sourceforge.net>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> my view on this discussion: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've used the CLI to release the latest version of GOFG >>>> Sports >>>>>>>>> Computer >>>>>>>>>>>>>> for Windows Phone. The support for the "merges" directory >>> is >>>> a >>>>>>>>> fantastic >>>>>>>>>>>>>> feature which allows me to focus on the javascript code >>> using >>>>>> e.g. >>>>>>>>> the >>>>>>>>>>>>>> NetBeans IDE - I can finally handle all my platform >>> specific >>>>> code >>>>>>>>> from >>>>>>>>>>>>>> JavaScript in one consistent directory structure - which >> is >>>>> what >>>>>>>>> Cordova >>>>>>>>>>>>>> should be about. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In addition the CLI forces you to write clean code (not >>>>> implying >>>>>>> that >>>>>>>>>>>>>> the >>>>>>>>>>>>>> other method forces to write messy code). If you need >>>> something >>>>>>>>> native >>>>>>>>>>>>>> write a clean plugin for it (which also makes the code >>>>> reusable) >>>>>> - >>>>>>> no >>>>>>>>>>>>>> need >>>>>>>>>>>>>> to mess around in the native projects code - this also >>> makes >>>>>>>>> upgrading >>>>>>>>>>>>>> cordova much easier. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Once I've done the Windows Phone version I've simply >> added >>>>>> Android >>>>>>>>> as a >>>>>>>>>>>>>> platform, build it and I was done - no need for fiddling >>>> around >>>>>>> with >>>>>>>>>>>>>> SDK / >>>>>>>>>>>>>> IDE setup etc (besides actually installing it). So CLI is >>> my >>>>>>> favorite >>>>>>>>>>>>>> way >>>>>>>>>>>>>> to develop now - and it is far more powerful than the old >>>>>> approach >>>>>>>>> (in >>>>>>>>>>>>>> my >>>>>>>>>>>>>> opinion) - since it saves you from fiddling around with >>>> project >>>>>>>>>>>>>> settings, >>>>>>>>>>>>>> etc. when you do a multi-platform release. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Oh yes - and GOFG SC uses two custom plugins, 5 official >>>>> plugins >>>>>>> and >>>>>>>>>>>>>> cordova 3.0 - so it is a bit beyond the "Hello World" >>>>>>> application.... >>>>>>>>>>>>>> >>>>>>>>>>>>>> And I do not agree that it isn't possible to work with >> the >>>>> native >>>>>>>>> IDEs >>>>>>>>>>>>>> with their own projects - this is simply wrong since you >>> can >>>>>> always >>>>>>>>> go >>>>>>>>>>>>>> to >>>>>>>>>>>>>> the "platforms" directory and open the platform-projects >>>> using >>>>>>> their >>>>>>>>>>>>>> native >>>>>>>>>>>>>> IDE from there (I've done this myself for e.g. plugin >>>>>> development). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Still I agree that both versions should be supported - >> but >>>>> don't >>>>>>> make >>>>>>>>>>>>>> the >>>>>>>>>>>>>> assumption that the CLI is for "n00bs" only! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best, >>>>>>>>>>>>>> Wolfgang >>>>>>>>>>>>>> >>>>>>>>>>>>>> Am 2013-10-16 23:11, schrieb Joe Bowser: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Oct 16, 2013 at 1:37 PM, Michal Mocny < >>>>>> mmo...@chromium.org >>>>>>> <mailto:mmo...@chromium.org>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Anis: Totally agrees, but its important to highlight >> that >>>> both >>>>>>>>>>>>>>>> directions >>>>>>>>>>>>>>>> for that arguments hold. We've done our best to >> support >>>> bin/ >>>>>>>>> scripts >>>>>>>>>>>>>>>> post >>>>>>>>>>>>>>>> 3.0, yet blanket statements like "CLI should not be >> used >>>> with >>>>>>>>> IDE", or >>>>>>>>>>>>>>>> "CLI >>>>>>>>>>>>>>>> sucks unless you just doing something trivial" are >> being >>>>> thrown >>>>>>>>>>>>>>>> around, >>>>>>>>>>>>>>>> which are harmful in my opinion, and I don't think its >>> fair >>>>>> that >>>>>>>>> some >>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>> us >>>>>>>>>>>>>>>> are promoting that message to users. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I don't think we're communicating with our users at >> all, >>>> so I >>>>>>>>> don't >>>>>>>>>>>>>>> see how this could be communicated. When users >>> communicate >>>>>> their >>>>>>>>>>>>>>> frustrations, it's usually something like this >>>>>>>>>>>>>>> ( >>> http://www.infil00p.org/****config-xml-changes-for-ios-**< >>>>>>>>> http://www.infil00p.org/**config-xml-changes-for-ios-**> >>>>>>>>>>>>>>> and-android/#comment-10731<htt**p:// >>>>> www.infil00p.org/config-**< >>>>>>> http://www.infil00p.org/config-**> >>>>>>>>>>>>>>> xml-changes-for-ios-and-**android/#comment-10731< >> http://www.infil00p.org/config-xml-changes-for-ios-and-android/#comment-10731 >>>>>>>>>> >>>>>>>>>>>>>>> ) >>>>>>>>>>>>>>> and this >>>>>>>>>>>>>>> ( >>>>> http://www.infil00p.org/****introducing-cordova-3-0-0-for-**** >>>>>> < >>>>>>>>> http://www.infil00p.org/**introducing-cordova-3-0-0-for-**> >>>>>>>>>>>>>>> android/#comment-10694<http://** >>>>> www.infil00p.org/introducing-** >>>>>> < >>>>>>> http://www.infil00p.org/introducing-**> >>>>>>>>>>>>>>> cordova-3-0-0-for-android/#**comment-10694< >> http://www.infil00p.org/introducing-cordova-3-0-0-for-android/#comment-10694 >>>>>>>>>> >>>>>>>>>>>>>>> ). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> CLI works well for me, and while its not perfect, I >> strive >>>> to >>>>>>> learn >>>>>>>>>>>>>>> its >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> limitations and make it better, not condemn it. >>>>>>>>>>>>>>> I avoid it because it's not developed for me, or >>> developers >>>>> like >>>>>>> me >>>>>>>>>>>>>>> who like to see a big pile of output when things fail. >> I >>>>>> avoided >>>>>>>>>>>>>>> having any part in its development because I thought it >>> was >>>>> the >>>>>>>>> wrong >>>>>>>>>>>>>>> way to do things. I assumed that the majority of users >>>>> actually >>>>>>>>>>>>>>> wanted this and that I should do my best to work around >>>> this, >>>>>> but >>>>>>>>> with >>>>>>>>>>>>>>> the backlash that we're getting, such as the blog posts >>> and >>>>> some >>>>>>>>>>>>>>> comments on the Google Groups, it seems that this is a >>>> feature >>>>>>> very >>>>>>>>>>>>>>> few people actually wanted. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As far as the CordovaWebView use case, I actually have >>> never >>>>>> tried >>>>>>>>>>>>>>> that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Has anyone bothered to make sure it works well >> post-3.0, >>> or >>>>>> does >>>>>>>>> Joe >>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>> a point that we missed addressing this? >>>>>>>>>>>>>>> We have JUnit unit tests in the Android repository to >> make >>>>> sure >>>>>>> that >>>>>>>>>>>>>>> this still works. However, I would like to see this >> test >>>> case >>>>>>>>>>>>>>> revisited since it may be more appropriate to have >>>>>> CordovaActivity >>>>>>>>> be >>>>>>>>>>>>>>> inherited instead of CordovaInterface, or for both to be >>>>>>> supported. >>>>>>>>>>>>>>> This is so that we can make more hybrid applications and >>>> deal >>>>>> with >>>>>>>>> the >>>>>>>>>>>>>>> fact that we're so brutally non-complaint with Android >> UI >>>>>>> guidelines >>>>>>>>>>>>>>> instead of just ignoring it. I'll probably bring this >> up >>>> and >>>>>>>>> present >>>>>>>>>>>>>>> more source code when it's ready to explain why we need >>> this >>>>>>> feature >>>>>>>>>>>>>>> in the next couple of weeks, and why it's important to >>>> respect >>>>>> the >>>>>>>>>>>>>>> platform, even when the platform doesn't respect the >> web. >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> GOFG - Get On Fat Guy >>>>>>>>>>>>>> http://www.gofg.at/ - powered by Cordova >>>>>>>>>>>> -- >>>>>>>>>>>> GOFG - Get On Fat Guy >>>>>>>>>>>> http://www.gofg.at/ - powered by Cordova >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Carlos Santana >>>>>>>>>>> <csantan...@gmail.com<mailto:csantan...@gmail.com>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Carlos Santana >>>>>>>>>> <csantan...@gmail.com<mailto:csantan...@gmail.com>> >>
