RE: Feedback on "cordova plugin save" & friends
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.er...@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 +, 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. > > > > > > 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.er...@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 +, Chuck Lantz wrote: > > +1 > > > > That same pattern could be applied to platforms actually with an additional > > version attribute: > > > > > > ... things like icons, splaschreens, and maybe even packaging details > > go here ... > > > > > > 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 > > > > > > 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: mmo...@google.com [mailto:mmo...@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 > > > > is nice, but why not just 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 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. >
Re: Feedback on "cordova plugin save" & friends
On Wed, Aug 13, 2014 at 01:21:24AM +, 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. > > > > > > > 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.er...@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 +, Chuck Lantz wrote: > > +1 > > > > That same pattern could be applied to platforms actually with an additional > > version attribute: > > > > > > ... things like icons, splaschreens, and maybe even packaging details > > go here ... > > > > > > 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 > > > > > > 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: mmo...@google.com [mailto:mmo...@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 > > > > is nice, but why not just 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 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 is used, since that could be > > > confused by the tools with the runtime config.xml's 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 (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
On Tue, Aug 12, 2014 at 09:21:10PM -0400, Andrew Grieve wrote: > On Tue, Aug 12, 2014 at 6:58 PM, Gorkem Ercan > wrote: > > > On Tue, Aug 12, 2014 at 08:40:25PM +, Chuck Lantz wrote: > > > +1 > > > > > > That same pattern could be applied to platforms actually with an > > additional version attribute: > > > > > > > > > ... things like icons, splaschreens, and maybe even packaging > > details go here ... > > > > > > > > > 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 > > > > > > > > > > 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: > Great, thanks.. This is why we need PTOs:. :) > > > > > > > > > > > > > > -Chuck > > > > > > -Original Message- > > > From: mmo...@google.com [mailto:mmo...@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 > > > > > > is nice, but why not just 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 > > 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 is used, since that could be > > > > confused by the tools with the runtime config.xml's 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 (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
On Tue, Aug 12, 2014 at 09:36:34PM -0400, Andrew Grieve wrote: > On Tue, Aug 12, 2014 at 6:43 PM, Gorkem Ercan > 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 is used, since that could be confused > > by > > > the tools with the runtime config.xml's 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 (CB-7142) > > > > > > > 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 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. > > > > > > > > > > > > > > > > > > > > > > The issue I have with , is that the name="" attribute is used as > an exec() bridge detail, and it's set by plugin.xml. Plugins can have > multiple s, or no 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 > separate from (keep the parts that users shouldn't touch separate > from the parts they can touch). > > Plus... ... what the heck is a feature? I know what a plugin is, > and a platform, but feature (as well as ), are generic terms > that I don't think make obvious what they do. E.g. are platforms a > feature/dependency? and are more self-explanatory I > think. > I agree.. is a horrible name to define plugins. I can easily change the saved info to be in 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 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 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
Re: Feedback on "cordova plugin save" & friends
On Tue, Aug 12, 2014 at 6:43 PM, Gorkem Ercan 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 is used, since that could be confused > by > > the tools with the runtime config.xml's 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 (CB-7142) > > > > 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 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. > > > > > > > > > > The issue I have with , is that the name="" attribute is used as an exec() bridge detail, and it's set by plugin.xml. Plugins can have multiple s, or no 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 separate from (keep the parts that users shouldn't touch separate from the parts they can touch). Plus... ... what the heck is a feature? I know what a plugin is, and a platform, but feature (as well as ), are generic terms that I don't think make obvious what they do. E.g. are platforms a feature/dependency? and 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 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
On Tue, Aug 12, 2014 at 6:58 PM, Gorkem Ercan wrote: > On Tue, Aug 12, 2014 at 08:40:25PM +, Chuck Lantz wrote: > > +1 > > > > That same pattern could be applied to platforms actually with an > additional version attribute: > > > > > > ... things like icons, splaschreens, and maybe even packaging > details go here ... > > > > > > 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 > > > > > > 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: > > > > > > > -Chuck > > > > -Original Message- > > From: mmo...@google.com [mailto:mmo...@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 > > > > is nice, but why not just 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 > 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 is used, since that could be > > > confused by the tools with the runtime config.xml's 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 (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
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. 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.er...@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 +, Chuck Lantz wrote: > +1 > > That same pattern could be applied to platforms actually with an additional > version attribute: > > > ... things like icons, splaschreens, and maybe even packaging details > go here ... > > > 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 > > 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: mmo...@google.com [mailto:mmo...@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 > > is nice, but why not just 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 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 is used, since that could be > > confused by the tools with the runtime config.xml's 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 (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
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.er...@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 +, Chuck Lantz wrote: > +1 > > That same pattern could be applied to platforms actually with an additional > version attribute: > > > ... things like icons, splaschreens, and maybe even packaging details > go here ... > > > 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 > > 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: mmo...@google.com [mailto:mmo...@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 > > is nice, but why not just 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 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 is used, since that could be > > confused by the tools with the runtime config.xml's 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 (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
On Tue, Aug 12, 2014 at 08:40:25PM +, Chuck Lantz wrote: > +1 > > That same pattern could be applied to platforms actually with an additional > version attribute: > > > ... things like icons, splaschreens, and maybe even packaging details > go here ... > > > 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 > > 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: mmo...@google.com [mailto:mmo...@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 > > is nice, but why not just 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 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 is used, since that could be > > confused by the tools with the runtime config.xml's 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 (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
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 is used, since that could be confused by > the tools with the runtime config.xml's 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 (CB-7142) > 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 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. > 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
RE: Feedback on "cordova plugin save" & friends
+1 That same pattern could be applied to platforms actually with an additional version attribute: ... things like icons, splaschreens, and maybe even packaging details go here ... 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 -Chuck -Original Message- From: mmo...@google.com [mailto:mmo...@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 is nice, but why not just 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 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 is used, since that could be > confused by the tools with the runtime config.xml's 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 (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
is nice, but why not just 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 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 is used, since that could be confused by > the tools with the runtime config.xml's 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 (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. >
