incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: State of command-line tools
Date Wed, 19 Sep 2012 16:18:40 GMT
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.mike@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.mike@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 <mmocny@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 <
>>> >> braden@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
>>> >> >>
>>> >>
>>>

Mime
View raw message