State of command-line tools

[Braden Shepherdson <br...@chromium.org>]

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

Re: State of command-line tools

[Michal Mocny <mm...@chromium.org>]

On Wed, Sep 19, 2012 at 11:16 AM, Mike Reinstein
<re...@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.
>

This is great, thanks!


>
> 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
>

So you cannot programmatically install plugins yet?  Just platforms
(cordova platform add android seems to work) I take it..  So you just
download 3rd party plugins manually then?


>
> 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. :)
>

Yes, we've all been enjoying the fruits of your labour here.  Thanks so
much for your efforts, they've not gone unnoticed.

Still, we should strive to make this less painless going forward, and since
this seems like a task for more than one person, perhaps we need a "core
working group" and someone to drive the overall communication?


>
> 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. : /
>

+1


>
> 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. :)
>

I think this is just a problem of "when everyone is responsible, no one
is".  Thanks for volunteering!


>
> -Mike
>

So what are the short term technical tasks that we can assist with?  I
think Braden is interested in contributing here.  Is porting to
linux/windows a first priority?  Setting up an npm repository of plugins?
 Code cleanup, testing, etc?


>
>
>
> 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 <mm...@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
> > >>
> >
>

Re: State of command-line tools

[Michal Mocny <mm...@chromium.org>]

Actually, I'm starting a new thread, lets not hijack this one on this topic.


On Wed, Sep 19, 2012 at 11:37 AM, Michal Mocny <mm...@chromium.org> wrote:

> Regarding Mailing List communication
>
> I've just used an IRC bot for logging purposes where the transcripts are
> either posted to the ML or just saved online.   Would an option like that
> work?
>
> -Michal
>
>
> 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
>> <re...@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 <mm...@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
>> >> >>
>> >>
>>
>
>

Re: State of command-line tools

[Michal Mocny <mm...@chromium.org>]

Regarding Mailing List communication

I've just used an IRC bot for logging purposes where the transcripts are
either posted to the ML or just saved online.   Would an option like that
work?

-Michal


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
> <re...@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 <mm...@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
> >> >>
> >>
>

Re: State of command-line tools

[Filip Maj <fi...@adobe.com>]

Yep, if people want to pick up specific tasks just post away on the
specific issues on github!

On 9/19/12 1:58 PM, "Michal Mocny" <mm...@chromium.org> wrote:

>Fantastic summary Fil, we will look to the issue list and help out with
>what we can.  Thanks!
>
>
>On Wed, Sep 19, 2012 at 1:49 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> I'll try to keep this short. Understand it is hard to keep up with all
>>of
>> the different projects involved but I think they exist for good reason.
>>
>> I have been pushing code for the cordova-client aggregate CLI tooling to
>> the cordova-labs repo, under the cordova-client branch [1]. I'm
>>mirroring
>> all commits to my fork on GitHub [2]. I am using the simple issues list
>>on
>> GitHub (sorry JIRA) to track outstanding tasks [3].
>>
>> Cordova-client depends on pluginstall, which lives in GitHub [4].
>> Pluginstall depends on node-xcode [5], which also lives in GitHub.
>>
>> Anis is currently working on adding plugin uninstallation. He is doing
>> this on his _fork_ of pluginstall [6], which in terms depends on his
>> _fork_ of node-xcode [7].
>>
>> I am working on having the user-facing config.xml file as the entry
>>point
>> for defining app metadata. So things like app names and package names
>>get
>> picked up from the config.xml and the right native bits get updated in
>>the
>> native projects every time you run the tools.
>>
>> The fact this is on GitHub is only for convenience. Eventually it will
>> make its way into a "proper" Apache repository. If anyone would like to
>> help out, I would check out the issues list on GitHub [3]. If this is a
>> problem I can move everything to JIRA. That said, pluginstall +
>>node-xcode
>> are stand-alone tools at this point and MIT licensed, so I think it is
>>OK
>> if we keep those on GitHub *for now*.
>>
>> Once this code is ready to move out of labs, we can then figure out what
>> code should live where.
>>
>> [1]
>> 
>>https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-labs.git;a=sh
>>or
>> tlog;h=refs/heads/cordova-client
>> [2] https://github.com/filmaj/cordova-client
>> [3] https://github.com/filmaj/cordova-client/issues
>> [4] https://github.com/alunny/pluginstall
>>
>> [5] https://github.com/alunny/node-xcode
>> [4] https://github.com/imhotep/pluginstall
>> [5] https://github.com/imhotep/node-xcode
>>
>>

Re: State of command-line tools

[Michal Mocny <mm...@chromium.org>]

Fantastic summary Fil, we will look to the issue list and help out with
what we can.  Thanks!


On Wed, Sep 19, 2012 at 1:49 PM, Filip Maj <fi...@adobe.com> wrote:

> I'll try to keep this short. Understand it is hard to keep up with all of
> the different projects involved but I think they exist for good reason.
>
> I have been pushing code for the cordova-client aggregate CLI tooling to
> the cordova-labs repo, under the cordova-client branch [1]. I'm mirroring
> all commits to my fork on GitHub [2]. I am using the simple issues list on
> GitHub (sorry JIRA) to track outstanding tasks [3].
>
> Cordova-client depends on pluginstall, which lives in GitHub [4].
> Pluginstall depends on node-xcode [5], which also lives in GitHub.
>
> Anis is currently working on adding plugin uninstallation. He is doing
> this on his _fork_ of pluginstall [6], which in terms depends on his
> _fork_ of node-xcode [7].
>
> I am working on having the user-facing config.xml file as the entry point
> for defining app metadata. So things like app names and package names get
> picked up from the config.xml and the right native bits get updated in the
> native projects every time you run the tools.
>
> The fact this is on GitHub is only for convenience. Eventually it will
> make its way into a "proper" Apache repository. If anyone would like to
> help out, I would check out the issues list on GitHub [3]. If this is a
> problem I can move everything to JIRA. That said, pluginstall + node-xcode
> are stand-alone tools at this point and MIT licensed, so I think it is OK
> if we keep those on GitHub *for now*.
>
> Once this code is ready to move out of labs, we can then figure out what
> code should live where.
>
> [1]
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-labs.git;a=shor
> tlog;h=refs/heads/cordova-client
> [2] https://github.com/filmaj/cordova-client
> [3] https://github.com/filmaj/cordova-client/issues
> [4] https://github.com/alunny/pluginstall
>
> [5] https://github.com/alunny/node-xcode
> [4] https://github.com/imhotep/pluginstall
> [5] https://github.com/imhotep/node-xcode
>
>

Re: State of command-line tools

[Filip Maj <fi...@adobe.com>]

I'll try to keep this short. Understand it is hard to keep up with all of
the different projects involved but I think they exist for good reason.

I have been pushing code for the cordova-client aggregate CLI tooling to
the cordova-labs repo, under the cordova-client branch [1]. I'm mirroring
all commits to my fork on GitHub [2]. I am using the simple issues list on
GitHub (sorry JIRA) to track outstanding tasks [3].

Cordova-client depends on pluginstall, which lives in GitHub [4].
Pluginstall depends on node-xcode [5], which also lives in GitHub.

Anis is currently working on adding plugin uninstallation. He is doing
this on his _fork_ of pluginstall [6], which in terms depends on his
_fork_ of node-xcode [7].

I am working on having the user-facing config.xml file as the entry point
for defining app metadata. So things like app names and package names get
picked up from the config.xml and the right native bits get updated in the
native projects every time you run the tools.

The fact this is on GitHub is only for convenience. Eventually it will
make its way into a "proper" Apache repository. If anyone would like to
help out, I would check out the issues list on GitHub [3]. If this is a
problem I can move everything to JIRA. That said, pluginstall + node-xcode
are stand-alone tools at this point and MIT licensed, so I think it is OK
if we keep those on GitHub *for now*.

Once this code is ready to move out of labs, we can then figure out what
code should live where.

[1] 
https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-labs.git;a=shor
tlog;h=refs/heads/cordova-client
[2] https://github.com/filmaj/cordova-client
[3] https://github.com/filmaj/cordova-client/issues
[4] https://github.com/alunny/pluginstall

[5] https://github.com/alunny/node-xcode
[4] https://github.com/imhotep/pluginstall
[5] https://github.com/imhotep/node-xcode

Re: State of command-line tools

[Brian LeRoux <b...@brian.io>]

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
> <re...@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
>>> <re...@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 <mm...@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
>>> >> >>
>>> >>
>>>

Re: State of command-line tools

[Brian LeRoux <b...@brian.io>]

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
<re...@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
>> <re...@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 <mm...@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
>> >> >>
>> >>
>>

Re: State of command-line tools

[Mike Reinstein <re...@gmail.com>]

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
> <re...@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 <mm...@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
> >> >>
> >>
>

Re: State of command-line tools

[Brian LeRoux <b...@brian.io>]

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
<re...@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 <mm...@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
>> >>
>>

Re: State of command-line tools

[Mike Reinstein <re...@gmail.com>]

> 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 <mm...@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
> >>
>

Re: State of command-line tools

[Michal Mocny <mm...@chromium.org>]

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
>

Whoa!  I was not aware we had this working, thats awesome!  Toying around
now.


>
> definitely alpha but super promising. =)
>
>
> On Wed, Sep 19, 2012 at 4:27 PM, Michal Mocny <mm...@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
> >>
>

Re: State of command-line tools

[Brian LeRoux <b...@brian.io>]

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 <mm...@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 <br...@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
>>

Re: State of command-line tools

[Michal Mocny <mm...@chromium.org>]

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 <br...@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
>