I also added some comments. I think we have had a lot of good discussion on this, and should we looking at closing the proposal and working on an implementation ? We could resolve the open issues using a hangout - I also realize that we did not have a hangout for January.
Would this be a good excuse to set up a hangout ? I could volunteer to start the doodle and set up the date and time if people agree that we should do a hangout. This would be one of the topics we could discuss. On 1/17/15, 6:01 PM, "Andrew Grieve" <agri...@chromium.org> wrote: >Both proposals are sounding quite good to me at this point! There's merit >to both for sure. I left a few more comments, but the only one I actually >feel strongly about is about storing .fetch.json for platforms within the >existing platform.json files rather than a separate file. > >On Thu, Jan 15, 2015 at 8:08 PM, Mefire O. <ommen...@microsoft.com> wrote: > >> True. I'm still diving into the details of plugins and will update the >>doc >> accordingly. >> >> >> Sent from my Verizon Wireless 4G LTE smartphone >> >> >> -------- Original message -------- >> From: Gorkem Ercan >> Date:01/15/2015 4:56 PM (GMT-08:00) >> To: dev@cordova.apache.org >> Subject: Re: platforms/plugins save and restore from config.xml >> >> >> The proposal(s) seems to only cover the platforms. Although the >> behaviours are very similar there will be details that should be >> addressed. For instance how to handle the search path for plugins >> -- >> Gorkem >> >> On 15 Jan 2015, at 19:33, Mefire O. wrote: >> >> > After some suggestions to instead move to autosaving to config.xml, >> > I've made modifications the document : It now includes two proposals >> > : --save vs autosave >> > >> > Please review and make suggestions : >> > >> >>https://docs.google.com/document/d/1qKjhzSf48ybGg2GFZPtjXP8dkF4Z5Jnc7FU41 >>V3-jFc/edit >> > >> > >> > Thanks, >> > Mefire >> > >> > -----Original Message----- >> > From: Mefire O. [mailto:ommen...@microsoft.com] >> > Sent: Wednesday, January 14, 2015 4:44 PM >> > To: dev@cordova.apache.org >> > Subject: RE: platforms/plugins save and restore from config.xml >> > >> > All, >> > I have incorporated feedback into the Google docs as suggested by >> > others. Please, cast another look. >> > For reviews/ comments/suggestions, please take a look at : >> > >> >>https://docs.google.com/document/d/1qKjhzSf48ybGg2GFZPtjXP8dkF4Z5Jnc7FU41 >>V3-jFc/edit >> > >> > It seems to me like most people agree with the proposed behavior of >> > --save. So, could anyone please review these pull requests that >> > include that functionality ? : >> > - https://github.com/apache/cordova-lib/pull/144 >> > - https://github.com/apache/cordova-cli/pull/203 >> > >> > Also, we have another related pull request that introduce git urls >> > support to 'cordova platform add' : >> > - https://github.com/apache/cordova-lib/pull/148 >> > >> > Thanks for all the feedback so far ! >> > I'll be creating JIRA issues for all the suggestions (those that have >> > been agreed on). And start working on some of them... >> > >> > >> > Thanks, >> > Mefire >> > >> > >> > -----Original Message----- >> > From: Chuck Lantz [mailto:cla...@microsoft.com] >> > Sent: Wednesday, January 14, 2015 1:15 PM >> > To: dev@cordova.apache.org >> > Subject: RE: platforms/plugins save and restore from config.xml >> > >> > For those joining the thread late - Here's the Google doc link that's >> > trying to consolidate the conversation: >> > >> >>https://docs.google.com/document/d/1qKjhzSf48ybGg2GFZPtjXP8dkF4Z5Jnc7FU41 >>V3-jFc/edit >> > >> > -Chuck >> > >> > -----Original Message----- >> > From: Chuck Lantz [mailto:cla...@microsoft.com] >> > Sent: Wednesday, January 14, 2015 1:11 PM >> > To: dev@cordova.apache.org >> > Subject: RE: platforms/plugins save and restore from config.xml >> > >> > You may also want to mention you tried to factor this conversation >> > into the google doc and repoint them to it once you're done editing. >> > >> > Before you do that, I'd also add our proposed <plugin> syntax in that >> > section before you send it out. Maybe use "strikethrough" on the XML >> > section with the <feature> elements and add the <plugin id=""...> >> > syntax below it. >> > >> > -Chuck >> > >> > -----Original Message----- >> > From: Mefire O. [mailto:ommen...@microsoft.com] >> > Sent: Tuesday, January 13, 2015 4:12 PM >> > To: dev@cordova.apache.org >> > Subject: RE: platforms/plugins save and restore from config.xml >> > >> > This PR adds support for git-urls to 'cordova platform add' : >> > https://github.com/apache/cordova-lib/pull/148 >> > Please, review. >> > >> > Thanks, >> > Mefire >> > >> > -----Original Message----- >> > From: Treggiari, Leo [mailto:leo.treggi...@intel.com] >> > Sent: Tuesday, January 13, 2015 8:18 AM >> > To: dev@cordova.apache.org >> > Subject: RE: platforms/plugins save and restore from config.xml >> > >> > I agree with always saving and automatically re-fetching sources and >> > platforms when needed. With regards to the other conversation going >> > on re: automatic add of a platform, I think the CLI should >> > automatically do things when it is reasonably unambiguous what the >> > user wants - e.g. if they explicitly say build for iOS then CLI adds >> > the platform if it is needed. If you are on Windows and you say build >> > for iOS, you get an error, which you would even if CLI had allowed you >> > to add the platform - e.g. for a cross platform, multi-developer >> > scenario. >> > >> > If save/restore are 'optional', then as others have pointed out, other >> > problems cannot be solved unless the user has used the save and >> > restore command/options. I don't want my IDE to be saying: "didn't I >> > tell you that you need to use the save/restore command options if you >> > want to do any operations outside of the IDE!". >> > >> > Leo >> > >> > -----Original Message----- >> > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of >> > Andrew Grieve >> > Sent: Tuesday, January 13, 2015 6:57 AM >> > To: Gorkem Ercan >> > Cc: dev; Andrew Grieve; Michael Brooks >> > Subject: Re: platforms/plugins save and restore from config.xml >> > >> > Saving all the time certainly would make this simpler. If we save all >> > of the time, we can also make uninstall a part of prepare. E.g. If >> > users edits their config.xml and removes a <plugin>, then prepare can >> > detect that and plugman uninstall it before building. If we don't >> > always save, then editing your config.xml wouldn't be that meaningful >> > unless you delete & recreate platforms every time. >> > >> > On Mon, Jan 12, 2015 at 10:29 PM, Gorkem Ercan >> > <gorkem.er...@gmail.com> >> > wrote: >> > >> >> >> >> >> >> On 12 Jan 2015, at 22:09, Andrew Grieve wrote: >> >> >> >> Related to this, but maybe can be discussed outside of the doc just >> >> fine: >> >>> >> >>> https://issues.apache.org/jira/browse/CB-4275 >> >>> >> >>> Right now when we add a new platform, we do a for-each on >> >>> directories >> >>> within plugins/ and add them as well. This causes all plugins to >> >>> wind >> >>> up as top-level plugins even when they are dependent plugins on >> >>> existing platforms. >> >>> >> >>> Having plugins listed in config.xml, I think it would make sense to >> >>> change this logic to plugin add based on plugins within config.xml >> >>> rather than directories that exist within plugins. We could >> >>> potentially still add all of them if no plugins are listed in >> >>> config.xml for backwards compat. >> >>> >> >>> >> >> Related to that, I was looking at CB-8278[1] this bug not only causes >> >> the variables to be lost also it causes the top-level plugin info to >> >> vanish as well. >> >> We could also fix this problem easier too if we are saving plugins to >> >> config.xml all the time. Which means no save command or --save. >> >> >> >> [1] https://issues.apache.org/jira/browse/CB-8278 >> >> >> >> >> >> >> >>> >> >>> On Mon, Jan 12, 2015 at 9:19 PM, Andrew Grieve >> >>> <agri...@chromium.org> >> >>> wrote: >> >>> >> >>> Thanks for putting the doc together. Added some comments to it. >> >>>> >> >>>> On Mon, Jan 12, 2015 at 5:39 PM, Mefire O. <ommen...@microsoft.com> >> >>>> wrote: >> >>>> >> >>>> Google docs link : >> >>>>> https://docs.google.com/document/d/1qKjhzSf48ybGg2GFZPtjXP8dkF4Z5 >> >>>>> Jnc7FU41V3-jFc/edit >> >>>>> >> >>>>> Thanks, >> >>>>> Mefire >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Mefire O. [mailto:ommen...@microsoft.com] >> >>>>> Sent: Monday, January 12, 2015 2:12 PM >> >>>>> To: dev@cordova.apache.org >> >>>>> Cc: Michael Brooks >> >>>>> Subject: RE: platforms/plugins save and restore from config.xml >> >>>>> >> >>>>> Here's what I propose, let me know what you think : >> >>>>> >> >>>>> 'cordova platform add' >> >>>>> * No -save flag, No 'autosave' setting in >> >>>>> project_dir/.cordova/config.json >> >>>>> 1. 'cordova platform add android' => restores the >> >>>>> android platform from config.xml. If config.xml doesn't have any >> >>>>> android engine, falls back to using the pinned CLI version. >> >>>>> * With -save flag or 'autosave' setting in >> >>>>> project_dir/.cordova/config.json >> >>>>> 1. 'cordova platform add >> >>>>> https://github.com/apache/cordova-android.git -save' => clones the >> >>>>> git repo and adds the android platform to the project, then >> >>>>> updates >> >>>>> config.xml and point its version to the specified git-url. >> >>>>> 2. 'cordova platform add android@ >> >>>>> https://github.com/apache/cordova-android.git -save' => clones the >> >>>>> git repo and adds the android platform to the project, then >> >>>>> updates >> >>>>> config.xml and point its version to the specified git-url. >> >>>>> 3. 'cordova platform add C:/path/to/android/platform >> >>>>> -save' => adds the android platform to the project, then updates >> >>>>> config.xml and point its version to the specified folder location. >> >>>>> * --Save flag is used in CLI-based workflows, and 'autosave' >> >>>>> (project_dir/.cordova/config.json) is used in IDE-based workflows. >> >>>>> >> >>>>> 'cordova save platforms' >> >>>>> In its current behavior, 'cordova save platforms' retrieves >> >>>>> all the platforms currently installed on the project, and saves >> >>>>> them to config.xml. However, unlike 'cordova save plugins', it >> >>>>> does >> >>>>> not save the source of the platform (i.e: git-url, folder >> >>>>> location), it only saves the version. This behavior is different >> >>>>> from the one that 'cordova save plugins' implements. >> >>>>> * 'cordova save platforms' => it should retrieve the sources >> >>>>> of all the installed platforms from .fetch.json, and save them in >> >>>>> config.xml. >> >>>>> This requires making changes to the way that 'cordova platform >> >>>>> add' >> >>>>> works, >> >>>>> it should always save the source in .fetch.json. >> >>>>> * In case of conflict with the config.xml, 'cordova save >> >>>>> platforms' should error out. The -force option shall be used if we >> >>>>> want it to override config.xml content. >> >>>>> >> >>>>> 'cordova restore platforms' >> >>>>> It reads the config.xml file and install all the platforms >> >>>>> specified there. >> >>>>> >> >>>>> 'cordova save' >> >>>>> Saves all installed platforms and plugins into config.xml >> >>>>> >> >>>>> 'cordova restore' >> >>>>> Restores all platforms and plugins from config.xml. similar to >> >>>>> 'npm install'. >> >>>>> >> >>>>> Here the link to the google docs : >> >>>>> >> >>>>> Thanks, >> >>>>> Mefire >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com] >> >>>>> Sent: Friday, January 9, 2015 1:09 PM >> >>>>> To: dev@cordova.apache.org >> >>>>> Cc: Michael Brooks >> >>>>> Subject: Re: platforms/plugins save and restore from config.xml >> >>>>> >> >>>>> Regarding save - I think automatic save could be an issue for >> >>>>> folks >> >>>>> who want to "try out" experimental platforms, or pick up platforms >> >>>>> from git URIs or master branches. What would happen in that case? >> >>>>> May be that's is why npm --save exists in the first place. >> >>>>> >> >>>>> Where to save - For making progress, looks like we will also have >> >>>>> to finalize if it will be persisted in config.xml or in >> >>>>> package.json. Most IDEs will not use the --save option, but may >> >>>>> choose to directly persist in the required file when a platform is >> >>>>> added using a GUI. >> >>>>> >> >>>>> Regarding restore - automatic restore makes a lot of sense. Does >> >>>>> mefire's PR not cover that ? >> >>>>> >> >>>>> From: Chuck Lantz<mailto:cla...@microsoft.com> >> >>>>> Sent: ?Friday?, ?January? ?9?, ?2015 ?12?:?43? ?PM >> >>>>> To: dev@cordova.apache.org<mailto:dev@cordova.apache.org> >> >>>>> Cc: Michael Brooks<mailto:mbro...@adobe.com> >> >>>>> >> >>>>> +1 on automating. >> >>>>> >> >>>>> That's why Mefire's PR for platform add just uses the version >> >>>>> information in config.xml if it is present. I think the idea >> >>>>> behind "--save" was to make this npm-like so that if a value is >> >>>>> already in config.xml, then you can also update it by specifying a >> >>>>> different version and "saving" it. >> >>>>> (Similar to how "npm install cordova@4.1.2 --save" would update >> >>>>> package.json in the directory you're executing the command even if >> >>>>> an earlier version was present). He mentioned the two PRs on the >> >>>>> "--save" >> >>>>> for >> >>>>> platform earlier in the this thread. >> >>>>> >> >>>>> As an improvement it could just "save" by default if there is >> >>>>> nothing present in config.xml. Personally I'd always use >> >>>>> "--save". >> >>>>> I also agree what we do for platforms we should likely do for >> >>>>> plugins too. >> >>>>> >> >>>>> Now, we had originally said in a hangout that "config.xml" should >> >>>>> contain "app stuff" and that platform and plugin versions and >> >>>>> preferences/params qualified as app stuff. We could certainly go >> >>>>> towards package.json (or something package.json-like) since that's >> >>>>> really what we're trying to emulate here at the end of the day I >> >>>>> think. However, I also thought we said that config.xml was too >> >>>>> engrained to move away from it (though clearly the web as a whole >> >>>>> is moving towards the W3C app manifest). >> >>>>> >> >>>>> If we don't use config.xml, it definitely needs to be a document >> >>>>> at >> >>>>> the root level not under ".cordova" since you should clearly check >> >>>>> it into source control and it shouldn't be hidden. It's details >> >>>>> about the app not how the CLI should behave. >> >>>>> >> >>>>> -Chuck >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Josh Soref [mailto:jso...@blackberry.com] >> >>>>> Sent: Friday, January 9, 2015 11:26 AM >> >>>>> To: dev@cordova.apache.org >> >>>>> Cc: Michael Brooks >> >>>>> Subject: Re: platforms/plugins save and restore from config.xml >> >>>>> >> >>>>> Leo wrote: >> >>>>> >> >>>>>> I had asked some questions about save and restore a while back >> >>>>>> >> >>>>> >> >>>>> One of my biggest questions was why would these commands be an >> >>>>> option? >> >>>>>> >> >>>>> >> >>>>> I can't think of any reasons. >> >>>>> >> >>>>> What I'm looking for, as soon as possible, is that Cordova >> >>>>> 'project' >> >>>>>> metadata is stored logically and consistently so that the CLI and >> >>>>>> multiple IDEs could simultaneously work on the same project and >> >>>>>> know about what each other have done wrt. adding/removing >> >>>>>> plugins/platforms/etc. >> >>>>>> >> >>>>> >> >>>>> Seems reasonable >> >>>>> >> >>>>> Does removing experimental advance that goal or does it, as Michal >> >>>>>> says, put obstacles in the path of getting there by requiring >> >>>>>> long >> >>>>>> term support of an incomplete and possibly confusing (more >> >>>>>> options?) solution? >> >>>>>> >> >>>>> >> >>>>> I think Michal is right. >> >>>>> >> >>>>> It probably makes more sense to integrate the code behind >> >>>>> save/restore into (platform|plugin) add and (something) so that it >> >>>>> automatically just works. >> >>>>> >> >>>>> I'm not sure offhand what 'restore' would look like in a such a >> >>>>> model though... >> >>>>> Also worth considering is the recent request for `cordova run >> >>>>> not-installed-platform` >> >>>>> >> >>>>> `cordova run not-installed-platform` (CB-8283) should honor the >> >>>>> values from `cordova platform save` >> >>>>> >> >>>>> That might be the replacement for 'restore', although it probably >> >>>>> isn't ideal... >> >>>>> >> >>>>> >>------------------------------------------------------------------- >> >>>>> -- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> >>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >> >>>>> >> >>>>> >> >>>>> >>------------------------------------------------------------------- >> >>>>> -- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> >>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >> >>>>> >> >>>>> >> >>>>> >> >>>> >> > B >> > KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB >> > [ X ܚX K K[XZ[ ] ][ X ܚX P ܙ ݘK \ X K ܙ B >> > ܈ Y ] [ۘ[ [X[ K[XZ[ ] Z [ ܙ ݘK \ X K ܙ B B >> > KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB >> > [ X ܚX K K[XZ[ ] ][ X ܚX P ܙ ݘK \ X K ܙ B >> > ܈ Y ] [ۘ[ [X[ K[XZ[ ] Z [ ܙ ݘK \ X K ܙ B B >> > KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB >> > [ X ܚX K K[XZ[ ] ][ X ܚX P ܙ ݘK \ X K ܙ B >> > ܈ Y ] [ۘ[ [X[ K[XZ[ ] Z [ ܙ ݘK \ X K ܙ B >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> > For additional commands, e-mail: dev-h...@cordova.apache.org >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> > For additional commands, e-mail: dev-h...@cordova.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> For additional commands, e-mail: dev-h...@cordova.apache.org >> >>
