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 ad
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. Th
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
> forw
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
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
creat
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
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
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
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 alre
+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` a
> 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 c
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
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 iss
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,
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.
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 do
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,
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 beg
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: mayb
+ 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.
+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 ./p
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 o
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!
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 automa
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
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
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
> >
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
28 matches
Mail list logo
