one other note both Jesse and Max have been prototyping an npm based bootstrap for distribution use case (search, package & publish) so if you have thoughts on that part: open a thread!
On Wed, Sep 19, 2012 at 6:14 PM, Brian LeRoux <b...@brian.io> wrote: > ahg, this is getting wordy without much use to anyone other than > history books. the reasons where definitely not due to communication > breakdowns mike. more technical barriers and differences of opinion on > technical choices. node. bash. ruby. python. all have been attempted. > node is easily the best and we can all agree we hate javascript the > least. > > matters not. > > *** > Back on topic. I am very glad everyone is now interested in > contributing to the CLI tooling. I'd say take Fils code for a spin by > installing it here: > > `npm install -g cordova` > > And then open specific threads here about the specific things we need > to do or think about! > > > > On Wed, Sep 19, 2012 at 5:55 PM, Mike Reinstein > <reinstein.m...@gmail.com> wrote: >> Responding to Michal: >> >>>So you cannot programmatically install plugins yet? >> You definitely can install plugins, with the following caveats: The plugins >> that are out in the wild are just that, wild. Andrew has "tamed" 2 of them: >> the childbrowser and pgsqlite. but all bets are off on the others. There >> are repos all over github with the plugins in various states. They depend >> on different versions of cordova. Cordova only started shipping the cli >> tools with 2.0, so if you want to use plugins with that you'll have to >> upgrade old plugins to get support. There's also no unification across >> platforms ( for example ChildBrowser has different repos for ios, android, >> etc.) >> >> >>> So you just download 3rd party plugins manually then? >> Depends on what you mean by manually. If you are comparing to npm install >> <blah> yes it's manual. you have to get the plugin, put it somewhere, and >> call cordova plugin add <args here...> But the tool cordova tool does work, >> for some use cases. >> >>> perhaps we need a "core working group" and someone to >>> drive the overall communication? >> That would be wonderful, though I'm not familiar with how this works. I'm >> happy to volunteer to do this, but I dont want to step on anybody's toes or >> take away power from other people. >> >>> So what are the short term technical tasks that we >>> can assist with? I think Braden is interested in contributing here. >> >> Honestly I think the first thing is, start researching the state of things. >> What we really need is to consolidate, organize, and plan. Like I said >> communication is the biggest problem. Adding more repos with changes for me >> to track is going to give me an ulcer, haha. I mean even referring to my >> own stuff, I've got repos where I've made changes that I *think* are >> valuable, but really at this point all I've done is make the problem worse; >> I've added more repos to track that some other poor soul should follow if >> she/he wanted to keep up with all the happenings of the plugin >> contributors. I'm committed to making this better and seeing this through >> but we need more planning and coordination, not more loose code snippets. >> I'll follow up with a stab at an agenda in an email shortly. >> >> Responding to Brian: >>> . MANY others have been involved..probably better to >>> just leave it at that >> >> I've tried to be as inclusive as possible. I can't possibly know the entire >> genesis of the project. I am not marginalizing or trivializing anyone's >> contributions; We are all standing on the shoulders of giants. That being >> said, I do think it's valuable for a newcomer to provide a practical >> overview of who's been contributing in the last few months, and where their >> work is. That's why I've referenced specific github names in my last email. >> I'm not trying to leave anyone out, you guys/gals rock! >> >>> use the mailing list to communicate or it did not happen >> Agreed, and that's we will continue to do. >> >> >>> pls use apache git to collaborate in the open, private forks >>> that aggregate everything have failed many times in the past >> I'm a bit confused on this one. The forks that are on github are currently >> public. Mine are too. Regarding failing of past aggregation attempts, I am >> going out on a limb and saying they probably failed for communication >> reasons, people couldn't get mental buy-in on their ideas, consolidate, or >> coordinate. Again I'm saying this without the vast history of >> cordova/phonegap/callback's anthropology but in all the other dev projects >> I've worked on this tends to be the cause of aggregation failure; people >> problems not container issues. >> >> >> On Wed, Sep 19, 2012 at 11:31 AM, Brian LeRoux <b...@brian.io> wrote: >> >>> eh MikeR couple of feedback points: >>> >>> 1. MANY others have been involved..probably better to just leave it at >>> that or ppl might feel bummed. probably every single adobe committer. >>> 2. use the mailing list to communicate or it did not happen (as they >>> say around these apache parts) >>> 3. pls use apache git to collaborate in the open, private forks that >>> aggregate everything have failed many times in the past (cordova >>> namesake project comes to mind) >>> >>> don't be discouraged by fragmented and distributed development. its >>> what we do best. ;) >>> >>> and finally, thank you getting this together into the semblance of >>> sanity in a single email >>> >>> >>> On Wed, Sep 19, 2012 at 5:16 PM, Mike Reinstein >>> <reinstein.m...@gmail.com> wrote: >>> >> Still, I would also appreciate a formal update >>> > >>> > I'm not sure how to make this formal, but let me outline what I've >>> learned >>> > so far. I'm very new to the cordova dev community so if I muck up part of >>> > this, someone chime and correct me. :) >>> > >>> > This may get kind of long but I think it will give a high level overview >>> of >>> > the state of things, who's involved, what we're working on, etc. One >>> thing >>> > to note: as it's been pointed out there are a lot of people working on >>> > this, and it's become a bit fragmented. As a result there's a metric ton >>> of >>> > links that I could point you at but I wont because you'd tear your hair >>> out >>> > trying to follow them all, so I'll give you a straight up history. If you >>> > have more questions follow up and I'll point you at the right places. >>> > >>> > Andrew Lunny seems to have started most of this work. He's developed a >>> > plugin specification, a 1st attempt at defining a package format that >>> > plugins will adhere to. It's essentially a directory organized in a >>> certain >>> > way, containing a plugin.xml with the bulk of the setup directives. >>> Andrew >>> > also created a tool called *pluginstall* that supports this plugin format >>> > and supports adding plugins on android and ios. He created this because >>> > he's primarily responsible for phonegap build at his day job, the web >>> > service that allow people to upload an archive and have it build >>> remotely, >>> > without requiring the hassle of local dev environments being set up. >>> > >>> > So pluginstall has been pulled into cordova command line tools as a low >>> > level dependency. When the cordova cli does plugin related stuff, it >>> calls >>> > this tool in the background to handle adding plugins. >>> > >>> > Here is where it gets complicated. :) Andrew built pluginstall, and it >>> > primarily exists to support phonegap build. He has no problem with it >>> being >>> > used for cordova as part of our toolsuite, but because his primary >>> concern >>> > is building/maintaining the pg build site that takes priority. Currently >>> > he's also just getting back from vacay, and won't be working on >>> pluginsall >>> > or it's spec for a few weeks because he's also got an upcoming release of >>> > phonegap build that takes priority. There are a number of things that >>> need >>> > to be changed in order to build out a more robust cli toolset on our >>> side. >>> > Just off the top of my head: >>> > * support for platforms besides ios and android >>> > * support for OSes besides Mac OS X (the cli tools only run on mac for >>> now) >>> > * better/more tests >>> > * someday we will probably want to have a repo so people can >>> > programmatically install plugins similar to npm >>> > >>> > Those are just the high level tasks, as you can imagine the devil is in >>> the >>> > details and there are 7.8 trillion sub tasks. >>> > >>> > What I've found to be most challenging though, is the dev environment and >>> > fragmentation. There are 4-6 people involved in the development of this >>> > tool, with people working in different directions though with a shared >>> > goal. My first several weeks on this team have largely been playing >>> > detective, interrogating everyone that seems to have some involvement in >>> > the plugin feature, looking at docs, and discovering what repos have what >>> > changes, and the *WHY *behind them. I have like 16 repos on github that >>> I'm >>> > trying to keep track of that are very similar but differnet. I'm willling >>> > to bet even as I'm writing this other people have chimed in on the plugin >>> > topic in this dev thread. :) >>> > >>> > So that being said, I'm not picking on anyone, we're making good >>> progress. >>> > But it's definitely frustrating how fragmented and unorganized the work >>> for >>> > it is. What I'm trying to consolidate the code everyone is working on >>> into >>> > one repo. I'm tracking the work of @imhotep, @wildabeast, @alunny, >>> @filmaj >>> > on github, and trying to pull their work into my codebase (while taming >>> the >>> > frankenstein aspects of bolting together contributions from 5 people.) >>> My >>> > hope is that in the next week or so, my code will provide everyone's >>> > contributions in one place, while at the same time trying to get more >>> > coordination on how we work and what we're doing so we're not trampling >>> > each other. That's my goal anyway. : / >>> > >>> > Anyway, I hope this has been helpful. The biggest challenge is getting >>> more >>> > organized and not repeating ourselves. I've found from other projects >>> that >>> > communication tends to be the biggest stumbling block, not the work >>> itself. >>> > And that experience was with day job, paid full time developers. In this >>> > open source situation it's like 3X more disconnected. :) >>> > >>> > -Mike >>> > >>> > >>> > >>> > On Wed, Sep 19, 2012 at 10:50 AM, Brian LeRoux <b...@brian.io> wrote: >>> > >>> >> you can also give `npm install -g cordova` a go to see where its at >>> >> >>> >> definitely alpha but super promising. =) >>> >> >>> >> >>> >> On Wed, Sep 19, 2012 at 4:27 PM, Michal Mocny <mmo...@chromium.org> >>> wrote: >>> >> > Take a look at the "plugin tooling/specification" thread, and Mike >>> >> > Reinstein has been digging around here lately. >>> >> > >>> >> > I think also they may have had an irc chat recently on this topic, >>> >> perhaps >>> >> > they can report if there were any interesting conclusions. >>> >> > >>> >> > Still, I would also appreciate a formal update to see how we can all >>> help >>> >> > out. >>> >> > >>> >> > -Michal >>> >> > >>> >> > >>> >> > On Wed, Sep 19, 2012 at 10:20 AM, Braden Shepherdson < >>> >> bra...@chromium.org>wrote: >>> >> > >>> >> >> I'm wondering about the state of the command-line tools for Cordova. >>> >> >> >>> >> >> Are the current plans and progress so far documented anywhere? If >>> not, >>> >> >> could someone give an update here? >>> >> >> >>> >> >> I'm interested in helping out with that effort, but it's hard to know >>> >> where >>> >> >> to start. I understand it had fragmented into several different >>> >> >> repositories but that someone was working on consolidating it again. >>> >> >> >>> >> >> Any information would be welcome. >>> >> >> >>> >> >> Braden >>> >> >> >>> >> >>>
