cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gorkem Ercan <gorkem.er...@gmail.com>
Subject Re: cordova plugin save
Date Thu, 14 Aug 2014 08:15:59 GMT

The goal with the save/restore work is to make it as convenient as
possible to share cordova projects, so Chuck was right on the money. We
also have an accompanying "save/restore platforms" command. Once the
work is complete CLI should be able to restore plugins and platforms
folders of a shared project with the plugins installed and platforms
that was worked on.

I actually think of config.xml as an app metadata file. Another of my
ramblings has been to have a single config.xml and remove the
need for platform specific ones. So I would prefer to avoid putting data that
is not relevant at runtime to config.xml.

For instance, Eclipse Thym [1] ,that I work on, uses config.json to save 
the engine information. I tend to think it is a more proper place for
it.

Answers to some of your questions. 

> -  Where does 'save' find the definitive list of plugins that it should save?  There
may be some plugins specified in config.xml and there are other metadata (<platform>.json)
 files that believe they know the list.
  The list of plugins is simply a list of directories under the plugins folder
> -  What does it save and where?  Does it save the argument that was passed to 'corodva
platform add xxx'?  Does it save the id, (and possibly additional information) from the sources
that were actually fetched?
  It saves the id and if shrinkwrap flag is set also the installed
  version to the config.xml. It does not use the information passed to
  "cordova platform add". The plan is to add git url information to be saved
  when appropriate  so that plugins that were installed using git can be
  restored too. 
> -  Can 'restore' be guaranteed to fetch the same exact sources that were in the project
that was 'save'd?  Does it need to?
  If shrinkwrap is set then restore will restore the exact version of
  the plugin from the registry. Otherwise it will get the latest
  available. In case of git URL it will be whatever that URL points to.

[1] http://www.eclipse.org/thym

--
Gorkem

On Thu, Aug 14, 2014 at 02:14:32AM +0000, Chuck Lantz wrote:
> Yeah I guess what I'm getting at is it is more of an app descriptor. It describes things
about the app that are immutable across the native underlying projects used to build the app,
different IDEs, or project structures. If there was a way to import and export Cordova apps
across any number of IDEs or products and services (PhoneGap Build, WorkLight, Intel, Telerik,
etc) there are a set of things about the app that wouldn't change. A transformed version of
config.xml lands in underlying native projects in the platforms folder as well.
> 
> Another example, lets say that Gulp becomes the build system instead of the CLI (not
saying that will happen - just jumping to an extreme). We need a place to keep the things
that would not change.
> 
> Speaking for VS, I would never put typescript compilation settings, build configs, and
other IDE settings that pertain to the app project in config.xml. That's specific to the VS
world and belongs in the VS project. Similarly I would not force a project structure on another
IDE let alone someone hand editing config.xml in sublime text. Most likely will not change
from the CLI structure anyway.
> 
> Now, how that is presented to the developer is a completely different story.
> 
> Whether config.xml is the right long term place for what I describe is another topic
entirely.  It's pretty engrained. I do think it will be important to easily separate the concepts,
however.
> 
> On the other questions - hop on that thread. I didn't make the PR so I can only speak
to the code verses the exact intent. :) The issue is that there is no single definitive list
of plugins or platforms to install today (plugins pull in dependencies for specific platforms
so the contents of the plugins folder is actually not the definitive list).  That's what it
was trying to fix.
> ________________________________
> From: Treggiari, Leo<mailto:leo.treggiari@intel.com>
> Sent: ‎8/‎13/‎2014 6:48 PM
> To: Chuck Lantz<mailto:clantz@microsoft.com>; dev@cordova.apache.org<mailto:dev@cordova.apache.org>
> Cc: Treggiari, Leo<mailto:leo.treggiari@intel.com>
> Subject: RE: cordova plugin save
> 
> Hi Chuck,
> 
> Thanks for adding the other 'app metadata file' (like AndroidManifest.xml or package.appxmanifest.xml.)
to the conversation.  It's important to consider that as well.  Those are somewhat different
because they contain information that is not built into the app executable, but rather handled
by an installer or loader.  Does that make those settings somehow different to the app developer?
 I'm not sure.  But I'm sure you're right that items in the existing set of metadata files
affect all of the app executable, the accompanying app 'manifest' file, and the accompanying
cordova.js file.
> 
> To start, I'm not sure that it makes sense to add any new metadata to the app config.xml
file.  I'm not sure that, because of its history, it fits cleanly into any metadata category
we might want to define.  Maybe a new file is needed.  Others than I are better suited to
judge that since I don't have the Cordova history.
> 
> However, I don't agree with some of the categorizations you've made.  I don't see why
the list of plugins your app uses is a different kind of metadata than the directories where
you would find portable sources, plugins, merge sources, etc.  Both are required to fully
define how to build the app based upon a set of sources pulled from a repository.  Thinking
in terms of a Visual Studio example, wouldn't both be defined in a single project file?  More
files just leads to more things to maintain and accidentally overlook.
> 
> > The idea behind  save/restore is to make it easier to share a project and reduce
the amount of redundant code that you'd check in to a source repo.  (You could omit the plugins
and platforms folders from source control and then "restore".)
> 
> So is that the primary use case for the new commands?  I didn't realize that from the
discussion I had read, but now I understand.  I  thought it was specifically recommended to
not put the platforms folder under source code control.  So, the savings could come with the
plugins folder.  There are, at least, a couple of issues/questions with this that have already
been mentioned (just adding them here to keep them in one place...):
> -  Where does 'save' find the definitive list of plugins that it should save?  There
may be some plugins specified in config.xml and there are other metadata (<platform>.json)
 files that believe they know the list.
> -  What does it save and where?  Does it save the argument that was passed to 'corodva
platform add xxx'?  Does it save the id, (and possibly additional information) from the sources
that were actually fetched?
> -  Can 'restore' be guaranteed to fetch the same exact sources that were in the project
that was 'save'd?  Does it need to?
> 
> Thanks,
> Leo
> 
> -----Original Message-----
> From: Chuck Lantz [mailto:clantz@microsoft.com]
> Sent: Wednesday, August 13, 2014 3:58 PM
> To: dev@cordova.apache.org; Treggiari, Leo
> Subject: RE: cordova plugin save
> 
> My two cents - there are three things here:
> 
> 1. App metadata
> 2. Project metadata
> 3. Workspace metadata
> 
> $project/.cordova/config.json is probably the closest thing to an IDE project file. The
closest thing to workspace level settings is $home/.cordova/config.json.
> 
> Given config.xml's roots, it's more of an app metadata file like AndroidManifest.xml
or package.appxmanifest.xml.  Its contents should describe the app intendant of IDE or build
system (as far as that is possible). So, regarding, "The newly proposed metadata for specifying
project directory structure would be part of this metadata," I don't think config.xml is the
right place for that. It's build system config - which I believe belongs in config.json. Plugins
in many ways equate to capabilities or intents which is why that makes sense to exist in config.xml.
 The platforms that the app is designed to target also by extension appear to make sense (though
admittedly less cleanly since there isn't a native platform equivalent).
> 
> On the plugin operations - Question is whether that would annoy developers that prefer
to edit by hand (vs IDE use). The idea behind save/restore is to make it easier to share a
project and reduce the amount of redundant code that you'd check in to a source repo.  (You
could omit the plugins and platforms folders from source control and then "restore".)
> 
> -Chuck
> 
> -----Original Message-----
> From: Michal Mocny [mailto:mmocny@google.com]
> Sent: Wednesday, August 13, 2014 3:27 PM
> To: Treggiari, Leo
> Cc: dev@cordova.apache.org
> Subject: Re: cordova plugin save
> 
> On Wed, Aug 13, 2014 at 6:07 PM, Treggiari, Leo <leo.treggiari@intel.com>
> wrote:
> 
> >  Hi Michal,
> >
> >
> >
> > Thanks for your answers.  They were quite helpful.  I have a few
> > follow-ups.
> >
> >
> >
> > With your answers, and references, and I found
> > https://wiki.apache.org/cordova/ConfigurationFiles,
> >
> > I have a better understanding of the existing metadata files.
> >
> >
> >
> > However there seem to be quite a few of them  and I’m not yet sure
> > about where different types of information should go.
> >
> >
> >
> > https://wiki.apache.org/cordova/ConfigurationFiles goes into the
> > answers I’m looking for, except it just seems to be documenting the
> > current situation.
> >
> > -  What types of metadata are there?
> >
> > -  Where is each type saved?
> >
> > -  Who owns each type and can change it?
> >
> I think we are figuring this out ourselves.  There are differing opinions.
>  Thanks for speaking up and voicing yours.
> 
> >
> >
> > Here are my thoughts:
> >
> >
> >
> > - “App” (or “Project”) metadata defines everything about the “app”
> > that should be shared by all developers who want to develop/build the
> > app.  In the case of Cordova CLI, this is primarily a “build recipe”.
> > I.e. with this metadata (plus given proper “workspace” (or
> > “environment”) setup), anyone can build the same app.  Tooling (e.g.
> > Cordova CLI) or IDEs would normally be used to maintain some/all of
> > this metadata.  For example, Cordova CLI may handle the plugins and
> > platforms but document how to add icons and splash screens to the app
> > using this metadata file.  An IDE might manage all of that inside the
> > IDE itself.  The newly proposed metadata for specifying project directory structure
would be part of this metadata.
> >
> Personally, this is exactly my mental model as well.  But its
> 
> 
> >
> >
> > - “Workspace” (or “Environment” or “Project specific user settings”)
> > metadata describe the settings that a user (or tools on the user’s
> > behalf) have to make to set up an environment for developing/building the app.
> > E.g. the location of native SDKs.
> >
> Ditto.
> 
> >
> >
> > In general, different tooling/IDEs could have different rules
> > regarding who creates these metadata files and who is allowed to edit them and how.
> >
> >
> >
> > Is app config.xml intended to be the “App” metadata file?
> >
> Yes.  Though it should be noted that most everyone would rather there was a different
file for this.
> 
> config.xml is based on a deprecated proposal for app metadata (widget spec).  There are
several new app manifest formats roaming around, most based on json.  However, I think we
will likely use what we already have for the foreseeable future since we're already spending
way too much time on tooling and changing this is not worthwhile bang-for-buck.
> 
> >  Is .cordova/config.json intended to be the “Workspace” metadata file?
> >
> I think so.  I'm less sure about how everyone feels about this file, but its likely that
we will stick with what we have.  Its also possible that IDE's/downstream tooling can just
use some internal settings representation since most the the config.json values can be passed
in to the CLI through the command line or node interface.
> 
> >
> >
> > > - Aside from the initial create script that sets name etc, the
> >
> > > plugin/platform save command is the first tooling command to edit
> > > the
> > file
> >
> > > directly (I think?).
> >
> >
> >
> > I don’t understand why ‘cordova plugin/platform add/remove’ would not
> > modify app config.xml, but now ‘cordova plugin/platform save’ would.
> > Or is that really the distinction between the 2?  And how does that
> > list of plugins interact with what the user may have added themselves to config.xml?
> >
> I think this was Andrew's point and Gorkems original intention.  We agree that `plugin
add/remove` should update the list.  The save/restore was just a non-intrusive way to experiment
for now.
> 
> >
> >
> > Thanks,
> >
> All good questions raised, with few definitive answers.  It sounds like you're all caught
up to the rest of us, though!
> 
> >  Leo
> >
> >
> >
> > > A few answers:
> >
> > > - There is no spec, since this is an "experimental" feature we
> > > aren't
> >
> > >  ourselves sure yet how it will look when complete.  That was the
> > > point
> > of
> >
> > >  recent threads.
> >
> > > - The file belongs to the app / user, not to the workspace / tooling.
> >
> > > - Aside from the initial create script that sets name etc, the
> >
> > > plugin/platform save command is the first tooling command to edit
> > > the
> > file
> >
> > > directly (I think?).
> >
> > > - You can read more here:
> >
> > > https://cordova.apache.org/docs/en/edge/config_ref_index.md.html
> >
> > > - The top level "app" config.xml is not platform specific, but you
> > > can
> > have
> >
> > > platform specific settings in there by using the <platform> tag
> >
> > > - It is specific to cordova CLI.  Each platform has another,
> > > different
> >
> > > config.xml (we usually call it the "platform" config.xml) which is
> > created
> >
> > > during cordova prepare, and thats what edited with non cli workflow.
> >
> > > - Phonegap workflow (also chrome cordova (cca) and likely others) is
> >
> > > compatible with cordova config.xml, but those often also add
> > > extensions
> > to
> >
> > > the options
> >
> > > - "project-level" (I call this "workspace") metadata should *not* go
> > > into
> >
> > > app config.xml. We already have another file, .cordova/config.json
> > > for
> >
> > > those.  However, the list of plugins that your app needs is arguably
> > > not
> > a
> >
> > > property of a workspace, but truly a property of your application.
> > > Ditto
> >
> > > for platforms (to a lesser extent).
> >
> > >
> >
> > > I'm not so sure what the proposal is for removing plugins/
> > > directory, I
> >
> > > don't think there is anything concrete for that, it was just
> > > ramblings of
> >
> > > various contributors ;)
> >
> > >
> >
> > > -Michal
> >
> > >
> >
> > >
> >
> > > On Wed, Aug 13, 2014 at 2:41 PM, Treggiari, Leo
> > > <leo.treggiari@intel.com
> > >
> >
> > > wrote:
> >
> > >
> >
> > >> I'm new to this mailing list.  I work on the Intel(r) XDK which is
> > another
> >
> > >> IDE which supports the creation of hybrid apps using Cordova plugins.
> >
> > >>
> >
> > >> I'm having trouble figuring out what the proposed 'cordova plugin save'
> >
> > >> command does.  Is there an up-to-date 'spec' that explains the
> > >> goals of
> > the
> >
> > >> command and the implementation?
> >
> > >>
> >
> > >> A couple of things that I have read in the mailing list concern me.
> >
> > >>
> >
> > >> There is mention of saving information in config.xml.  The usage of
> >
> > >> config.xml is somewhat of a mystery to me:
> >
> > >> -  Who owns the file?  Does the user own and edit it?  Do certain
> > Cordova
> >
> > >> CLI commands edit it?  What are the valid entries?
> >
> > >> -  Is it treated differently by different platform builds - e.g. iOS vs.
> >
> > >> Android?  Is it treated differently by Cordova CLI vs. other
> > >> Cordova
> > IDEs
> >
> > >> which directly use Cordova CLI or not - e.g. PhoneGap build?
> >
> > >> -  If Cordova CLI wants to store 'project-level' metadata, is this
> > >> a
> > good
> >
> > >> place to put it?  If the answer to the first question above is not
> > >> well
> >
> > >> defined, or the answer to the second question is that different 'things'
> >
> > >> are using it differently, then config.xml may not be a good place
> > >> to be
> >
> > >> putting new metadata.
> >
> > >>
> >
> > >> There is a mention of plugin "restoring" and making the plugins
> > directory
> >
> > >> optional.  This relates to the issue of plugin 'versions'.  Now,
> > >> when a
> >
> > >> user executes 'cordova plugin add', plugin sources are fetched and
> > >> the
> >
> > >> version of the plugin that was added is fixed until the user
> > >> explicitly
> >
> > >> removes and re-adds it.  Is 'cordova plugin save' & 'restore'
> > suggesting a
> >
> > >> new version management model?  E.g. if I add a plugin without a
> > >> specific
> >
> > >> version suffix and 'restore' it later, I may not get the same
> > >> version,
> >
> > >> right?
> >
> > >>
> >
> > >> If there is a 'spec', I should be able to answer these questions myself.
> >
> > >>
> >
> > >> Thanks,
> >
> > >> Leo Treggiari
> >
> >
> >

Mime
View raw message