Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of csantana23@gmail.com
 designates 209.85.212.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAEeF2Tep7Gq4-BpR9kGfH0f+S9oLfeRRiFiGSSswTtRSMiHA1g@mail.gmail.com>
References: 
 <CAHYtTqnHmftRto0_ZFiAC=WToLuWNz7bXx3hX5xhk8vObFQdtg@mail.gmail.com>
	<CAEeF2TfX58mHZ1iAC_PL5qturjH=LUurrKSuBXv3HftZDanktA@mail.gmail.com>
	<CAHYtTqk81eYWefc9SGyydBYmy7mPQ+6CvQb8RmmAh27wrhn5sQ@mail.gmail.com>
	<CAEeF2Tep7Gq4-BpR9kGfH0f+S9oLfeRRiFiGSSswTtRSMiHA1g@mail.gmail.com>
Date: Wed, 30 Jul 2014 12:45:32 -0400
Message-ID: 
 <CAHYtTq=i=ev4bcCfmpy0mZVDSdieTsxhq5e-SRg3Mk2kP=AC8w@mail.gmail.com>
Subject: Re: How to provide more files from plugin.xml for project and native?
From: Carlos Santana <csantana23@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7bacc66476a5c704ff6be242

--047d7bacc66476a5c704ff6be242
Content-Type: text/plain; charset=UTF-8

Would appreciate help to brainstorm

I want to come out what is best for cordova developers.
Today we have a downstream that ships cordova, I want to see if we can
provide better experience

I'm trying to experiment with the crazy idea of providing our value-add
thru a cordova plugin, meaning developer uses cordova and cordova plugins,
they can pick and choose when to update, and our value add is something
they can add and remove very easily leaving their app un-touch.

I understand the scenario about grunt/yeoman/gulp and scaffolding, but
that's not the main use case.
When starting from scratch on create is easy to use a template, the main
use case is when a developer already has a created app.

For example if a developer already has a Chrome Mobile App using cca, and
then he wants to add a functionality that we provide?
I want the answer to be: keep using cca tool, and just add our plugin

I think I can achieve something by asking them to unzip an archive that I
provide that contains files and hooks, but my problem is I want to provide
an easy way for the developer to remove what was added by the zip archive.

And again I don't think implementing a new type of "plugin",  "module", or
"package" for the app/project that can be fetch, install, and remove is a
simple answer, I want to keep it simple and easy to understand for
developers.


On Wed, Jul 30, 2014 at 12:06 PM, Michal Mocny <mmocny@chromium.org> wrote:

> On Wed, Jul 30, 2014 at 11:38 AM, Carlos Santana <csantana23@gmail.com>
> wrote:
>
> > On Wed, Jul 30, 2014 at 10:54 AM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> >
> > > First, the easy one: Certainly you should have a way to drop files into
> > > platforms/ios/HelloCordova, and I think <source-file> is probably the
> way
> > > to go.  The root seems to be the plugin folder by default, so you may
> > need
> > > to prefix with "../.." right now.  Also seems hacky, not sure if there
> > is a
> > > better way.
> > >
> >
> > <source-file> doesn't work for my use case, I'm already using for
> > libraries, frameworks, and files that I want to be available inside the
> > Mobile App.
> > I want the file to be inside the XCode project, but NOT inside the Mobile
> > App. It's a file that I need from xcode build script
> >
> >
> > > For the other two: /merges and /hooks, I really don't think we should
> be
> > > adding files into there.  I consider those application assets, along
> with
> > > www/ and application config.xml, which we also should not be directly
> > > modifying from plugins.
> > >
> > >
> > I think plugins should be allow to add files to any place in the cordova
> > project/application.
> > Or we can design a new type of "plugin" a plugin that deals with cordova
> > project tooling.
> > I like things simple, so if I can manage to create one plugin for my
> > enterprise product, it will be easy for end user starting with cordova to
> > add and remove one type of plugin, and then the plugin will take care of
> > both what runs on the device and any tooling requirements for those
> > features
> >
> > I'm building a plugin that will add to the existing cordova project
> > excluding www/ (I don't want to touch this one). For www I think I will
> > have "www" templates they can use when the do "cordova create" but this
> are
> > just samples, if they already have an existing app I want an easy for
> them
> > to get necessary files for my plugin to work, and some files are to be
> > edited by them "merges", and other are hooks that need to run in prepare
> >
> > I want to add files to /merges/ /platforms and /hooks that are only
> > applicable to my plugin and not overwriting any user files
> >
>
> This sounds like something thats worth brainstorming the right solution
> for.  I'm thinking this functionality should lay outside of cordova
> tooling, which is already too beefy.
>
> For chrome apps, we created a downstream tool for this (cca).  I do think
> its unfortunate that we all need to have separate downstream CLI's that
> cannot be used together, but I don't think writing complicated plugins that
> overwrite large part of a cordova workspace is a useful alternative.
>  Perhaps grunt/gulp plugins that combine well are, not sure.
>
> Another option is to publish a project generator for your type of
> application, either via yeoman, a custom script, or just a boilerplate
> project.
>
>
> >
> >
> > > For hooks -- there is a PR outstanding to just go ahead and add plugin
> > > hooks.  Perhaps you would like to help review and comment on that to
> get
> > it
> > > landed asap?
> > >
> >
> > I will take a look, but I don't think it solves my use case, basically
> I'm
> > asking for this function to be added to be done in a generic way in
> > plugin.xml, versus having a mega_plugin_install hooks scripts that kind
> > does the same thing is a custom brittle way vs relying on the the cordova
> > community tooling
> >
>
> I think running hooks from plugins is slightly less ugly than having
> plugins add hooks to the root, but in the end roughly equivalent.  The
> hooks that actually run are just as brittle in either case, which is why we
> are cautious about adding this in any form.
>
>
> >
> >
> > > For merges -- I kinda think we should have plugins on par with apps,
> and
> > > just have a merges/ folder for plugins.  However, merges/ is probably
> > just
> > > generally a bad idea, and I suspect you can do a better job yourself by
> > > writing hooks/ instead.
> > >
> > >
> > Totally got blind here I don't know what you mean by "have plugins on par
> > with apps" and "merges/ folder for plugins"
> >
>
> I just mean that, apps have a hooks/ and merges/, but plugins do not.
>  We're now considering adding hooks/, so maybe we should also add merges/
> (right now plugins can simulate this explicitly with <platform> tags and
> <assets>).
>
>
> >
> > I'm also looking on having a "/append/" and "/prepend/" in addition of
> what
> > we have today "merges/" but probably that's a new mailing thread
> >
>
> Yeah, lets leave that for another thread.  Some significantly competing
> ideas on this one.
>
>
> >
> >
> > > -Michal
> > >
> > >
> > > On Wed, Jul 30, 2014 at 10:32 AM, Carlos Santana <csantana23@gmail.com
> >
> > > wrote:
> > >
> > > > I already know about <asset> and <resource-file> [1] in plugin.xml
> > > >
> > > > I'm currently working with ios:
> > > > <asset> copy files will be available inside mobile app www path
> > > > <resource-file> files will be available to mobile app from root path
> > > >
> > > > I want to be able to provide files to other locations that do not go
> > > inside
> > > > mobile app:
> > > > 1. I want to add files to <cordovaproject>
> > > > <cordovaproject>/merges/ios/
> > > > <cordovaproject>/hooks/
> > > > Also here to add scripts/files that will be use by XCode build phases
> > but
> > > > do not go inside mobile App
> > > > <cordovaproject>platform/ios/HelloCordova/
> > > >
> > > > Right now I'm doing something like this, and it feels like a hack
> that
> > > > might not work for all operating systems.
> > > >
> > > > <asset src="src/ios/www/default/worklight/checksum.js"
> > > > target="../../../merges/ios/default/worklight/checksum.js" />
> > > >
> > > > Maybe we need to add new feature for more elements like?
> > > > <cordova-file src="" target="">
> > > > <native src="" target="">
> > > >
> > > >
> > > >
> > > > [1]:
> > > >
> > > >
> > >
> >
> https://github.com/apache/cordova-docs/blob/master/docs/en/edge/plugin_ref/spec.md
> > > >
> > > > --
> > > > Carlos Santana
> > > > <csantana23@gmail.com>
> > > >
> > >
> >
> >
> >
> > --
> > Carlos Santana
> > <csantana23@gmail.com>
> >
>


-- 
Carlos Santana
<csantana23@gmail.com>

--047d7bacc66476a5c704ff6be242--