Re: What's your daily workflow for cordova development?
It could be, and there's even a plugin add --link option. BUT, there's a major caveat here: Changes to plugin.xml, native code, and possibly other parts, won't be updated on cordova prepare, but only on cordova plugin add. So you'd have to plugin rm+add on most changes anyway, so there's little advantage to linking. Braden On Mon, Sep 23, 2013 at 10:33 AM, Jamie Munro wrote: > Could a plugin that is in development be symlinked into the plugins folder > of the project it is being developed for? > > Robert (Jamie) Munro > > > On 20 September 2013 17:38, Brian LeRoux wrote: > > > Agree you will certainly arrive at the ideal solution by iterating from > the > > less-than-ideal solution. That is not a reason to not start breaking > stuff > > though. > > > > > > On Fri, Sep 20, 2013 at 5:31 PM, Michal Mocny > wrote: > > > > > Ugh, unfortunately Braden is right. Still, I think that means we can > > move > > > forward with the plan to make "plugman create" work anywhere and > "cordova > > > plugin create" only work inside of a workspace, but don't implement the > > > latter until its actually feasible to make edits to plugins inside a > > > workspace in some sane fashion. > > > > > > Not supporting cordova plugin create from a global context leaves us > open > > > to doing the right thing in the future, I think. > > > > > > -Michal > > > > > > > > > On Fri, Sep 20, 2013 at 7:53 AM, Braden Shepherdson < > bra...@chromium.org > > > >wrote: > > > > > > > I would caution against developing a plugin inside a cordova-cli > > > workspace. > > > > The nature of the install vs. prepare divide is that any changes to > > > native > > > > code require reinstalling. That's confusing for developers, so I > would > > > > recommend that the best way to develop a plugin using CLI is to > plugman > > > > create elsewhere, and then install that plugin into a CLI workspace > for > > > > testing. Then when you make a change to the plugin at its top-level > > > > location, you uninstall and reinstall it. > > > > > > > > I recognize that this flow is less than ideal, and I'd like to > improve > > it > > > > in the long term, but in the meantime it would be a bad idea to keep > a > > > > plugin's canonical location inside plugins/. > > > > > > > > Braden > > > > > > > > > > > > On Fri, Sep 20, 2013 at 10:16 AM, Lucas Holmquist < > lholm...@redhat.com > > > > >wrote: > > > > > > > > > i always forget about plugman > > > > > On Sep 20, 2013, at 9:57 AM, Michal Mocny > > wrote: > > > > > > > > > > > plugman create could be used outside of a project, and cordova > > plugin > > > > > > create should be used only inside of a project? > > > > > > > > > > > > All other cordova commands must be used inside a project (except > > the > > > > > > "create" entry point), and if we decide to ship the plugin > > templates > > > > with > > > > > > platforms, and/or decide to make the global cordova command just > a > > > > > > grunt-cli like thing, etc etc, then I would worry about adding > uses > > > for > > > > > > cordova command in some global context. > > > > > > > > > > > > > > > > > > On Fri, Sep 20, 2013 at 6:42 AM, Lucas Holmquist < > > > lholm...@redhat.com > > > > > >wrote: > > > > > > > > > > > >> So currently when doing > > > > > >> > > > > > >> $ cordova plugin …. > > > > > >> > > > > > >> it fails if you are not in a cordova project. > > > > > >> > > > > > >> but > > > > > >> > > > > > >> $ cordova plugin create > > > > > >> > > > > > >> might not be used inside a project( i think it shouldn't be used > > > > inside > > > > > a > > > > > >> project at all, but i can be convinced otherwise ) > > > > > >> > > > > > >> > > > > > >> On Sep 4, 2013, at 10:46 PM, lmnbeyond > > wrote: > > > > > >> > > > > > >>> > > > > > >>> > > > > > I also think it should sub-shell to a platform script. We > > already > > > > have > > > > > a `project template` folder in each platform. We can easily > add > > a > > > > > `plugin template` as well and write a quick create_plugin > > script. > > > > > > > > > > What do you guys think of the workflow I described above ? Any > > > > > comments ? I can create jira issues for it and tackle it. > > > > > > > > > > -a > > > > > > > > > > >>> > > > > > >>> Hi Anis, > > > > > >>> > > > > > >>> I just want to confirm whether or not this is the workflow we > are > > > > > >> talking about : > > > > > >>> > > > > > >>> For a brand new plugin: > > > > > >>> > > > > > >>> $ cordova plugin create /path/to/myPlugin > > > > > >>> $ cordova plugin add /path/to/myPlugin --watch > > > > > >>> > > > > > >>> > > > > > >>> For an existing plugin: > > > > > >>> > > > > > >>> $ cordova plugin add /path/to/corePlugin --watch > > > > > >>> > > > > > >>> > > > > > >>> Although, I'm not quite clear about the complexity behind this, > > I > > > > > think > > > > > >> the above workflow is great for me! > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>>
Re: What's your daily workflow for cordova development?
Could a plugin that is in development be symlinked into the plugins folder of the project it is being developed for? Robert (Jamie) Munro On 20 September 2013 17:38, Brian LeRoux wrote: > Agree you will certainly arrive at the ideal solution by iterating from the > less-than-ideal solution. That is not a reason to not start breaking stuff > though. > > > On Fri, Sep 20, 2013 at 5:31 PM, Michal Mocny wrote: > > > Ugh, unfortunately Braden is right. Still, I think that means we can > move > > forward with the plan to make "plugman create" work anywhere and "cordova > > plugin create" only work inside of a workspace, but don't implement the > > latter until its actually feasible to make edits to plugins inside a > > workspace in some sane fashion. > > > > Not supporting cordova plugin create from a global context leaves us open > > to doing the right thing in the future, I think. > > > > -Michal > > > > > > On Fri, Sep 20, 2013 at 7:53 AM, Braden Shepherdson > >wrote: > > > > > I would caution against developing a plugin inside a cordova-cli > > workspace. > > > The nature of the install vs. prepare divide is that any changes to > > native > > > code require reinstalling. That's confusing for developers, so I would > > > recommend that the best way to develop a plugin using CLI is to plugman > > > create elsewhere, and then install that plugin into a CLI workspace for > > > testing. Then when you make a change to the plugin at its top-level > > > location, you uninstall and reinstall it. > > > > > > I recognize that this flow is less than ideal, and I'd like to improve > it > > > in the long term, but in the meantime it would be a bad idea to keep a > > > plugin's canonical location inside plugins/. > > > > > > Braden > > > > > > > > > On Fri, Sep 20, 2013 at 10:16 AM, Lucas Holmquist > > >wrote: > > > > > > > i always forget about plugman > > > > On Sep 20, 2013, at 9:57 AM, Michal Mocny > wrote: > > > > > > > > > plugman create could be used outside of a project, and cordova > plugin > > > > > create should be used only inside of a project? > > > > > > > > > > All other cordova commands must be used inside a project (except > the > > > > > "create" entry point), and if we decide to ship the plugin > templates > > > with > > > > > platforms, and/or decide to make the global cordova command just a > > > > > grunt-cli like thing, etc etc, then I would worry about adding uses > > for > > > > > cordova command in some global context. > > > > > > > > > > > > > > > On Fri, Sep 20, 2013 at 6:42 AM, Lucas Holmquist < > > lholm...@redhat.com > > > > >wrote: > > > > > > > > > >> So currently when doing > > > > >> > > > > >> $ cordova plugin …. > > > > >> > > > > >> it fails if you are not in a cordova project. > > > > >> > > > > >> but > > > > >> > > > > >> $ cordova plugin create > > > > >> > > > > >> might not be used inside a project( i think it shouldn't be used > > > inside > > > > a > > > > >> project at all, but i can be convinced otherwise ) > > > > >> > > > > >> > > > > >> On Sep 4, 2013, at 10:46 PM, lmnbeyond > wrote: > > > > >> > > > > >>> > > > > >>> > > > > I also think it should sub-shell to a platform script. We > already > > > have > > > > a `project template` folder in each platform. We can easily add > a > > > > `plugin template` as well and write a quick create_plugin > script. > > > > > > > > What do you guys think of the workflow I described above ? Any > > > > comments ? I can create jira issues for it and tackle it. > > > > > > > > -a > > > > > > > > >>> > > > > >>> Hi Anis, > > > > >>> > > > > >>> I just want to confirm whether or not this is the workflow we are > > > > >> talking about : > > > > >>> > > > > >>> For a brand new plugin: > > > > >>> > > > > >>> $ cordova plugin create /path/to/myPlugin > > > > >>> $ cordova plugin add /path/to/myPlugin --watch > > > > >>> > > > > >>> > > > > >>> For an existing plugin: > > > > >>> > > > > >>> $ cordova plugin add /path/to/corePlugin --watch > > > > >>> > > > > >>> > > > > >>> Although, I'm not quite clear about the complexity behind this, > I > > > > think > > > > >> the above workflow is great for me! > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > >
Re: What's your daily workflow for cordova development?
Agree you will certainly arrive at the ideal solution by iterating from the less-than-ideal solution. That is not a reason to not start breaking stuff though. On Fri, Sep 20, 2013 at 5:31 PM, Michal Mocny wrote: > Ugh, unfortunately Braden is right. Still, I think that means we can move > forward with the plan to make "plugman create" work anywhere and "cordova > plugin create" only work inside of a workspace, but don't implement the > latter until its actually feasible to make edits to plugins inside a > workspace in some sane fashion. > > Not supporting cordova plugin create from a global context leaves us open > to doing the right thing in the future, I think. > > -Michal > > > On Fri, Sep 20, 2013 at 7:53 AM, Braden Shepherdson >wrote: > > > I would caution against developing a plugin inside a cordova-cli > workspace. > > The nature of the install vs. prepare divide is that any changes to > native > > code require reinstalling. That's confusing for developers, so I would > > recommend that the best way to develop a plugin using CLI is to plugman > > create elsewhere, and then install that plugin into a CLI workspace for > > testing. Then when you make a change to the plugin at its top-level > > location, you uninstall and reinstall it. > > > > I recognize that this flow is less than ideal, and I'd like to improve it > > in the long term, but in the meantime it would be a bad idea to keep a > > plugin's canonical location inside plugins/. > > > > Braden > > > > > > On Fri, Sep 20, 2013 at 10:16 AM, Lucas Holmquist > >wrote: > > > > > i always forget about plugman > > > On Sep 20, 2013, at 9:57 AM, Michal Mocny wrote: > > > > > > > plugman create could be used outside of a project, and cordova plugin > > > > create should be used only inside of a project? > > > > > > > > All other cordova commands must be used inside a project (except the > > > > "create" entry point), and if we decide to ship the plugin templates > > with > > > > platforms, and/or decide to make the global cordova command just a > > > > grunt-cli like thing, etc etc, then I would worry about adding uses > for > > > > cordova command in some global context. > > > > > > > > > > > > On Fri, Sep 20, 2013 at 6:42 AM, Lucas Holmquist < > lholm...@redhat.com > > > >wrote: > > > > > > > >> So currently when doing > > > >> > > > >> $ cordova plugin …. > > > >> > > > >> it fails if you are not in a cordova project. > > > >> > > > >> but > > > >> > > > >> $ cordova plugin create > > > >> > > > >> might not be used inside a project( i think it shouldn't be used > > inside > > > a > > > >> project at all, but i can be convinced otherwise ) > > > >> > > > >> > > > >> On Sep 4, 2013, at 10:46 PM, lmnbeyond wrote: > > > >> > > > >>> > > > >>> > > > I also think it should sub-shell to a platform script. We already > > have > > > a `project template` folder in each platform. We can easily add a > > > `plugin template` as well and write a quick create_plugin script. > > > > > > What do you guys think of the workflow I described above ? Any > > > comments ? I can create jira issues for it and tackle it. > > > > > > -a > > > > > > >>> > > > >>> Hi Anis, > > > >>> > > > >>> I just want to confirm whether or not this is the workflow we are > > > >> talking about : > > > >>> > > > >>> For a brand new plugin: > > > >>> > > > >>> $ cordova plugin create /path/to/myPlugin > > > >>> $ cordova plugin add /path/to/myPlugin --watch > > > >>> > > > >>> > > > >>> For an existing plugin: > > > >>> > > > >>> $ cordova plugin add /path/to/corePlugin --watch > > > >>> > > > >>> > > > >>> Although, I'm not quite clear about the complexity behind this, I > > > think > > > >> the above workflow is great for me! > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >> > > > >> > > > > > > > > >
Re: What's your daily workflow for cordova development?
Ugh, unfortunately Braden is right. Still, I think that means we can move forward with the plan to make "plugman create" work anywhere and "cordova plugin create" only work inside of a workspace, but don't implement the latter until its actually feasible to make edits to plugins inside a workspace in some sane fashion. Not supporting cordova plugin create from a global context leaves us open to doing the right thing in the future, I think. -Michal On Fri, Sep 20, 2013 at 7:53 AM, Braden Shepherdson wrote: > I would caution against developing a plugin inside a cordova-cli workspace. > The nature of the install vs. prepare divide is that any changes to native > code require reinstalling. That's confusing for developers, so I would > recommend that the best way to develop a plugin using CLI is to plugman > create elsewhere, and then install that plugin into a CLI workspace for > testing. Then when you make a change to the plugin at its top-level > location, you uninstall and reinstall it. > > I recognize that this flow is less than ideal, and I'd like to improve it > in the long term, but in the meantime it would be a bad idea to keep a > plugin's canonical location inside plugins/. > > Braden > > > On Fri, Sep 20, 2013 at 10:16 AM, Lucas Holmquist >wrote: > > > i always forget about plugman > > On Sep 20, 2013, at 9:57 AM, Michal Mocny wrote: > > > > > plugman create could be used outside of a project, and cordova plugin > > > create should be used only inside of a project? > > > > > > All other cordova commands must be used inside a project (except the > > > "create" entry point), and if we decide to ship the plugin templates > with > > > platforms, and/or decide to make the global cordova command just a > > > grunt-cli like thing, etc etc, then I would worry about adding uses for > > > cordova command in some global context. > > > > > > > > > On Fri, Sep 20, 2013 at 6:42 AM, Lucas Holmquist > >wrote: > > > > > >> So currently when doing > > >> > > >> $ cordova plugin …. > > >> > > >> it fails if you are not in a cordova project. > > >> > > >> but > > >> > > >> $ cordova plugin create > > >> > > >> might not be used inside a project( i think it shouldn't be used > inside > > a > > >> project at all, but i can be convinced otherwise ) > > >> > > >> > > >> On Sep 4, 2013, at 10:46 PM, lmnbeyond wrote: > > >> > > >>> > > >>> > > I also think it should sub-shell to a platform script. We already > have > > a `project template` folder in each platform. We can easily add a > > `plugin template` as well and write a quick create_plugin script. > > > > What do you guys think of the workflow I described above ? Any > > comments ? I can create jira issues for it and tackle it. > > > > -a > > > > >>> > > >>> Hi Anis, > > >>> > > >>> I just want to confirm whether or not this is the workflow we are > > >> talking about : > > >>> > > >>> For a brand new plugin: > > >>> > > >>> $ cordova plugin create /path/to/myPlugin > > >>> $ cordova plugin add /path/to/myPlugin --watch > > >>> > > >>> > > >>> For an existing plugin: > > >>> > > >>> $ cordova plugin add /path/to/corePlugin --watch > > >>> > > >>> > > >>> Although, I'm not quite clear about the complexity behind this, I > > think > > >> the above workflow is great for me! > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > > > >
Re: What's your daily workflow for cordova development?
I would caution against developing a plugin inside a cordova-cli workspace. The nature of the install vs. prepare divide is that any changes to native code require reinstalling. That's confusing for developers, so I would recommend that the best way to develop a plugin using CLI is to plugman create elsewhere, and then install that plugin into a CLI workspace for testing. Then when you make a change to the plugin at its top-level location, you uninstall and reinstall it. I recognize that this flow is less than ideal, and I'd like to improve it in the long term, but in the meantime it would be a bad idea to keep a plugin's canonical location inside plugins/. Braden On Fri, Sep 20, 2013 at 10:16 AM, Lucas Holmquist wrote: > i always forget about plugman > On Sep 20, 2013, at 9:57 AM, Michal Mocny wrote: > > > plugman create could be used outside of a project, and cordova plugin > > create should be used only inside of a project? > > > > All other cordova commands must be used inside a project (except the > > "create" entry point), and if we decide to ship the plugin templates with > > platforms, and/or decide to make the global cordova command just a > > grunt-cli like thing, etc etc, then I would worry about adding uses for > > cordova command in some global context. > > > > > > On Fri, Sep 20, 2013 at 6:42 AM, Lucas Holmquist >wrote: > > > >> So currently when doing > >> > >> $ cordova plugin …. > >> > >> it fails if you are not in a cordova project. > >> > >> but > >> > >> $ cordova plugin create > >> > >> might not be used inside a project( i think it shouldn't be used inside > a > >> project at all, but i can be convinced otherwise ) > >> > >> > >> On Sep 4, 2013, at 10:46 PM, lmnbeyond wrote: > >> > >>> > >>> > I also think it should sub-shell to a platform script. We already have > a `project template` folder in each platform. We can easily add a > `plugin template` as well and write a quick create_plugin script. > > What do you guys think of the workflow I described above ? Any > comments ? I can create jira issues for it and tackle it. > > -a > > >>> > >>> Hi Anis, > >>> > >>> I just want to confirm whether or not this is the workflow we are > >> talking about : > >>> > >>> For a brand new plugin: > >>> > >>> $ cordova plugin create /path/to/myPlugin > >>> $ cordova plugin add /path/to/myPlugin --watch > >>> > >>> > >>> For an existing plugin: > >>> > >>> $ cordova plugin add /path/to/corePlugin --watch > >>> > >>> > >>> Although, I'm not quite clear about the complexity behind this, I > think > >> the above workflow is great for me! > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >
Re: What's your daily workflow for cordova development?
i always forget about plugman On Sep 20, 2013, at 9:57 AM, Michal Mocny wrote: > plugman create could be used outside of a project, and cordova plugin > create should be used only inside of a project? > > All other cordova commands must be used inside a project (except the > "create" entry point), and if we decide to ship the plugin templates with > platforms, and/or decide to make the global cordova command just a > grunt-cli like thing, etc etc, then I would worry about adding uses for > cordova command in some global context. > > > On Fri, Sep 20, 2013 at 6:42 AM, Lucas Holmquist wrote: > >> So currently when doing >> >> $ cordova plugin …. >> >> it fails if you are not in a cordova project. >> >> but >> >> $ cordova plugin create >> >> might not be used inside a project( i think it shouldn't be used inside a >> project at all, but i can be convinced otherwise ) >> >> >> On Sep 4, 2013, at 10:46 PM, lmnbeyond wrote: >> >>> >>> I also think it should sub-shell to a platform script. We already have a `project template` folder in each platform. We can easily add a `plugin template` as well and write a quick create_plugin script. What do you guys think of the workflow I described above ? Any comments ? I can create jira issues for it and tackle it. -a >>> >>> Hi Anis, >>> >>> I just want to confirm whether or not this is the workflow we are >> talking about : >>> >>> For a brand new plugin: >>> >>> $ cordova plugin create /path/to/myPlugin >>> $ cordova plugin add /path/to/myPlugin --watch >>> >>> >>> For an existing plugin: >>> >>> $ cordova plugin add /path/to/corePlugin --watch >>> >>> >>> Although, I'm not quite clear about the complexity behind this, I think >> the above workflow is great for me! >>> >>> >>> >>> >>> >>> >> >>
Re: What's your daily workflow for cordova development?
plugman create could be used outside of a project, and cordova plugin create should be used only inside of a project? All other cordova commands must be used inside a project (except the "create" entry point), and if we decide to ship the plugin templates with platforms, and/or decide to make the global cordova command just a grunt-cli like thing, etc etc, then I would worry about adding uses for cordova command in some global context. On Fri, Sep 20, 2013 at 6:42 AM, Lucas Holmquist wrote: > So currently when doing > > $ cordova plugin …. > > it fails if you are not in a cordova project. > > but > > $ cordova plugin create > > might not be used inside a project( i think it shouldn't be used inside a > project at all, but i can be convinced otherwise ) > > > On Sep 4, 2013, at 10:46 PM, lmnbeyond wrote: > > > > > > >> I also think it should sub-shell to a platform script. We already have > >> a `project template` folder in each platform. We can easily add a > >> `plugin template` as well and write a quick create_plugin script. > >> > >> What do you guys think of the workflow I described above ? Any > >> comments ? I can create jira issues for it and tackle it. > >> > >> -a > >> > > > > Hi Anis, > > > > I just want to confirm whether or not this is the workflow we are > talking about : > > > > For a brand new plugin: > > > > $ cordova plugin create /path/to/myPlugin > > $ cordova plugin add /path/to/myPlugin --watch > > > > > > For an existing plugin: > > > > $ cordova plugin add /path/to/corePlugin --watch > > > > > > Although, I'm not quite clear about the complexity behind this, I think > the above workflow is great for me! > > > > > > > > > > > > > >
Re: What's your daily workflow for cordova development?
So currently when doing $ cordova plugin …. it fails if you are not in a cordova project. but $ cordova plugin create might not be used inside a project( i think it shouldn't be used inside a project at all, but i can be convinced otherwise ) On Sep 4, 2013, at 10:46 PM, lmnbeyond wrote: > > >> I also think it should sub-shell to a platform script. We already have >> a `project template` folder in each platform. We can easily add a >> `plugin template` as well and write a quick create_plugin script. >> >> What do you guys think of the workflow I described above ? Any >> comments ? I can create jira issues for it and tackle it. >> >> -a >> > > Hi Anis, > > I just want to confirm whether or not this is the workflow we are talking > about : > > For a brand new plugin: > > $ cordova plugin create /path/to/myPlugin > $ cordova plugin add /path/to/myPlugin --watch > > > For an existing plugin: > > $ cordova plugin add /path/to/corePlugin --watch > > > Although, I'm not quite clear about the complexity behind this, I think the > above workflow is great for me! > > > > > >
Re: What's your daily workflow for cordova development?
Filed CB-4886 for plugin create. On Fri, Sep 6, 2013 at 6:54 PM, James Jong wrote: > +1 create,add/watch workflow , IMO watch would be a nice addition > > -James Jong > > On Sep 4, 2013, at 10:46 PM, lmnbeyond wrote: > > > > > > >> I also think it should sub-shell to a platform script. We already have > >> a `project template` folder in each platform. We can easily add a > >> `plugin template` as well and write a quick create_plugin script. > >> > >> What do you guys think of the workflow I described above ? Any > >> comments ? I can create jira issues for it and tackle it. > >> > >> -a > >> > > > > Hi Anis, > > > > I just want to confirm whether or not this is the workflow we are > talking about : > > > > For a brand new plugin: > > > > $ cordova plugin create /path/to/myPlugin > > $ cordova plugin add /path/to/myPlugin --watch > > > > > > For an existing plugin: > > > > $ cordova plugin add /path/to/corePlugin --watch > > > > > > Although, I'm not quite clear about the complexity behind this, I think > the above workflow is great for me! > > > > > > > > > > > > > >
Re: What's your daily workflow for cordova development?
+1 create,add/watch workflow , IMO watch would be a nice addition -James Jong On Sep 4, 2013, at 10:46 PM, lmnbeyond wrote: > > >> I also think it should sub-shell to a platform script. We already have >> a `project template` folder in each platform. We can easily add a >> `plugin template` as well and write a quick create_plugin script. >> >> What do you guys think of the workflow I described above ? Any >> comments ? I can create jira issues for it and tackle it. >> >> -a >> > > Hi Anis, > > I just want to confirm whether or not this is the workflow we are talking > about : > > For a brand new plugin: > > $ cordova plugin create /path/to/myPlugin > $ cordova plugin add /path/to/myPlugin --watch > > > For an existing plugin: > > $ cordova plugin add /path/to/corePlugin --watch > > > Although, I'm not quite clear about the complexity behind this, I think the > above workflow is great for me! > > > > > >
Re: What's your daily workflow for cordova development?
> I also think it should sub-shell to a platform script. We already have > a `project template` folder in each platform. We can easily add a > `plugin template` as well and write a quick create_plugin script. > > What do you guys think of the workflow I described above ? Any > comments ? I can create jira issues for it and tackle it. > > -a > Hi Anis, I just want to confirm whether or not this is the workflow we are talking about : For a brand new plugin: $ cordova plugin create /path/to/myPlugin $ cordova plugin add /path/to/myPlugin --watch For an existing plugin: $ cordova plugin add /path/to/corePlugin --watch Although, I'm not quite clear about the complexity behind this, I think the above workflow is great for me!
Re: What's your daily workflow for cordova development?
Personally, I don't think this should be built into the system; I see nothing wrong with the workflow that Anis originally posted. If all we ever did was write echo plugins, then this would make sense, but IMHO, actually writing a plugin requires some time spent in each ./platform As an example: I am currently working through some missing functionality on WP7+8 for the filetransfer plugin. I have created a new project, installed the filetransfer plugin, and added the specs/tests so when I run it I jump right to the tests. I now have visual studio open, and I have deleted the FileTransfer.cs file from the project, and simply sim-linked to the one in the plugin repo. When I am satisfied that everything works, I will simply commit the plugin repo and be done ... @purplecabbage risingj.com On Wed, Sep 4, 2013 at 4:56 PM, Anis KADRI wrote: > I also think it should sub-shell to a platform script. We already have > a `project template` folder in each platform. We can easily add a > `plugin template` as well and write a quick create_plugin script. > > What do you guys think of the workflow I described above ? Any > comments ? I can create jira issues for it and tackle it. > > -a > > On Wed, Sep 4, 2013 at 7:26 AM, Michal Mocny wrote: > > Maybe a plugin template ships with each platform, and when you "plugin > > create" it merges the template for each platform you have installed? > > > > That would mean you have to add all interested platforms before creating > a > > plugin. > > > > -Michal > > > > > > On Wed, Sep 4, 2013 at 10:22 AM, Ian Clelland >wrote: > > > >> On Tue, Sep 3, 2013 at 11:50 AM, Braden Shepherdson < > bra...@chromium.org > >> >wrote: > >> > >> > On Tue, Sep 3, 2013 at 11:07 AM, Jonathan Bond-Caron < > >> > jbo...@gdesolutions.com> wrote: > >> > > Two new features could be useful from cli: > >> > > a) Create an initial plugin from a template > >> > > cordova plugin create [path] [name] > >> > > > >> > > e.g. > >> > > > cordova plugin create F:/GitHub/MyPlugin MyPlugin > >> > > > >> > > > >> > I agree, this would be useful. It's pretty easy to implement, just > not a > >> > high priority. Do you want to file a JIRA ticket for it? > >> > > >> > >> +1 for scaffolding; this could be very useful as a means of documenting > >> best practices for plugin authors. > >> > >> I'm not certain how this interacts with platforms, though -- would we > have > >> a monolithic "plugin template" that contains a skeleton for each > platform, > >> or is there some kind of cooperation between the various platform repos > so > >> that they can contribute their own code to the template? (or maybe the > >> default is JS only, and you have to know how to add code for any given > >> platform that you develop for) > >> > >> Ian > >> >
Re: What's your daily workflow for cordova development?
I also think it should sub-shell to a platform script. We already have a `project template` folder in each platform. We can easily add a `plugin template` as well and write a quick create_plugin script. What do you guys think of the workflow I described above ? Any comments ? I can create jira issues for it and tackle it. -a On Wed, Sep 4, 2013 at 7:26 AM, Michal Mocny wrote: > Maybe a plugin template ships with each platform, and when you "plugin > create" it merges the template for each platform you have installed? > > That would mean you have to add all interested platforms before creating a > plugin. > > -Michal > > > On Wed, Sep 4, 2013 at 10:22 AM, Ian Clelland wrote: > >> On Tue, Sep 3, 2013 at 11:50 AM, Braden Shepherdson > >wrote: >> >> > On Tue, Sep 3, 2013 at 11:07 AM, Jonathan Bond-Caron < >> > jbo...@gdesolutions.com> wrote: >> > > Two new features could be useful from cli: >> > > a) Create an initial plugin from a template >> > > cordova plugin create [path] [name] >> > > >> > > e.g. >> > > > cordova plugin create F:/GitHub/MyPlugin MyPlugin >> > > >> > > >> > I agree, this would be useful. It's pretty easy to implement, just not a >> > high priority. Do you want to file a JIRA ticket for it? >> > >> >> +1 for scaffolding; this could be very useful as a means of documenting >> best practices for plugin authors. >> >> I'm not certain how this interacts with platforms, though -- would we have >> a monolithic "plugin template" that contains a skeleton for each platform, >> or is there some kind of cooperation between the various platform repos so >> that they can contribute their own code to the template? (or maybe the >> default is JS only, and you have to know how to add code for any given >> platform that you develop for) >> >> Ian >>
Re: What's your daily workflow for cordova development?
Maybe a plugin template ships with each platform, and when you "plugin create" it merges the template for each platform you have installed? That would mean you have to add all interested platforms before creating a plugin. -Michal On Wed, Sep 4, 2013 at 10:22 AM, Ian Clelland wrote: > On Tue, Sep 3, 2013 at 11:50 AM, Braden Shepherdson >wrote: > > > On Tue, Sep 3, 2013 at 11:07 AM, Jonathan Bond-Caron < > > jbo...@gdesolutions.com> wrote: > > > Two new features could be useful from cli: > > > a) Create an initial plugin from a template > > > cordova plugin create [path] [name] > > > > > > e.g. > > > > cordova plugin create F:/GitHub/MyPlugin MyPlugin > > > > > > > > I agree, this would be useful. It's pretty easy to implement, just not a > > high priority. Do you want to file a JIRA ticket for it? > > > > +1 for scaffolding; this could be very useful as a means of documenting > best practices for plugin authors. > > I'm not certain how this interacts with platforms, though -- would we have > a monolithic "plugin template" that contains a skeleton for each platform, > or is there some kind of cooperation between the various platform repos so > that they can contribute their own code to the template? (or maybe the > default is JS only, and you have to know how to add code for any given > platform that you develop for) > > Ian >
Re: What's your daily workflow for cordova development?
On Tue, Sep 3, 2013 at 11:50 AM, Braden Shepherdson wrote: > On Tue, Sep 3, 2013 at 11:07 AM, Jonathan Bond-Caron < > jbo...@gdesolutions.com> wrote: > > Two new features could be useful from cli: > > a) Create an initial plugin from a template > > cordova plugin create [path] [name] > > > > e.g. > > > cordova plugin create F:/GitHub/MyPlugin MyPlugin > > > > > I agree, this would be useful. It's pretty easy to implement, just not a > high priority. Do you want to file a JIRA ticket for it? > +1 for scaffolding; this could be very useful as a means of documenting best practices for plugin authors. I'm not certain how this interacts with platforms, though -- would we have a monolithic "plugin template" that contains a skeleton for each platform, or is there some kind of cooperation between the various platform repos so that they can contribute their own code to the template? (or maybe the default is JS only, and you have to know how to add code for any given platform that you develop for) Ian
Re: What's your daily workflow for cordova development?
This would be my ideal workflow $ cordova plugin add /path/to/plugin $ cordova plugin watch /path/to/plugin # detects if plugin is installed (otherwise fails), watches for changes and automatically updates CLIPROJECT/plugins and re-runs prepare. maybe even `add --watch` (CTRL+C to cancel). We don't have to worry about version numbers. We can just watch the filesystem for changes (and there are node packages that do that such as chokidar [1]) I think update/upgrade for plugins and cordova are more for app developers than plugin developers. As far as testing, I think it should be part of the plugin itself and not part of giant test suite (like mobile-spec). Also I remember us talking about giving the freedom to use whatever testing framework they want as long as it spits out a proper test result format. Was it TAP [2]? [1] https://github.com/paulmillr/chokidar [2] http://en.wikipedia.org/wiki/Test_Anything_Protocol On Tue, Sep 3, 2013 at 8:50 AM, Braden Shepherdson wrote: > Responses inline. > > > On Tue, Sep 3, 2013 at 11:07 AM, Jonathan Bond-Caron < > jbo...@gdesolutions.com> wrote: > >> On Mon Sep 2 07:34 PM, Brian LeRoux wrote: >> > Here's a shot. Ideal flow tomorrow might be to generate a plugin called, >> lets say, >> > "Echo" that matches something we'd find in our docs, automate add/remove >> > with some sort of watch command. That way ppl are writing to the plugin >> spec >> > from the beginning instead of refactoring a plugin out of a native >> project. >> > >> > Thoughts? >> > >> >> Two new features could be useful from cli: >> a) Create an initial plugin from a template >> cordova plugin create [path] [name] >> >> e.g. >> > cordova plugin create F:/GitHub/MyPlugin MyPlugin >> >> > I agree, this would be useful. It's pretty easy to implement, just not a > high priority. Do you want to file a JIRA ticket for it? > > >> b) Update all plugins from a cordova application >> cordova plugins update >> >> e.g. >> > cordova create F:/CordovaApp >> > cd F:/CordovaApp >> > cordova plugin add F:/GitHub/MyPlugin >> > cordova plugins update >> >> The implementation is likely tricky, how to detect plugin modification? >> Version check? >> I image it would remove & install the new plugin. >> >> > cordova plugins update -local >> >> Could be useful to force the removal and reinstall of only local plugins >> (from a filesystem path) / under development... >> >> > There are plans for an cordova plugin upgrade [foo] command, but you're > correct that it's tricky, how we handle dependencies and so on. I've got a > draft of a plan for it, but I haven't finished it and sent it around. > > I think the ideal solution to the larger problem of in-place-updating > plugins would be to have the plugin installation logic running on every > prepare (and then a cordova watch command that re-runs prepare when the > plugins change). My ideal flow is: > - I add the plugin via symlink, so that it's pointing to the same place on > disk. > - I change some file, native or JS or even plugin.xml > - cordova watch notices that and re-runs prepare, which updates everything > properly. > > But that takes some doing: what if I removed or renamed a native file? It > needs to know which one so that it can be removed, but for that it needs to > cache the old plugin.xml, etc. etc. All of these are solvable problems, but > it will be some time before all the pieces are in place for this flow. > > Ultimately, we need to optimize first for app developers, and then for > plugin developers. On the other hand, the fact that we're now concerned > with the latter suggests that the main app developer flow is pretty solid, > which I think it is. With the exception of how painful it currently is to > update a platform (rather than a plugin), but we've got plans under > discussion for that problem too. > > >> I haven't gotten around to running .spec tests but something simple as: >> c) Running tests within plugin directory >> cd F:/GitHub/MyPlugin >> cordova plugin test >> >> [Test #1] Passed >> [Test #2] Failed: Reference error foo doesn't not exist >> >> Would be very useful. >> >> > We want some kind of per-plugin testing story, rather than our big > mobile-spec test suite. There are enough problems and questions here, > though, that we've just left things as they are for now. That is, one > monolithic mobile-spec for all of Cordova's core plugins, and plugin > authors are on their own - which generally means that third-party plugins > have no tests :( > > Braden
Re: What's your daily workflow for cordova development?
Responses inline. On Tue, Sep 3, 2013 at 11:07 AM, Jonathan Bond-Caron < jbo...@gdesolutions.com> wrote: > On Mon Sep 2 07:34 PM, Brian LeRoux wrote: > > Here's a shot. Ideal flow tomorrow might be to generate a plugin called, > lets say, > > "Echo" that matches something we'd find in our docs, automate add/remove > > with some sort of watch command. That way ppl are writing to the plugin > spec > > from the beginning instead of refactoring a plugin out of a native > project. > > > > Thoughts? > > > > Two new features could be useful from cli: > a) Create an initial plugin from a template > cordova plugin create [path] [name] > > e.g. > > cordova plugin create F:/GitHub/MyPlugin MyPlugin > > I agree, this would be useful. It's pretty easy to implement, just not a high priority. Do you want to file a JIRA ticket for it? > b) Update all plugins from a cordova application > cordova plugins update > > e.g. > > cordova create F:/CordovaApp > > cd F:/CordovaApp > > cordova plugin add F:/GitHub/MyPlugin > > cordova plugins update > > The implementation is likely tricky, how to detect plugin modification? > Version check? > I image it would remove & install the new plugin. > > > cordova plugins update -local > > Could be useful to force the removal and reinstall of only local plugins > (from a filesystem path) / under development... > > There are plans for an cordova plugin upgrade [foo] command, but you're correct that it's tricky, how we handle dependencies and so on. I've got a draft of a plan for it, but I haven't finished it and sent it around. I think the ideal solution to the larger problem of in-place-updating plugins would be to have the plugin installation logic running on every prepare (and then a cordova watch command that re-runs prepare when the plugins change). My ideal flow is: - I add the plugin via symlink, so that it's pointing to the same place on disk. - I change some file, native or JS or even plugin.xml - cordova watch notices that and re-runs prepare, which updates everything properly. But that takes some doing: what if I removed or renamed a native file? It needs to know which one so that it can be removed, but for that it needs to cache the old plugin.xml, etc. etc. All of these are solvable problems, but it will be some time before all the pieces are in place for this flow. Ultimately, we need to optimize first for app developers, and then for plugin developers. On the other hand, the fact that we're now concerned with the latter suggests that the main app developer flow is pretty solid, which I think it is. With the exception of how painful it currently is to update a platform (rather than a plugin), but we've got plans under discussion for that problem too. > I haven't gotten around to running .spec tests but something simple as: > c) Running tests within plugin directory > cd F:/GitHub/MyPlugin > cordova plugin test > > [Test #1] Passed > [Test #2] Failed: Reference error foo doesn't not exist > > Would be very useful. > > We want some kind of per-plugin testing story, rather than our big mobile-spec test suite. There are enough problems and questions here, though, that we've just left things as they are for now. That is, one monolithic mobile-spec for all of Cordova's core plugins, and plugin authors are on their own - which generally means that third-party plugins have no tests :( Braden
RE: What's your daily workflow for cordova development?
On Mon Sep 2 07:34 PM, Brian LeRoux wrote: > Here's a shot. Ideal flow tomorrow might be to generate a plugin called, lets > say, > "Echo" that matches something we'd find in our docs, automate add/remove > with some sort of watch command. That way ppl are writing to the plugin spec > from the beginning instead of refactoring a plugin out of a native project. > > Thoughts? > Two new features could be useful from cli: a) Create an initial plugin from a template cordova plugin create [path] [name] e.g. > cordova plugin create F:/GitHub/MyPlugin MyPlugin b) Update all plugins from a cordova application cordova plugins update e.g. > cordova create F:/CordovaApp > cd F:/CordovaApp > cordova plugin add F:/GitHub/MyPlugin > cordova plugins update The implementation is likely tricky, how to detect plugin modification? Version check? I image it would remove & install the new plugin. > cordova plugins update -local Could be useful to force the removal and reinstall of only local plugins (from a filesystem path) / under development... I haven't gotten around to running .spec tests but something simple as: c) Running tests within plugin directory cd F:/GitHub/MyPlugin cordova plugin test [Test #1] Passed [Test #2] Failed: Reference error foo doesn't not exist Would be very useful.
Re: What's your daily workflow for cordova development?
I do like the idea of a `plugin watch` command, but I think we need to consider a few points: Our current plan for "plugin upgrade" is to plugin rm && plugin add. So, we need an keep immutable copy of the original plugin as it was during install time in order to uninstall correctly (thought: maybe we only need the original plugin.xml?). I think that is the purpose of the plugins/ directory, more than anything else right now. If we want to support any "live" plugin dev, it would currently need to be in a different directory location (outside plugins/ folder). I really don't like that fact (seems @devgeeks agrees). Perhaps we can fix this situation if all thats needed is the original plugin.xml.. Also, perhaps we also add a "plugin create" command to set up a plugin template? -Michal On Mon, Sep 2, 2013 at 9:49 PM, lmnbeyond wrote: > + 1 love "watch command" idea :) > > Best Regards! > > > > On 2013-9-3, at 上午7:34, Brian LeRoux wrote: > > > automate > > add/remove with some sort of watch command. That way ppl are writing to > the > > plugin spec from the beginning instead of refactoring a plugin out of a > > native project. > >
Re: What's your daily workflow for cordova development?
+ 1 love "watch command" idea :) Best Regards! On 2013-9-3, at 上午7:34, Brian LeRoux wrote: > automate > add/remove with some sort of watch command. That way ppl are writing to the > plugin spec from the beginning instead of refactoring a plugin out of a > native project.
Re: What's your daily workflow for cordova development?
+1 I am surprised that once a plugin has been added to ./platforms/**/* it is never refreshed from the version in ./plugins/**/* It means that plugin dev has to happen in ./platforms instead of in ./plugins at the very least. If I could create a plugin or even add a scaffold of a plugin to ./plugins and then edit it there and have it get refreshed into my platform when I build that would be a great start. Having said all that, I personally love the cli with all my heart because it means I almost never have to open Xcode or Eclipse… but when working on a plugin, native debugging tools can be a must, so I need to open them anyway… so maybe having to work within ./platforms isn't as bad as it sounds… :| On 03/09/2013, at 9:34 AM, Brian LeRoux wrote: > So, first of all I agree, this is probably the ideal flow today. A good > reason for this list is to figure out how we can make the best possible > developer experience going forward. With the Discovery side of things all > but deployed I'd love for us to look at making this part a little more sane > for our dev community. > > Here's a shot. Ideal flow tomorrow might be to generate a plugin called, > lets say, "Echo" that matches something we'd find in our docs, automate > add/remove with some sort of watch command. That way ppl are writing to the > plugin spec from the beginning instead of refactoring a plugin out of a > native project. > > Thoughts? > > > > On Fri, Aug 30, 2013 at 2:03 PM, Anis KADRI wrote: > >> Neither CLI nor plugman (at least while developing). >> >> I would create a project using our platform scripts and develop my >> plugin in that project workspace and when I feel that my plugin is >> ready that I will create a plugin.xml and test it out with plugman and >> CLI and then publish it. >> >> plugman automates plugin installation but I don't think it adds any >> real benefits to plugin authors. >> CLI automates cross-platform project management but I don't think it >> adds any real benefits for plugin authors either. Unless we're talking >> about javascript only plugins, in which case you just work on your >> www/ folder and test out things with CLI commands. For plugins that >> require native bits you have to re-add it every time since your >> platforms/ folder gets blown away on every build. That is why I said >> it's not ideal. >> >> That is how I roll but I don't expect or advise anybody to do the same. >> >> On Fri, Aug 30, 2013 at 1:16 PM, Brian LeRoux wrote: >>> Pls explain. >>> On Aug 30, 2013 12:45 PM, "Anis KADRI" wrote: >>> I wouldn't use cordova-cli if I were to develop a plugin. I don't think the workflow is ideal. On Fri, Aug 30, 2013 at 6:47 AM, Michal Mocny >> wrote: > I am interpreting your concern in two different ways, so I'll clarify >> my > assumption and answer both: > > -- > > Interpretation (1): You want to develop a new plugin, and find it >> hard to > find the right files to track inside a cli created workspace. > > If you want to "develop some feature or plugin", I suggest you do not first > create a project in the cli and try to write your plugin directly >> inside > there manually. > > Instead, create a new plugin using the plugin dev guide[1] and >> spec[2], > creating it in a separate folder/repo. It seems we don't have a great > "overview" page about how to create a plugin directory structure. >> I'll see > about adding that, but for now, just consult another plugin structure, such > as cordova-plugin-device[3]. > > Once you've started writing your plugin, and have at least the bare >> bones > structure, create a cli project to consume it: > > cordova create App ... && cd App > cordova platform add ... > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN > cordova prepare > ... > > Now, every time you make changes to *the original* plugin, you'll >> need to > re-add it from source: > > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN // Doing this should > overwrite the old version > cordova prepare > ... > > Then, Iterate! > > (We may simplify that step with a "plugin upgrade" command one day) > > Note: If you make mistakes in your plugin.xml specifications, the >> install > may fail and you may end up with a slightly awkward workspace, and >> will > need to manually delete some files, or just re-create a new workspace >> for > testing. > > -- > > Interpretation (2): You want to version an entire workspace you've created > with cordova-cli. > > You can do this, but, cli created workspaces have a bunch of "build > artifacts" and it serves little purpose to actually track changes to >> them > (in my opinion). > > The pieces that are actually worth tracking are the original sources: > p
Re: What's your daily workflow for cordova development?
So, first of all I agree, this is probably the ideal flow today. A good reason for this list is to figure out how we can make the best possible developer experience going forward. With the Discovery side of things all but deployed I'd love for us to look at making this part a little more sane for our dev community. Here's a shot. Ideal flow tomorrow might be to generate a plugin called, lets say, "Echo" that matches something we'd find in our docs, automate add/remove with some sort of watch command. That way ppl are writing to the plugin spec from the beginning instead of refactoring a plugin out of a native project. Thoughts? On Fri, Aug 30, 2013 at 2:03 PM, Anis KADRI wrote: > Neither CLI nor plugman (at least while developing). > > I would create a project using our platform scripts and develop my > plugin in that project workspace and when I feel that my plugin is > ready that I will create a plugin.xml and test it out with plugman and > CLI and then publish it. > > plugman automates plugin installation but I don't think it adds any > real benefits to plugin authors. > CLI automates cross-platform project management but I don't think it > adds any real benefits for plugin authors either. Unless we're talking > about javascript only plugins, in which case you just work on your > www/ folder and test out things with CLI commands. For plugins that > require native bits you have to re-add it every time since your > platforms/ folder gets blown away on every build. That is why I said > it's not ideal. > > That is how I roll but I don't expect or advise anybody to do the same. > > On Fri, Aug 30, 2013 at 1:16 PM, Brian LeRoux wrote: > > Pls explain. > > On Aug 30, 2013 12:45 PM, "Anis KADRI" wrote: > > > >> I wouldn't use cordova-cli if I were to develop a plugin. I don't > >> think the workflow is ideal. > >> > >> On Fri, Aug 30, 2013 at 6:47 AM, Michal Mocny > wrote: > >> > I am interpreting your concern in two different ways, so I'll clarify > my > >> > assumption and answer both: > >> > > >> > -- > >> > > >> > Interpretation (1): You want to develop a new plugin, and find it > hard to > >> > find the right files to track inside a cli created workspace. > >> > > >> > If you want to "develop some feature or plugin", I suggest you do not > >> first > >> > create a project in the cli and try to write your plugin directly > inside > >> > there manually. > >> > > >> > Instead, create a new plugin using the plugin dev guide[1] and > spec[2], > >> > creating it in a separate folder/repo. It seems we don't have a great > >> > "overview" page about how to create a plugin directory structure. > I'll > >> see > >> > about adding that, but for now, just consult another plugin structure, > >> such > >> > as cordova-plugin-device[3]. > >> > > >> > Once you've started writing your plugin, and have at least the bare > bones > >> > structure, create a cli project to consume it: > >> > > >> > cordova create App ... && cd App > >> > cordova platform add ... > >> > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN > >> > cordova prepare > >> > ... > >> > > >> > Now, every time you make changes to *the original* plugin, you'll > need to > >> > re-add it from source: > >> > > >> > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN // Doing this should > >> > overwrite the old version > >> > cordova prepare > >> > ... > >> > > >> > Then, Iterate! > >> > > >> > (We may simplify that step with a "plugin upgrade" command one day) > >> > > >> > Note: If you make mistakes in your plugin.xml specifications, the > install > >> > may fail and you may end up with a slightly awkward workspace, and > will > >> > need to manually delete some files, or just re-create a new workspace > for > >> > testing. > >> > > >> > -- > >> > > >> > Interpretation (2): You want to version an entire workspace you've > >> created > >> > with cordova-cli. > >> > > >> > You can do this, but, cli created workspaces have a bunch of "build > >> > artifacts" and it serves little purpose to actually track changes to > them > >> > (in my opinion). > >> > > >> > The pieces that are actually worth tracking are the original sources: > >> > platforms, plugins, and your app(s). > >> > > >> > If you would like to manually track versions of platforms or the core > >> > plugins, you are free to clone the git repos manually, and use > >> cordova-cli > >> > to add them from local paths. This way, you can also make downstream > >> > changes inside feature branches etc. > >> > > >> > If you do not actually need to make changes to platforms/plugins, it > is > >> > easier to let CLI automatically fetch the latest stable versions for > you, > >> > or fetch specific version you request for you, and trust that we will > >> serve > >> > good working versions. You can always revert to older versions if > issues > >> > come up. > >> > > >> > Again, you can of course add the whole workspace into a repo and share > >> that > >> > across a team, but m
Re: What's your daily workflow for cordova development?
Hi, Thanks for all your detailed explanations. I tend to agree with @Anis KADRI, CLI is amazing, but it's a little low-productive to iterate "add/remove". However, I think I can accept a compromise: add a "plugin upgrade" command, as @Michal Mocny has mentioned. Best Regards! On 2013-8-31, at 上午5:03, Anis KADRI wrote: > Neither CLI nor plugman (at least while developing). > > I would create a project using our platform scripts and develop my > plugin in that project workspace and when I feel that my plugin is > ready that I will create a plugin.xml and test it out with plugman and > CLI and then publish it. > > plugman automates plugin installation but I don't think it adds any > real benefits to plugin authors. > CLI automates cross-platform project management but I don't think it > adds any real benefits for plugin authors either. Unless we're talking > about javascript only plugins, in which case you just work on your > www/ folder and test out things with CLI commands. For plugins that > require native bits you have to re-add it every time since your > platforms/ folder gets blown away on every build. That is why I said > it's not ideal. > > That is how I roll but I don't expect or advise anybody to do the same. > > On Fri, Aug 30, 2013 at 1:16 PM, Brian LeRoux wrote: >> Pls explain. >> On Aug 30, 2013 12:45 PM, "Anis KADRI" wrote: >> >>> I wouldn't use cordova-cli if I were to develop a plugin. I don't >>> think the workflow is ideal. >>> >>> On Fri, Aug 30, 2013 at 6:47 AM, Michal Mocny wrote: I am interpreting your concern in two different ways, so I'll clarify my assumption and answer both: -- Interpretation (1): You want to develop a new plugin, and find it hard to find the right files to track inside a cli created workspace. If you want to "develop some feature or plugin", I suggest you do not >>> first create a project in the cli and try to write your plugin directly inside there manually. Instead, create a new plugin using the plugin dev guide[1] and spec[2], creating it in a separate folder/repo. It seems we don't have a great "overview" page about how to create a plugin directory structure. I'll >>> see about adding that, but for now, just consult another plugin structure, >>> such as cordova-plugin-device[3]. Once you've started writing your plugin, and have at least the bare bones structure, create a cli project to consume it: cordova create App ... && cd App cordova platform add ... cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN cordova prepare ... Now, every time you make changes to *the original* plugin, you'll need to re-add it from source: cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN // Doing this should overwrite the old version cordova prepare ... Then, Iterate! (We may simplify that step with a "plugin upgrade" command one day) Note: If you make mistakes in your plugin.xml specifications, the install may fail and you may end up with a slightly awkward workspace, and will need to manually delete some files, or just re-create a new workspace for testing. -- Interpretation (2): You want to version an entire workspace you've >>> created with cordova-cli. You can do this, but, cli created workspaces have a bunch of "build artifacts" and it serves little purpose to actually track changes to them (in my opinion). The pieces that are actually worth tracking are the original sources: platforms, plugins, and your app(s). If you would like to manually track versions of platforms or the core plugins, you are free to clone the git repos manually, and use >>> cordova-cli to add them from local paths. This way, you can also make downstream changes inside feature branches etc. If you do not actually need to make changes to platforms/plugins, it is easier to let CLI automatically fetch the latest stable versions for you, or fetch specific version you request for you, and trust that we will >>> serve good working versions. You can always revert to older versions if issues come up. Again, you can of course add the whole workspace into a repo and share >>> that across a team, but much of those files are created as a result of file munging and will change in odd ways over time. -- [1]: >>> http://cordova.apache.org/docs/en/3.0.0/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide [2]: >>> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Specification [3]: https://github.com/apache/cordova-plugin-device -Michal On Fri, Aug 30, 2013 at 5:51 AM
Re: What's your daily workflow for cordova development?
Neither CLI nor plugman (at least while developing). I would create a project using our platform scripts and develop my plugin in that project workspace and when I feel that my plugin is ready that I will create a plugin.xml and test it out with plugman and CLI and then publish it. plugman automates plugin installation but I don't think it adds any real benefits to plugin authors. CLI automates cross-platform project management but I don't think it adds any real benefits for plugin authors either. Unless we're talking about javascript only plugins, in which case you just work on your www/ folder and test out things with CLI commands. For plugins that require native bits you have to re-add it every time since your platforms/ folder gets blown away on every build. That is why I said it's not ideal. That is how I roll but I don't expect or advise anybody to do the same. On Fri, Aug 30, 2013 at 1:16 PM, Brian LeRoux wrote: > Pls explain. > On Aug 30, 2013 12:45 PM, "Anis KADRI" wrote: > >> I wouldn't use cordova-cli if I were to develop a plugin. I don't >> think the workflow is ideal. >> >> On Fri, Aug 30, 2013 at 6:47 AM, Michal Mocny wrote: >> > I am interpreting your concern in two different ways, so I'll clarify my >> > assumption and answer both: >> > >> > -- >> > >> > Interpretation (1): You want to develop a new plugin, and find it hard to >> > find the right files to track inside a cli created workspace. >> > >> > If you want to "develop some feature or plugin", I suggest you do not >> first >> > create a project in the cli and try to write your plugin directly inside >> > there manually. >> > >> > Instead, create a new plugin using the plugin dev guide[1] and spec[2], >> > creating it in a separate folder/repo. It seems we don't have a great >> > "overview" page about how to create a plugin directory structure. I'll >> see >> > about adding that, but for now, just consult another plugin structure, >> such >> > as cordova-plugin-device[3]. >> > >> > Once you've started writing your plugin, and have at least the bare bones >> > structure, create a cli project to consume it: >> > >> > cordova create App ... && cd App >> > cordova platform add ... >> > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN >> > cordova prepare >> > ... >> > >> > Now, every time you make changes to *the original* plugin, you'll need to >> > re-add it from source: >> > >> > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN // Doing this should >> > overwrite the old version >> > cordova prepare >> > ... >> > >> > Then, Iterate! >> > >> > (We may simplify that step with a "plugin upgrade" command one day) >> > >> > Note: If you make mistakes in your plugin.xml specifications, the install >> > may fail and you may end up with a slightly awkward workspace, and will >> > need to manually delete some files, or just re-create a new workspace for >> > testing. >> > >> > -- >> > >> > Interpretation (2): You want to version an entire workspace you've >> created >> > with cordova-cli. >> > >> > You can do this, but, cli created workspaces have a bunch of "build >> > artifacts" and it serves little purpose to actually track changes to them >> > (in my opinion). >> > >> > The pieces that are actually worth tracking are the original sources: >> > platforms, plugins, and your app(s). >> > >> > If you would like to manually track versions of platforms or the core >> > plugins, you are free to clone the git repos manually, and use >> cordova-cli >> > to add them from local paths. This way, you can also make downstream >> > changes inside feature branches etc. >> > >> > If you do not actually need to make changes to platforms/plugins, it is >> > easier to let CLI automatically fetch the latest stable versions for you, >> > or fetch specific version you request for you, and trust that we will >> serve >> > good working versions. You can always revert to older versions if issues >> > come up. >> > >> > Again, you can of course add the whole workspace into a repo and share >> that >> > across a team, but much of those files are created as a result of file >> > munging and will change in odd ways over time. >> > >> > -- >> > >> > >> > [1]: >> > >> http://cordova.apache.org/docs/en/3.0.0/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide >> > [2]: >> > >> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Specification >> > [3]: https://github.com/apache/cordova-plugin-device >> > >> > -Michal >> > >> > >> > >> > On Fri, Aug 30, 2013 at 5:51 AM, lmnbeyond wrote: >> > >> >> Hi all, >> >> >> >> Cordova was separated into tens of individual repos ever since >> 3.0 >> >> and we're benefit from this change and can quickly build/test apps. >> >> >> >> For now, if I want to develop some feature or plugin, I can >> first >> >> create a project by cli, then did some changes, but meanwhile it's >> >> difficult to track which files got changed/added/removed, s
Re: What's your daily workflow for cordova development?
I wouldn't use cordova-cli if I were to develop a plugin. I don't think the workflow is ideal. On Fri, Aug 30, 2013 at 6:47 AM, Michal Mocny wrote: > I am interpreting your concern in two different ways, so I'll clarify my > assumption and answer both: > > -- > > Interpretation (1): You want to develop a new plugin, and find it hard to > find the right files to track inside a cli created workspace. > > If you want to "develop some feature or plugin", I suggest you do not first > create a project in the cli and try to write your plugin directly inside > there manually. > > Instead, create a new plugin using the plugin dev guide[1] and spec[2], > creating it in a separate folder/repo. It seems we don't have a great > "overview" page about how to create a plugin directory structure. I'll see > about adding that, but for now, just consult another plugin structure, such > as cordova-plugin-device[3]. > > Once you've started writing your plugin, and have at least the bare bones > structure, create a cli project to consume it: > > cordova create App ... && cd App > cordova platform add ... > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN > cordova prepare > ... > > Now, every time you make changes to *the original* plugin, you'll need to > re-add it from source: > > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN // Doing this should > overwrite the old version > cordova prepare > ... > > Then, Iterate! > > (We may simplify that step with a "plugin upgrade" command one day) > > Note: If you make mistakes in your plugin.xml specifications, the install > may fail and you may end up with a slightly awkward workspace, and will > need to manually delete some files, or just re-create a new workspace for > testing. > > -- > > Interpretation (2): You want to version an entire workspace you've created > with cordova-cli. > > You can do this, but, cli created workspaces have a bunch of "build > artifacts" and it serves little purpose to actually track changes to them > (in my opinion). > > The pieces that are actually worth tracking are the original sources: > platforms, plugins, and your app(s). > > If you would like to manually track versions of platforms or the core > plugins, you are free to clone the git repos manually, and use cordova-cli > to add them from local paths. This way, you can also make downstream > changes inside feature branches etc. > > If you do not actually need to make changes to platforms/plugins, it is > easier to let CLI automatically fetch the latest stable versions for you, > or fetch specific version you request for you, and trust that we will serve > good working versions. You can always revert to older versions if issues > come up. > > Again, you can of course add the whole workspace into a repo and share that > across a team, but much of those files are created as a result of file > munging and will change in odd ways over time. > > -- > > > [1]: > http://cordova.apache.org/docs/en/3.0.0/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide > [2]: > http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Specification > [3]: https://github.com/apache/cordova-plugin-device > > -Michal > > > > On Fri, Aug 30, 2013 at 5:51 AM, lmnbeyond wrote: > >> Hi all, >> >> Cordova was separated into tens of individual repos ever since 3.0 >> and we're benefit from this change and can quickly build/test apps. >> >> For now, if I want to develop some feature or plugin, I can first >> create a project by cli, then did some changes, but meanwhile it's >> difficult to track which files got changed/added/removed, since all source >> was not under source control. And it's also error prone to manually do the >> tracking. The structure of cordova-x repos is different from the structure >> in a development project. >> >> It was easier if there was an all-in-one project, I mean all >> native sources in a single project, before 3.0. >> >> >> Best Regards! >> >> >> >>
Re: What's your daily workflow for cordova development?
How is plugin dev via CLI worse than just using plugman directly? The only other option is to not use our plugin format at all, and treat your "feature" as a platform extension. You can still use some of our plugin guide to develop your feature, I wouldn't consider it a plugin, i.e. you couldn't publish/share it with others. If thats your intention, I would clone the platform and develop your features on a branch, and use that in your "platform add" step. -Michal On Fri, Aug 30, 2013 at 3:38 PM, Anis KADRI wrote: > I wouldn't use cordova-cli if I were to develop a plugin. I don't > think the workflow is ideal. > > On Fri, Aug 30, 2013 at 6:47 AM, Michal Mocny wrote: > > I am interpreting your concern in two different ways, so I'll clarify my > > assumption and answer both: > > > > -- > > > > Interpretation (1): You want to develop a new plugin, and find it hard to > > find the right files to track inside a cli created workspace. > > > > If you want to "develop some feature or plugin", I suggest you do not > first > > create a project in the cli and try to write your plugin directly inside > > there manually. > > > > Instead, create a new plugin using the plugin dev guide[1] and spec[2], > > creating it in a separate folder/repo. It seems we don't have a great > > "overview" page about how to create a plugin directory structure. I'll > see > > about adding that, but for now, just consult another plugin structure, > such > > as cordova-plugin-device[3]. > > > > Once you've started writing your plugin, and have at least the bare bones > > structure, create a cli project to consume it: > > > > cordova create App ... && cd App > > cordova platform add ... > > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN > > cordova prepare > > ... > > > > Now, every time you make changes to *the original* plugin, you'll need to > > re-add it from source: > > > > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN // Doing this should > > overwrite the old version > > cordova prepare > > ... > > > > Then, Iterate! > > > > (We may simplify that step with a "plugin upgrade" command one day) > > > > Note: If you make mistakes in your plugin.xml specifications, the install > > may fail and you may end up with a slightly awkward workspace, and will > > need to manually delete some files, or just re-create a new workspace for > > testing. > > > > -- > > > > Interpretation (2): You want to version an entire workspace you've > created > > with cordova-cli. > > > > You can do this, but, cli created workspaces have a bunch of "build > > artifacts" and it serves little purpose to actually track changes to them > > (in my opinion). > > > > The pieces that are actually worth tracking are the original sources: > > platforms, plugins, and your app(s). > > > > If you would like to manually track versions of platforms or the core > > plugins, you are free to clone the git repos manually, and use > cordova-cli > > to add them from local paths. This way, you can also make downstream > > changes inside feature branches etc. > > > > If you do not actually need to make changes to platforms/plugins, it is > > easier to let CLI automatically fetch the latest stable versions for you, > > or fetch specific version you request for you, and trust that we will > serve > > good working versions. You can always revert to older versions if issues > > come up. > > > > Again, you can of course add the whole workspace into a repo and share > that > > across a team, but much of those files are created as a result of file > > munging and will change in odd ways over time. > > > > -- > > > > > > [1]: > > > http://cordova.apache.org/docs/en/3.0.0/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide > > [2]: > > > http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Specification > > [3]: https://github.com/apache/cordova-plugin-device > > > > -Michal > > > > > > > > On Fri, Aug 30, 2013 at 5:51 AM, lmnbeyond wrote: > > > >> Hi all, > >> > >> Cordova was separated into tens of individual repos ever since > 3.0 > >> and we're benefit from this change and can quickly build/test apps. > >> > >> For now, if I want to develop some feature or plugin, I can > first > >> create a project by cli, then did some changes, but meanwhile it's > >> difficult to track which files got changed/added/removed, since all > source > >> was not under source control. And it's also error prone to manually do > the > >> tracking. The structure of cordova-x repos is different from the > structure > >> in a development project. > >> > >> It was easier if there was an all-in-one project, I mean all > >> native sources in a single project, before 3.0. > >> > >> > >> Best Regards! > >> > >> > >> > >> >
Re: What's your daily workflow for cordova development?
Pls explain. On Aug 30, 2013 12:45 PM, "Anis KADRI" wrote: > I wouldn't use cordova-cli if I were to develop a plugin. I don't > think the workflow is ideal. > > On Fri, Aug 30, 2013 at 6:47 AM, Michal Mocny wrote: > > I am interpreting your concern in two different ways, so I'll clarify my > > assumption and answer both: > > > > -- > > > > Interpretation (1): You want to develop a new plugin, and find it hard to > > find the right files to track inside a cli created workspace. > > > > If you want to "develop some feature or plugin", I suggest you do not > first > > create a project in the cli and try to write your plugin directly inside > > there manually. > > > > Instead, create a new plugin using the plugin dev guide[1] and spec[2], > > creating it in a separate folder/repo. It seems we don't have a great > > "overview" page about how to create a plugin directory structure. I'll > see > > about adding that, but for now, just consult another plugin structure, > such > > as cordova-plugin-device[3]. > > > > Once you've started writing your plugin, and have at least the bare bones > > structure, create a cli project to consume it: > > > > cordova create App ... && cd App > > cordova platform add ... > > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN > > cordova prepare > > ... > > > > Now, every time you make changes to *the original* plugin, you'll need to > > re-add it from source: > > > > cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN // Doing this should > > overwrite the old version > > cordova prepare > > ... > > > > Then, Iterate! > > > > (We may simplify that step with a "plugin upgrade" command one day) > > > > Note: If you make mistakes in your plugin.xml specifications, the install > > may fail and you may end up with a slightly awkward workspace, and will > > need to manually delete some files, or just re-create a new workspace for > > testing. > > > > -- > > > > Interpretation (2): You want to version an entire workspace you've > created > > with cordova-cli. > > > > You can do this, but, cli created workspaces have a bunch of "build > > artifacts" and it serves little purpose to actually track changes to them > > (in my opinion). > > > > The pieces that are actually worth tracking are the original sources: > > platforms, plugins, and your app(s). > > > > If you would like to manually track versions of platforms or the core > > plugins, you are free to clone the git repos manually, and use > cordova-cli > > to add them from local paths. This way, you can also make downstream > > changes inside feature branches etc. > > > > If you do not actually need to make changes to platforms/plugins, it is > > easier to let CLI automatically fetch the latest stable versions for you, > > or fetch specific version you request for you, and trust that we will > serve > > good working versions. You can always revert to older versions if issues > > come up. > > > > Again, you can of course add the whole workspace into a repo and share > that > > across a team, but much of those files are created as a result of file > > munging and will change in odd ways over time. > > > > -- > > > > > > [1]: > > > http://cordova.apache.org/docs/en/3.0.0/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide > > [2]: > > > http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Specification > > [3]: https://github.com/apache/cordova-plugin-device > > > > -Michal > > > > > > > > On Fri, Aug 30, 2013 at 5:51 AM, lmnbeyond wrote: > > > >> Hi all, > >> > >> Cordova was separated into tens of individual repos ever since > 3.0 > >> and we're benefit from this change and can quickly build/test apps. > >> > >> For now, if I want to develop some feature or plugin, I can > first > >> create a project by cli, then did some changes, but meanwhile it's > >> difficult to track which files got changed/added/removed, since all > source > >> was not under source control. And it's also error prone to manually do > the > >> tracking. The structure of cordova-x repos is different from the > structure > >> in a development project. > >> > >> It was easier if there was an all-in-one project, I mean all > >> native sources in a single project, before 3.0. > >> > >> > >> Best Regards! > >> > >> > >> > >> >
Re: What's your daily workflow for cordova development?
I am interpreting your concern in two different ways, so I'll clarify my assumption and answer both: -- Interpretation (1): You want to develop a new plugin, and find it hard to find the right files to track inside a cli created workspace. If you want to "develop some feature or plugin", I suggest you do not first create a project in the cli and try to write your plugin directly inside there manually. Instead, create a new plugin using the plugin dev guide[1] and spec[2], creating it in a separate folder/repo. It seems we don't have a great "overview" page about how to create a plugin directory structure. I'll see about adding that, but for now, just consult another plugin structure, such as cordova-plugin-device[3]. Once you've started writing your plugin, and have at least the bare bones structure, create a cli project to consume it: cordova create App ... && cd App cordova platform add ... cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN cordova prepare ... Now, every time you make changes to *the original* plugin, you'll need to re-add it from source: cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN // Doing this should overwrite the old version cordova prepare ... Then, Iterate! (We may simplify that step with a "plugin upgrade" command one day) Note: If you make mistakes in your plugin.xml specifications, the install may fail and you may end up with a slightly awkward workspace, and will need to manually delete some files, or just re-create a new workspace for testing. -- Interpretation (2): You want to version an entire workspace you've created with cordova-cli. You can do this, but, cli created workspaces have a bunch of "build artifacts" and it serves little purpose to actually track changes to them (in my opinion). The pieces that are actually worth tracking are the original sources: platforms, plugins, and your app(s). If you would like to manually track versions of platforms or the core plugins, you are free to clone the git repos manually, and use cordova-cli to add them from local paths. This way, you can also make downstream changes inside feature branches etc. If you do not actually need to make changes to platforms/plugins, it is easier to let CLI automatically fetch the latest stable versions for you, or fetch specific version you request for you, and trust that we will serve good working versions. You can always revert to older versions if issues come up. Again, you can of course add the whole workspace into a repo and share that across a team, but much of those files are created as a result of file munging and will change in odd ways over time. -- [1]: http://cordova.apache.org/docs/en/3.0.0/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide [2]: http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Specification [3]: https://github.com/apache/cordova-plugin-device -Michal On Fri, Aug 30, 2013 at 5:51 AM, lmnbeyond wrote: > Hi all, > > Cordova was separated into tens of individual repos ever since 3.0 > and we're benefit from this change and can quickly build/test apps. > > For now, if I want to develop some feature or plugin, I can first > create a project by cli, then did some changes, but meanwhile it's > difficult to track which files got changed/added/removed, since all source > was not under source control. And it's also error prone to manually do the > tracking. The structure of cordova-x repos is different from the structure > in a development project. > > It was easier if there was an all-in-one project, I mean all > native sources in a single project, before 3.0. > > > Best Regards! > > > >
What's your daily workflow for cordova development?
Hi all, Cordova was separated into tens of individual repos ever since 3.0 and we're benefit from this change and can quickly build/test apps. For now, if I want to develop some feature or plugin, I can first create a project by cli, then did some changes, but meanwhile it's difficult to track which files got changed/added/removed, since all source was not under source control. And it's also error prone to manually do the tracking. The structure of cordova-x repos is different from the structure in a development project. It was easier if there was an all-in-one project, I mean all native sources in a single project, before 3.0. Best Regards!
