You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Andrew Grieve <ag...@google.com> on 2014/08/12 22:06:14 UTC
Feedback on "cordova plugin save" & friends
Played around with it and it's pretty clear to me that the ability to
record your plugins & platforms in config.xml is a big step up.
I do have some specific comments about the current design though:
- Right now the plugin save saves all plugins to config.xml rather than
just explicitly-installed plugins.
- For the shrinkwrap use-case, you actually do want to record dependent
plugins and their versions though, so it's still important for this case.
- Plugin restore doesn't work for locally installed plugins. e.g. try it
with mobilespec. It won't remember to look in the right spot for plugins.
- Really don't like that <feature> is used, since that could be confused by
the tools with the runtime config.xml's <feature> tag. Instead, I think the
syntax PGBuild uses would be better (minus the gap:)
http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
- Note there's a PR for adding <param> (CB-7142)
When I was playing with it, I found that I wished that is would just run
every time I added a plugin, rather than having to run the command
explicitly afterwards. Maybe we could add an environment variable that will
enable it while we're still experimenting? Then, too, we could make
platform / plugin restore a part of `prepare`.
Don't have the intention of picking up work on this in the near term, but
wanted to at least share the feedback since I did play around with it.
RE: Feedback on "cordova plugin save" & friends
Posted by Chuck Lantz <cl...@microsoft.com>.
For a "save," Git/local would require inspection of the .fetch.json file to determine the original source - but the problem is that plugman caches so the fetch source will appear to be the filesystem in most cases. That can probably be worked around, however.
We had this exact same need for the same reasons in Visual Studio and actually used the "feature" element with a custom vs: namespace to avoid the conflicts Andrew mentioned. In retrospect, plugins or dependency would have been better. I was interested when I saw this thread since we had been talking about revising and contributing something like it.
-Chuck
-----Original Message-----
From: Gorkem Ercan [mailto:gorkem.ercan@gmail.com]
Sent: Wednesday, August 13, 2014 3:37 AM
To: dev@cordova.apache.org
Cc: Parashuram Narasimhan (MS OPEN TECH)
Subject: Re: Feedback on "cordova plugin save" & friends
On Wed, Aug 13, 2014 at 01:21:24AM +0000, Chuck Lantz wrote:
> Yes, good point - Took a look at the PR with platforms - seems like a similar concept but using the engine element which as I think about it would probably be better anyway.
>
> <engines>
> <engine name="cordova-android" version="3.5.1"/>
> <engine name="cordova-ios" version="3.5.0"/> </engines>
>
> More consistent with the existing plugin.xml
>
> Would we need / want to support restoring from git repos or other non-official sources? My off-hand reaction is that is more useful for platform development than end-users. As long as platforms implementations are cached somewhere outside of the project itself as they are now it doesn't strike me that restoring from the local filesystem is needed as a perf measure either.
git repos is a good idea. Right now both plugins and engines are missing it. For the non-official sources we are bound with what CLI can support.
>
> -Chuck
>
> -----Original Message-----
> From: Parashuram Narasimhan (MS OPEN TECH)
> Sent: Tuesday, August 12, 2014 4:05 PM
> To: dev@cordova.apache.org; Chuck Lantz
> Subject: RE: Feedback on "cordova plugin save" & friends
>
> Given that we are looking at decoupling engine and platform releases, there should be ways to specify them separately, right ? In this case, I am assuming it is basically version of cordova-cli/cordova-lib and the platform, assuming that cordova-cli can work with older platform versions.
>
> -----Original Message-----
> From: Gorkem Ercan [mailto:gorkem.ercan@gmail.com]
> Sent: Tuesday, August 12, 2014 3:59 PM
> To: Chuck Lantz
> Cc: dev@cordova.apache.org
> Subject: Re: Feedback on "cordova plugin save" & friends
>
> On Tue, Aug 12, 2014 at 08:40:25PM +0000, Chuck Lantz wrote:
> > +1
> >
> > That same pattern could be applied to platforms actually with an additional version attribute:
> >
> > <platform name="android" version="3.5.1">
> > ... things like icons, splaschreens, and maybe even packaging details go here ...
> > </platform>
> >
> > We could also follow a similar model if we wanted to say what top
> > level cordova version was used to create the project by using the
> > engine element from plugin.xml
> >
> > <engine name="cordova" version="3.5.0" />
>
> Already had a PR [1] for saving and restoring platforms, that is MIA. Is there a specific reason why you want engines stated expilicitly, wouldn't platforms be sufficient.
>
> [1] https://github.com/apache/cordova-lib/pull/18
>
>
> >
> > -Chuck
> >
> > -----Original Message-----
> > From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of
> > Michal Mocny
> > Sent: Tuesday, August 12, 2014 1:34 PM
> > To: dev
> > Cc: Gorkem Ercan
> > Subject: Re: Feedback on "cordova plugin save" & friends
> >
> > <plugin> is nice, but why not just <dependency> as plugin.xml already uses?
> > config.xml and plugin.xml share lots of tags already, why fork here?
> >
> > -Michal
> >
> >
> > On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve <ag...@google.com> wrote:
> >
> > > Played around with it and it's pretty clear to me that the ability
> > > to record your plugins & platforms in config.xml is a big step up.
> > >
> > > I do have some specific comments about the current design though:
> > >
> > > - Right now the plugin save saves all plugins to config.xml rather
> > > than just explicitly-installed plugins.
> > > - For the shrinkwrap use-case, you actually do want to record
> > > dependent plugins and their versions though, so it's still important for this case.
> > > - Plugin restore doesn't work for locally installed plugins. e.g.
> > > try it with mobilespec. It won't remember to look in the right spot for plugins.
> > > - Really don't like that <feature> is used, since that could be
> > > confused by the tools with the runtime config.xml's <feature> tag.
> > > Instead, I think the syntax PGBuild uses would be better (minus
> > > the
> > > gap:) http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> > > - Note there's a PR for adding <param> (CB-7142)
> > >
> > > When I was playing with it, I found that I wished that is would
> > > just run every time I added a plugin, rather than having to run
> > > the command explicitly afterwards. Maybe we could add an
> > > environment variable that will enable it while we're still
> > > experimenting? Then, too, we could make platform / plugin restore a part of `prepare`.
> > >
> > > Don't have the intention of picking up work on this in the near
> > > term, but wanted to at least share the feedback since I did play around with it.
> > >
Re: Feedback on "cordova plugin save" & friends
Posted by Gorkem Ercan <go...@gmail.com>.
On Wed, Aug 13, 2014 at 01:21:24AM +0000, Chuck Lantz wrote:
> Yes, good point - Took a look at the PR with platforms - seems like a similar concept but using the engine element which as I think about it would probably be better anyway.
>
> <engines>
> <engine name="cordova-android" version="3.5.1"/>
> <engine name="cordova-ios" version="3.5.0"/>
> </engines>
>
> More consistent with the existing plugin.xml
>
> Would we need / want to support restoring from git repos or other non-official sources? My off-hand reaction is that is more useful for platform development than end-users. As long as platforms implementations are cached somewhere outside of the project itself as they are now it doesn't strike me that restoring from the local filesystem is needed as a perf measure either.
git repos is a good idea. Right now both plugins and engines are
missing it. For the non-official sources we are bound with what CLI can
support.
>
> -Chuck
>
> -----Original Message-----
> From: Parashuram Narasimhan (MS OPEN TECH)
> Sent: Tuesday, August 12, 2014 4:05 PM
> To: dev@cordova.apache.org; Chuck Lantz
> Subject: RE: Feedback on "cordova plugin save" & friends
>
> Given that we are looking at decoupling engine and platform releases, there should be ways to specify them separately, right ? In this case, I am assuming it is basically version of cordova-cli/cordova-lib and the platform, assuming that cordova-cli can work with older platform versions.
>
> -----Original Message-----
> From: Gorkem Ercan [mailto:gorkem.ercan@gmail.com]
> Sent: Tuesday, August 12, 2014 3:59 PM
> To: Chuck Lantz
> Cc: dev@cordova.apache.org
> Subject: Re: Feedback on "cordova plugin save" & friends
>
> On Tue, Aug 12, 2014 at 08:40:25PM +0000, Chuck Lantz wrote:
> > +1
> >
> > That same pattern could be applied to platforms actually with an additional version attribute:
> >
> > <platform name="android" version="3.5.1">
> > ... things like icons, splaschreens, and maybe even packaging details go here ...
> > </platform>
> >
> > We could also follow a similar model if we wanted to say what top
> > level cordova version was used to create the project by using the
> > engine element from plugin.xml
> >
> > <engine name="cordova" version="3.5.0" />
>
> Already had a PR [1] for saving and restoring platforms, that is MIA. Is there a specific reason why you want engines stated expilicitly, wouldn't platforms be sufficient.
>
> [1] https://github.com/apache/cordova-lib/pull/18
>
>
> >
> > -Chuck
> >
> > -----Original Message-----
> > From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal
> > Mocny
> > Sent: Tuesday, August 12, 2014 1:34 PM
> > To: dev
> > Cc: Gorkem Ercan
> > Subject: Re: Feedback on "cordova plugin save" & friends
> >
> > <plugin> is nice, but why not just <dependency> as plugin.xml already uses?
> > config.xml and plugin.xml share lots of tags already, why fork here?
> >
> > -Michal
> >
> >
> > On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve <ag...@google.com> wrote:
> >
> > > Played around with it and it's pretty clear to me that the ability
> > > to record your plugins & platforms in config.xml is a big step up.
> > >
> > > I do have some specific comments about the current design though:
> > >
> > > - Right now the plugin save saves all plugins to config.xml rather
> > > than just explicitly-installed plugins.
> > > - For the shrinkwrap use-case, you actually do want to record
> > > dependent plugins and their versions though, so it's still important for this case.
> > > - Plugin restore doesn't work for locally installed plugins. e.g.
> > > try it with mobilespec. It won't remember to look in the right spot for plugins.
> > > - Really don't like that <feature> is used, since that could be
> > > confused by the tools with the runtime config.xml's <feature> tag.
> > > Instead, I think the syntax PGBuild uses would be better (minus the
> > > gap:) http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> > > - Note there's a PR for adding <param> (CB-7142)
> > >
> > > When I was playing with it, I found that I wished that is would just
> > > run every time I added a plugin, rather than having to run the
> > > command explicitly afterwards. Maybe we could add an environment
> > > variable that will enable it while we're still experimenting? Then,
> > > too, we could make platform / plugin restore a part of `prepare`.
> > >
> > > Don't have the intention of picking up work on this in the near
> > > term, but wanted to at least share the feedback since I did play around with it.
> > >
RE: Feedback on "cordova plugin save" & friends
Posted by Chuck Lantz <cl...@microsoft.com>.
Yes, good point - Took a look at the PR with platforms - seems like a similar concept but using the engine element which as I think about it would probably be better anyway.
<engines>
<engine name="cordova-android" version="3.5.1"/>
<engine name="cordova-ios" version="3.5.0"/>
</engines>
More consistent with the existing plugin.xml
Would we need / want to support restoring from git repos or other non-official sources? My off-hand reaction is that is more useful for platform development than end-users. As long as platforms implementations are cached somewhere outside of the project itself as they are now it doesn't strike me that restoring from the local filesystem is needed as a perf measure either.
-Chuck
-----Original Message-----
From: Parashuram Narasimhan (MS OPEN TECH)
Sent: Tuesday, August 12, 2014 4:05 PM
To: dev@cordova.apache.org; Chuck Lantz
Subject: RE: Feedback on "cordova plugin save" & friends
Given that we are looking at decoupling engine and platform releases, there should be ways to specify them separately, right ? In this case, I am assuming it is basically version of cordova-cli/cordova-lib and the platform, assuming that cordova-cli can work with older platform versions.
-----Original Message-----
From: Gorkem Ercan [mailto:gorkem.ercan@gmail.com]
Sent: Tuesday, August 12, 2014 3:59 PM
To: Chuck Lantz
Cc: dev@cordova.apache.org
Subject: Re: Feedback on "cordova plugin save" & friends
On Tue, Aug 12, 2014 at 08:40:25PM +0000, Chuck Lantz wrote:
> +1
>
> That same pattern could be applied to platforms actually with an additional version attribute:
>
> <platform name="android" version="3.5.1">
> ... things like icons, splaschreens, and maybe even packaging details go here ...
> </platform>
>
> We could also follow a similar model if we wanted to say what top
> level cordova version was used to create the project by using the
> engine element from plugin.xml
>
> <engine name="cordova" version="3.5.0" />
Already had a PR [1] for saving and restoring platforms, that is MIA. Is there a specific reason why you want engines stated expilicitly, wouldn't platforms be sufficient.
[1] https://github.com/apache/cordova-lib/pull/18
>
> -Chuck
>
> -----Original Message-----
> From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal
> Mocny
> Sent: Tuesday, August 12, 2014 1:34 PM
> To: dev
> Cc: Gorkem Ercan
> Subject: Re: Feedback on "cordova plugin save" & friends
>
> <plugin> is nice, but why not just <dependency> as plugin.xml already uses?
> config.xml and plugin.xml share lots of tags already, why fork here?
>
> -Michal
>
>
> On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve <ag...@google.com> wrote:
>
> > Played around with it and it's pretty clear to me that the ability
> > to record your plugins & platforms in config.xml is a big step up.
> >
> > I do have some specific comments about the current design though:
> >
> > - Right now the plugin save saves all plugins to config.xml rather
> > than just explicitly-installed plugins.
> > - For the shrinkwrap use-case, you actually do want to record
> > dependent plugins and their versions though, so it's still important for this case.
> > - Plugin restore doesn't work for locally installed plugins. e.g.
> > try it with mobilespec. It won't remember to look in the right spot for plugins.
> > - Really don't like that <feature> is used, since that could be
> > confused by the tools with the runtime config.xml's <feature> tag.
> > Instead, I think the syntax PGBuild uses would be better (minus the
> > gap:) http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> > - Note there's a PR for adding <param> (CB-7142)
> >
> > When I was playing with it, I found that I wished that is would just
> > run every time I added a plugin, rather than having to run the
> > command explicitly afterwards. Maybe we could add an environment
> > variable that will enable it while we're still experimenting? Then,
> > too, we could make platform / plugin restore a part of `prepare`.
> >
> > Don't have the intention of picking up work on this in the near
> > term, but wanted to at least share the feedback since I did play around with it.
> >
RE: Feedback on "cordova plugin save" & friends
Posted by "Parashuram Narasimhan (MS OPEN TECH)" <pa...@microsoft.com>.
Given that we are looking at decoupling engine and platform releases, there should be ways to specify them separately, right ? In this case, I am assuming it is basically version of cordova-cli/cordova-lib and the platform, assuming that cordova-cli can work with older platform versions.
-----Original Message-----
From: Gorkem Ercan [mailto:gorkem.ercan@gmail.com]
Sent: Tuesday, August 12, 2014 3:59 PM
To: Chuck Lantz
Cc: dev@cordova.apache.org
Subject: Re: Feedback on "cordova plugin save" & friends
On Tue, Aug 12, 2014 at 08:40:25PM +0000, Chuck Lantz wrote:
> +1
>
> That same pattern could be applied to platforms actually with an additional version attribute:
>
> <platform name="android" version="3.5.1">
> ... things like icons, splaschreens, and maybe even packaging details go here ...
> </platform>
>
> We could also follow a similar model if we wanted to say what top
> level cordova version was used to create the project by using the
> engine element from plugin.xml
>
> <engine name="cordova" version="3.5.0" />
Already had a PR [1] for saving and restoring platforms, that is MIA. Is there a specific reason why you want engines stated expilicitly, wouldn't platforms be sufficient.
[1] https://github.com/apache/cordova-lib/pull/18
>
> -Chuck
>
> -----Original Message-----
> From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal
> Mocny
> Sent: Tuesday, August 12, 2014 1:34 PM
> To: dev
> Cc: Gorkem Ercan
> Subject: Re: Feedback on "cordova plugin save" & friends
>
> <plugin> is nice, but why not just <dependency> as plugin.xml already uses?
> config.xml and plugin.xml share lots of tags already, why fork here?
>
> -Michal
>
>
> On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve <ag...@google.com> wrote:
>
> > Played around with it and it's pretty clear to me that the ability
> > to record your plugins & platforms in config.xml is a big step up.
> >
> > I do have some specific comments about the current design though:
> >
> > - Right now the plugin save saves all plugins to config.xml rather
> > than just explicitly-installed plugins.
> > - For the shrinkwrap use-case, you actually do want to record
> > dependent plugins and their versions though, so it's still important for this case.
> > - Plugin restore doesn't work for locally installed plugins. e.g.
> > try it with mobilespec. It won't remember to look in the right spot for plugins.
> > - Really don't like that <feature> is used, since that could be
> > confused by the tools with the runtime config.xml's <feature> tag.
> > Instead, I think the syntax PGBuild uses would be better (minus the
> > gap:) http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> > - Note there's a PR for adding <param> (CB-7142)
> >
> > When I was playing with it, I found that I wished that is would just
> > run every time I added a plugin, rather than having to run the
> > command explicitly afterwards. Maybe we could add an environment
> > variable that will enable it while we're still experimenting? Then,
> > too, we could make platform / plugin restore a part of `prepare`.
> >
> > Don't have the intention of picking up work on this in the near
> > term, but wanted to at least share the feedback since I did play around with it.
> >
Re: Feedback on "cordova plugin save" & friends
Posted by Gorkem Ercan <go...@gmail.com>.
On Tue, Aug 12, 2014 at 09:21:10PM -0400, Andrew Grieve wrote:
> On Tue, Aug 12, 2014 at 6:58 PM, Gorkem Ercan <go...@gmail.com>
> wrote:
>
> > On Tue, Aug 12, 2014 at 08:40:25PM +0000, Chuck Lantz wrote:
> > > +1
> > >
> > > That same pattern could be applied to platforms actually with an
> > additional version attribute:
> > >
> > > <platform name="android" version="3.5.1">
> > > ... things like icons, splaschreens, and maybe even packaging
> > details go here ...
> > > </platform>
> > >
> > > We could also follow a similar model if we wanted to say what top level
> > cordova version was used to create the project by using the engine element
> > from plugin.xml
> > >
> > > <engine name="cordova" version="3.5.0" />
> >
> > Already had a PR [1] for saving and restoring platforms, that is MIA. Is
> > there a specific reason why you want engines stated expilicitly,
> > wouldn't platforms be sufficient.
> >
> > [1] https://github.com/apache/cordova-lib/pull/18
>
>
> This was merged (I did it :P)
>
> cordova save platforms --experimental
> Results in:
> <cdv:engine id="android" version="3.6.0-dev" />
Great, thanks.. This is why we need PTOs:. :)
>
>
> >
> >
> >
> > >
> > > -Chuck
> > >
> > > -----Original Message-----
> > > From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal
> > Mocny
> > > Sent: Tuesday, August 12, 2014 1:34 PM
> > > To: dev
> > > Cc: Gorkem Ercan
> > > Subject: Re: Feedback on "cordova plugin save" & friends
> > >
> > > <plugin> is nice, but why not just <dependency> as plugin.xml already
> > uses?
> > > config.xml and plugin.xml share lots of tags already, why fork here?
> > >
> > > -Michal
> > >
> > >
> > > On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve <ag...@google.com>
> > wrote:
> > >
> > > > Played around with it and it's pretty clear to me that the ability to
> > > > record your plugins & platforms in config.xml is a big step up.
> > > >
> > > > I do have some specific comments about the current design though:
> > > >
> > > > - Right now the plugin save saves all plugins to config.xml rather
> > > > than just explicitly-installed plugins.
> > > > - For the shrinkwrap use-case, you actually do want to record
> > > > dependent plugins and their versions though, so it's still important
> > for this case.
> > > > - Plugin restore doesn't work for locally installed plugins. e.g. try
> > > > it with mobilespec. It won't remember to look in the right spot for
> > plugins.
> > > > - Really don't like that <feature> is used, since that could be
> > > > confused by the tools with the runtime config.xml's <feature> tag.
> > > > Instead, I think the syntax PGBuild uses would be better (minus the
> > > > gap:) http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> > > > - Note there's a PR for adding <param> (CB-7142)
> > > >
> > > > When I was playing with it, I found that I wished that is would just
> > > > run every time I added a plugin, rather than having to run the command
> > > > explicitly afterwards. Maybe we could add an environment variable that
> > > > will enable it while we're still experimenting? Then, too, we could
> > > > make platform / plugin restore a part of `prepare`.
> > > >
> > > > Don't have the intention of picking up work on this in the near term,
> > > > but wanted to at least share the feedback since I did play around with
> > it.
> > > >
> >
Re: Feedback on "cordova plugin save" & friends
Posted by Andrew Grieve <ag...@chromium.org>.
On Tue, Aug 12, 2014 at 6:58 PM, Gorkem Ercan <go...@gmail.com>
wrote:
> On Tue, Aug 12, 2014 at 08:40:25PM +0000, Chuck Lantz wrote:
> > +1
> >
> > That same pattern could be applied to platforms actually with an
> additional version attribute:
> >
> > <platform name="android" version="3.5.1">
> > ... things like icons, splaschreens, and maybe even packaging
> details go here ...
> > </platform>
> >
> > We could also follow a similar model if we wanted to say what top level
> cordova version was used to create the project by using the engine element
> from plugin.xml
> >
> > <engine name="cordova" version="3.5.0" />
>
> Already had a PR [1] for saving and restoring platforms, that is MIA. Is
> there a specific reason why you want engines stated expilicitly,
> wouldn't platforms be sufficient.
>
> [1] https://github.com/apache/cordova-lib/pull/18
This was merged (I did it :P)
cordova save platforms --experimental
Results in:
<cdv:engine id="android" version="3.6.0-dev" />
>
>
>
> >
> > -Chuck
> >
> > -----Original Message-----
> > From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal
> Mocny
> > Sent: Tuesday, August 12, 2014 1:34 PM
> > To: dev
> > Cc: Gorkem Ercan
> > Subject: Re: Feedback on "cordova plugin save" & friends
> >
> > <plugin> is nice, but why not just <dependency> as plugin.xml already
> uses?
> > config.xml and plugin.xml share lots of tags already, why fork here?
> >
> > -Michal
> >
> >
> > On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve <ag...@google.com>
> wrote:
> >
> > > Played around with it and it's pretty clear to me that the ability to
> > > record your plugins & platforms in config.xml is a big step up.
> > >
> > > I do have some specific comments about the current design though:
> > >
> > > - Right now the plugin save saves all plugins to config.xml rather
> > > than just explicitly-installed plugins.
> > > - For the shrinkwrap use-case, you actually do want to record
> > > dependent plugins and their versions though, so it's still important
> for this case.
> > > - Plugin restore doesn't work for locally installed plugins. e.g. try
> > > it with mobilespec. It won't remember to look in the right spot for
> plugins.
> > > - Really don't like that <feature> is used, since that could be
> > > confused by the tools with the runtime config.xml's <feature> tag.
> > > Instead, I think the syntax PGBuild uses would be better (minus the
> > > gap:) http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> > > - Note there's a PR for adding <param> (CB-7142)
> > >
> > > When I was playing with it, I found that I wished that is would just
> > > run every time I added a plugin, rather than having to run the command
> > > explicitly afterwards. Maybe we could add an environment variable that
> > > will enable it while we're still experimenting? Then, too, we could
> > > make platform / plugin restore a part of `prepare`.
> > >
> > > Don't have the intention of picking up work on this in the near term,
> > > but wanted to at least share the feedback since I did play around with
> it.
> > >
>
Re: Feedback on "cordova plugin save" & friends
Posted by Gorkem Ercan <go...@gmail.com>.
On Tue, Aug 12, 2014 at 08:40:25PM +0000, Chuck Lantz wrote:
> +1
>
> That same pattern could be applied to platforms actually with an additional version attribute:
>
> <platform name="android" version="3.5.1">
> ... things like icons, splaschreens, and maybe even packaging details go here ...
> </platform>
>
> We could also follow a similar model if we wanted to say what top level cordova version was used to create the project by using the engine element from plugin.xml
>
> <engine name="cordova" version="3.5.0" />
Already had a PR [1] for saving and restoring platforms, that is MIA. Is
there a specific reason why you want engines stated expilicitly,
wouldn't platforms be sufficient.
[1] https://github.com/apache/cordova-lib/pull/18
>
> -Chuck
>
> -----Original Message-----
> From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal Mocny
> Sent: Tuesday, August 12, 2014 1:34 PM
> To: dev
> Cc: Gorkem Ercan
> Subject: Re: Feedback on "cordova plugin save" & friends
>
> <plugin> is nice, but why not just <dependency> as plugin.xml already uses?
> config.xml and plugin.xml share lots of tags already, why fork here?
>
> -Michal
>
>
> On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve <ag...@google.com> wrote:
>
> > Played around with it and it's pretty clear to me that the ability to
> > record your plugins & platforms in config.xml is a big step up.
> >
> > I do have some specific comments about the current design though:
> >
> > - Right now the plugin save saves all plugins to config.xml rather
> > than just explicitly-installed plugins.
> > - For the shrinkwrap use-case, you actually do want to record
> > dependent plugins and their versions though, so it's still important for this case.
> > - Plugin restore doesn't work for locally installed plugins. e.g. try
> > it with mobilespec. It won't remember to look in the right spot for plugins.
> > - Really don't like that <feature> is used, since that could be
> > confused by the tools with the runtime config.xml's <feature> tag.
> > Instead, I think the syntax PGBuild uses would be better (minus the
> > gap:) http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> > - Note there's a PR for adding <param> (CB-7142)
> >
> > When I was playing with it, I found that I wished that is would just
> > run every time I added a plugin, rather than having to run the command
> > explicitly afterwards. Maybe we could add an environment variable that
> > will enable it while we're still experimenting? Then, too, we could
> > make platform / plugin restore a part of `prepare`.
> >
> > Don't have the intention of picking up work on this in the near term,
> > but wanted to at least share the feedback since I did play around with it.
> >
RE: Feedback on "cordova plugin save" & friends
Posted by Chuck Lantz <cl...@microsoft.com>.
+1
That same pattern could be applied to platforms actually with an additional version attribute:
<platform name="android" version="3.5.1">
... things like icons, splaschreens, and maybe even packaging details go here ...
</platform>
We could also follow a similar model if we wanted to say what top level cordova version was used to create the project by using the engine element from plugin.xml
<engine name="cordova" version="3.5.0" />
-Chuck
-----Original Message-----
From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal Mocny
Sent: Tuesday, August 12, 2014 1:34 PM
To: dev
Cc: Gorkem Ercan
Subject: Re: Feedback on "cordova plugin save" & friends
<plugin> is nice, but why not just <dependency> as plugin.xml already uses?
config.xml and plugin.xml share lots of tags already, why fork here?
-Michal
On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve <ag...@google.com> wrote:
> Played around with it and it's pretty clear to me that the ability to
> record your plugins & platforms in config.xml is a big step up.
>
> I do have some specific comments about the current design though:
>
> - Right now the plugin save saves all plugins to config.xml rather
> than just explicitly-installed plugins.
> - For the shrinkwrap use-case, you actually do want to record
> dependent plugins and their versions though, so it's still important for this case.
> - Plugin restore doesn't work for locally installed plugins. e.g. try
> it with mobilespec. It won't remember to look in the right spot for plugins.
> - Really don't like that <feature> is used, since that could be
> confused by the tools with the runtime config.xml's <feature> tag.
> Instead, I think the syntax PGBuild uses would be better (minus the
> gap:) http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> - Note there's a PR for adding <param> (CB-7142)
>
> When I was playing with it, I found that I wished that is would just
> run every time I added a plugin, rather than having to run the command
> explicitly afterwards. Maybe we could add an environment variable that
> will enable it while we're still experimenting? Then, too, we could
> make platform / plugin restore a part of `prepare`.
>
> Don't have the intention of picking up work on this in the near term,
> but wanted to at least share the feedback since I did play around with it.
>
Re: Feedback on "cordova plugin save" & friends
Posted by Michal Mocny <mm...@chromium.org>.
<plugin> is nice, but why not just <dependency> as plugin.xml already uses?
config.xml and plugin.xml share lots of tags already, why fork here?
-Michal
On Tue, Aug 12, 2014 at 4:06 PM, Andrew Grieve <ag...@google.com> wrote:
> Played around with it and it's pretty clear to me that the ability to
> record your plugins & platforms in config.xml is a big step up.
>
> I do have some specific comments about the current design though:
>
> - Right now the plugin save saves all plugins to config.xml rather than
> just explicitly-installed plugins.
> - For the shrinkwrap use-case, you actually do want to record dependent
> plugins and their versions though, so it's still important for this case.
> - Plugin restore doesn't work for locally installed plugins. e.g. try it
> with mobilespec. It won't remember to look in the right spot for plugins.
> - Really don't like that <feature> is used, since that could be confused by
> the tools with the runtime config.xml's <feature> tag. Instead, I think the
> syntax PGBuild uses would be better (minus the gap:)
> http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> - Note there's a PR for adding <param> (CB-7142)
>
> When I was playing with it, I found that I wished that is would just run
> every time I added a plugin, rather than having to run the command
> explicitly afterwards. Maybe we could add an environment variable that will
> enable it while we're still experimenting? Then, too, we could make
> platform / plugin restore a part of `prepare`.
>
> Don't have the intention of picking up work on this in the near term, but
> wanted to at least share the feedback since I did play around with it.
>
Re: Feedback on "cordova plugin save" & friends
Posted by Gorkem Ercan <go...@gmail.com>.
On Tue, Aug 12, 2014 at 09:36:34PM -0400, Andrew Grieve wrote:
> On Tue, Aug 12, 2014 at 6:43 PM, Gorkem Ercan <go...@gmail.com>
> wrote:
>
> >
> > Just returning from PTO, great timing :)
> >
> :)
>
> >
> > On Tue, Aug 12, 2014 at 04:06:14PM -0400, Andrew Grieve wrote:
> > > Played around with it and it's pretty clear to me that the ability to
> > > record your plugins & platforms in config.xml is a big step up.
> > >
> > > I do have some specific comments about the current design though:
> > >
> > > - Right now the plugin save saves all plugins to config.xml rather than
> > > just explicitly-installed plugins.
> >
> > I agree, it should only save the explicitly installed plugins but I could
> > not see an easy way to extract that info and did not want to spend too
> > much time on it at the beginning.
> >
>
> I know that the info is stored in the android.json, ios.json, etc files,
> but I don't know how the exact details of finding it.
> @kamrik - do you know?
>
>
> >
> > > - For the shrinkwrap use-case, you actually do want to record dependent
> > > plugins and their versions though, so it's still important for this case.
> >
> > agreed.
> >
> > > - Plugin restore doesn't work for locally installed plugins. e.g. try it
> > > with mobilespec. It won't remember to look in the right spot for plugins.
> > > - Really don't like that <feature> is used, since that could be confused
> > by
> > > the tools with the runtime config.xml's <feature> tag. Instead, I think
> > the
> > > syntax PGBuild uses would be better (minus the gap:)
> > > http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> > > - Note there's a PR for adding <param> (CB-7142)
> > >
> >
> > <feature> tag looks off place because CLI generates platforms specific
> > config.xml files. If CLI adopted a single config.xml file that is just
> > copied over instead of being modified during platform builds, the
> > benefit of the <feature> tag would be more visible.
> >
> > Below is what is generated by Eclipse Thym for Device plugin when it is
> > installed on config.xml, all the info for the plugin is
> > under one tag, which makes it easier to manage for humans and tools.
> >
> > <feature name="Device">
> > <param name="firefoxos-package" value="Device" />
> > <param name="android-package" value="org.apache.cordova.device.Device" />
> > <param name="ios-package" value="CDVDevice" />
> > <param name="wp-package" value="Device" />
> > <param name="id" value="org.apache.cordova.device" />
> > <param name="version" value="0.2.11" />
> > </feature>
> >
>
> The issue I have with <feature>, is that the name="" attribute is used as
> an exec() bridge detail, and it's set by plugin.xml. Plugins can have
> multiple <feature>s, or no <feature>s at all, and there's no way to know
> the name="" before looking at the plugin.xml and inferring it. Even if CLI
> did use a shared config.xml, I think I'd still want to use <plugin>
> separate from <feature> (keep the parts that users shouldn't touch separate
> from the parts they can touch).
>
> Plus... <feature>... what the heck is a feature? I know what a plugin is,
> and a platform, but feature (as well as <dependency>), are generic terms
> that I don't think make obvious what they do. E.g. are platforms a
> feature/dependency? <platform> and <plugin> are more self-explanatory I
> think.
>
I agree.. <feature> is a horrible name to define plugins. I can
easily change the saved info to be in <cdv:plugin> tags, it makes little
difference and this is a convinient time to do it. I still prefer
everything related to a plugin collected under one tag perhaps we should retire
the <feature> tag and use the new one on the platform runtimes too.
>
>
> >
> > > When I was playing with it, I found that I wished that is would just run
> > > every time I added a plugin, rather than having to run the command
> > > explicitly afterwards. Maybe we could add an environment variable that
> > will
> > > enable it while we're still experimenting? Then, too, we could make
> > > platform / plugin restore a part of `prepare`.
> >
> > Initial implementation was actually part of the plugin add and
> > prepare. We did not have explicit save and restore commands at all.
> > Michal suggested that it was early for this feature so I came up with
> > the save and restore commands.
> >
> > On Eclipse Thym, I have it implemented so that every plugin installation
> > is "saved" to config.xml and plugins are auto restored when they are
> > detected
> > on config.xml. I am actually keeping plugins folder at this point just
> > to be compatible but I hope that we can get CLI to the same stage and
> > make the plugins folder a temporarily generated one that is not visible
> > to anyone.
> >
>
> Cool! How to you handle <asset>s if you don't actually use the plugins/
> directory? CLI has to copy them from plugins/ -> platforms on each prepare
> when constructing the www/.
The plugins directory may still exist but not as part of the project
tree because now config.xml carries all the info needed for it to be
generated. On CLI it can probably be implemented on prepare by generating
(or updating) a plugins folder on a temp folder as a build time artifact
and used from there.
>
>
> >
> > >
> > > Don't have the intention of picking up work on this in the near term, but
> > > wanted to at least share the feedback since I did play around with it.
> >
> > No worries, as long as somebody takes time to review and merge PRs, I
> > can keep the ball rolling.
> >
> > --
> > Gorkem
> >
Re: Feedback on "cordova plugin save" & friends
Posted by Andrew Grieve <ag...@google.com>.
On Tue, Aug 12, 2014 at 6:43 PM, Gorkem Ercan <go...@gmail.com>
wrote:
>
> Just returning from PTO, great timing :)
>
:)
>
> On Tue, Aug 12, 2014 at 04:06:14PM -0400, Andrew Grieve wrote:
> > Played around with it and it's pretty clear to me that the ability to
> > record your plugins & platforms in config.xml is a big step up.
> >
> > I do have some specific comments about the current design though:
> >
> > - Right now the plugin save saves all plugins to config.xml rather than
> > just explicitly-installed plugins.
>
> I agree, it should only save the explicitly installed plugins but I could
> not see an easy way to extract that info and did not want to spend too
> much time on it at the beginning.
>
I know that the info is stored in the android.json, ios.json, etc files,
but I don't know how the exact details of finding it.
@kamrik - do you know?
>
> > - For the shrinkwrap use-case, you actually do want to record dependent
> > plugins and their versions though, so it's still important for this case.
>
> agreed.
>
> > - Plugin restore doesn't work for locally installed plugins. e.g. try it
> > with mobilespec. It won't remember to look in the right spot for plugins.
> > - Really don't like that <feature> is used, since that could be confused
> by
> > the tools with the runtime config.xml's <feature> tag. Instead, I think
> the
> > syntax PGBuild uses would be better (minus the gap:)
> > http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> > - Note there's a PR for adding <param> (CB-7142)
> >
>
> <feature> tag looks off place because CLI generates platforms specific
> config.xml files. If CLI adopted a single config.xml file that is just
> copied over instead of being modified during platform builds, the
> benefit of the <feature> tag would be more visible.
>
> Below is what is generated by Eclipse Thym for Device plugin when it is
> installed on config.xml, all the info for the plugin is
> under one tag, which makes it easier to manage for humans and tools.
>
> <feature name="Device">
> <param name="firefoxos-package" value="Device" />
> <param name="android-package" value="org.apache.cordova.device.Device" />
> <param name="ios-package" value="CDVDevice" />
> <param name="wp-package" value="Device" />
> <param name="id" value="org.apache.cordova.device" />
> <param name="version" value="0.2.11" />
> </feature>
>
The issue I have with <feature>, is that the name="" attribute is used as
an exec() bridge detail, and it's set by plugin.xml. Plugins can have
multiple <feature>s, or no <feature>s at all, and there's no way to know
the name="" before looking at the plugin.xml and inferring it. Even if CLI
did use a shared config.xml, I think I'd still want to use <plugin>
separate from <feature> (keep the parts that users shouldn't touch separate
from the parts they can touch).
Plus... <feature>... what the heck is a feature? I know what a plugin is,
and a platform, but feature (as well as <dependency>), are generic terms
that I don't think make obvious what they do. E.g. are platforms a
feature/dependency? <platform> and <plugin> are more self-explanatory I
think.
>
> > When I was playing with it, I found that I wished that is would just run
> > every time I added a plugin, rather than having to run the command
> > explicitly afterwards. Maybe we could add an environment variable that
> will
> > enable it while we're still experimenting? Then, too, we could make
> > platform / plugin restore a part of `prepare`.
>
> Initial implementation was actually part of the plugin add and
> prepare. We did not have explicit save and restore commands at all.
> Michal suggested that it was early for this feature so I came up with
> the save and restore commands.
>
> On Eclipse Thym, I have it implemented so that every plugin installation
> is "saved" to config.xml and plugins are auto restored when they are
> detected
> on config.xml. I am actually keeping plugins folder at this point just
> to be compatible but I hope that we can get CLI to the same stage and
> make the plugins folder a temporarily generated one that is not visible
> to anyone.
>
Cool! How to you handle <asset>s if you don't actually use the plugins/
directory? CLI has to copy them from plugins/ -> platforms on each prepare
when constructing the www/.
>
> >
> > Don't have the intention of picking up work on this in the near term, but
> > wanted to at least share the feedback since I did play around with it.
>
> No worries, as long as somebody takes time to review and merge PRs, I
> can keep the ball rolling.
>
> --
> Gorkem
>
Re: Feedback on "cordova plugin save" & friends
Posted by Gorkem Ercan <go...@gmail.com>.
Just returning from PTO, great timing :)
On Tue, Aug 12, 2014 at 04:06:14PM -0400, Andrew Grieve wrote:
> Played around with it and it's pretty clear to me that the ability to
> record your plugins & platforms in config.xml is a big step up.
>
> I do have some specific comments about the current design though:
>
> - Right now the plugin save saves all plugins to config.xml rather than
> just explicitly-installed plugins.
I agree, it should only save the explicitly installed plugins but I could
not see an easy way to extract that info and did not want to spend too
much time on it at the beginning.
> - For the shrinkwrap use-case, you actually do want to record dependent
> plugins and their versions though, so it's still important for this case.
agreed.
> - Plugin restore doesn't work for locally installed plugins. e.g. try it
> with mobilespec. It won't remember to look in the right spot for plugins.
> - Really don't like that <feature> is used, since that could be confused by
> the tools with the runtime config.xml's <feature> tag. Instead, I think the
> syntax PGBuild uses would be better (minus the gap:)
> http://docs.build.phonegap.com/en_US/configuring_plugins.md.html
> - Note there's a PR for adding <param> (CB-7142)
>
<feature> tag looks off place because CLI generates platforms specific
config.xml files. If CLI adopted a single config.xml file that is just
copied over instead of being modified during platform builds, the
benefit of the <feature> tag would be more visible.
Below is what is generated by Eclipse Thym for Device plugin when it is
installed on config.xml, all the info for the plugin is
under one tag, which makes it easier to manage for humans and tools.
<feature name="Device">
<param name="firefoxos-package" value="Device" />
<param name="android-package" value="org.apache.cordova.device.Device" />
<param name="ios-package" value="CDVDevice" />
<param name="wp-package" value="Device" />
<param name="id" value="org.apache.cordova.device" />
<param name="version" value="0.2.11" />
</feature>
> When I was playing with it, I found that I wished that is would just run
> every time I added a plugin, rather than having to run the command
> explicitly afterwards. Maybe we could add an environment variable that will
> enable it while we're still experimenting? Then, too, we could make
> platform / plugin restore a part of `prepare`.
Initial implementation was actually part of the plugin add and
prepare. We did not have explicit save and restore commands at all.
Michal suggested that it was early for this feature so I came up with
the save and restore commands.
On Eclipse Thym, I have it implemented so that every plugin installation
is "saved" to config.xml and plugins are auto restored when they are detected
on config.xml. I am actually keeping plugins folder at this point just
to be compatible but I hope that we can get CLI to the same stage and
make the plugins folder a temporarily generated one that is not visible
to anyone.
>
> Don't have the intention of picking up work on this in the near term, but
> wanted to at least share the feedback since I did play around with it.
No worries, as long as somebody takes time to review and merge PRs, I
can keep the ball rolling.
--
Gorkem