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 2013/01/09 15:42:39 UTC

Moving plugin JS files around

I'd like to take a first step towards moving plugin JS into separate repos
by first moving them around within cordova-js.

Here is my proposal:

Current structure:
        lib/common/plugin/*.js
        lib/$PLATFORM/plugin/*.js

New structure:
        plugin/$PLUGIN_NAME/js/common/*.js
        plugin/$PLUGIN_NAME/js/$PLATFORM/*.js

The require path will need to change. Going from:
        cordova.require('cordova/plugin/FileTransferError')
To:
        cordova.require('plugin/file/FileTransferError')


I'll obviously need to update the builder scripts accordingly. The idea
here is that we:
        1. "cordova plugin add" will copy files into a project's plugins
directory
        2. "cordova build ios" will use the cordova-js packager and pass it
the plugin/ directory to use

This will not involve changing how we export modules onto namespaces in
common.js / platform.js. That will come next though.


The resulting structure will look like:

plugin/accelerometer/js/common/Acceleration.js
plugin/accelerometer/js/common/accelerometer.js
plugin/battery/js/common/battery.js
plugin/compass/js/common/Compass*.js
plugin/contacts/js/common/Contact*.js
plugin/device/js/common/device.js
plugin/geolocation/js/common/Coordinates.js
plugin/geolocation/js/common/Position*.js
plugin/globalization/js/common/Globalization*.js
plugin/inappbrowser/js/common/InAppBrowser.js
plugin/logger/js/common/logger.js
plugin/logger/js/common/console-via-logger.js
plugin/media/js/common/Capture*.js
plugin/media/js/common/ConfigurationData.js
plugin/media/js/common/Media*.js
plugin/network/js/common/Connection.js
plugin/notification/js/common/notification.js
plugin/camera/js/common/Camera*.js
plugin/echo/js/common/echo.js
plugin/file/js/common/Directory*.js
plugin/file/js/common/Entry.js
plugin/file/js/common/File*.js
plugin/file/js/common/Flags.js
plugin/file/js/common/LocalFileSystem.js
plugin/file/js/common/Metadata.js
plugin/file/js/common/ProgressEvent.js
plugin/splashscreen/js/common/splashscreen.js

Re: Moving plugin JS files around

Posted by Gord Tanner <gt...@gmail.com>.

I was envisioning this working closer to the node_modules pattern.

Ideally with a module loading framework you should be able to XHR these
modules over at require time.

Here is where the debate of commonJS vrs AMD will heat up.  CommonJS will
require sync XHR because of it's ties to node (which I don't think is a bad
thing ;))

Since we have made the leap to a module based javascript layer we should be
able to leverage it to dynamically load the modules for us (may it be XHR,
over the exec bridge, voodoo).




On Mon, Jan 14, 2013 at 4:19 PM, Andrew Grieve <ag...@chromium.org> wrote:

> On Mon, Jan 14, 2013 at 4:04 PM, Gord Tanner <gt...@gmail.com> wrote:
>
> > Yes,
> >
> > BlackBerry is really 3 platforms in one.  We used to have them as 3
> > seperate platforms but was a headache for writing apps and ensuring that
> > you had the right javascript file in the right place.
> >
> Just so I understand this, is it that blackberry has fat binaries? e.g. one
> binary can be deployed to multiple platforms?
>
> Otherwise, it's quite likely that cordova-cli will make the old
> multi-platform headaches go away.
>
>
> >
> > Since I wrote most of the module stuff I agree I have abused it a little
> > with some of the tricks of the trade we have in place with the build
> step.
> >
> > I would rather see us handle this via the exec bridge than including
> script
> > files in the DOM (stay with me for a little bit).
> >
> > Not a final spec but an idea would be:
> >
> > var foo = require('cordova/plugin/foo')
> >
> > inside require we would realize we don't have foo preloaded in cordova.js
> > and call exec>
> >
> > exec(success, fail, 'PluginManager', 'getPluginSource', {plugin: "foo",
> > platform: "ios"})
> >
> > where success would be something like:
> >
> > function (func) {
> >     cordova.define('cordova/plugin/foo', func);
> > }
> >
> > Thoughts?
> >
>
> Gord, what's the motivation for this? Maybe that it addresses the having
> alter <script> tags when adding/removing plugins?
> You'd still need to deal with knowing which JS to include in your App
> package (might be a bit bloated to include all JS for all platforms in all
> apps)
> It would mean making require() an async call (unless you use sync. XHRs),
> and I think would have negative effects on performance.
>
>
>
> >
> >
> > On Mon, Jan 14, 2013 at 3:41 PM, Jesse <pu...@gmail.com> wrote:
> >
> > > Comments inline below.
> > >
> > >
> > > On Mon, Jan 14, 2013 at 11:43 AM, Andrew Grieve <agrieve@chromium.org
> > > >wrote:
> > >
> > > > Created a bug for the file moving part (CB-2214), but we can
> > > > continue discussing here.
> > > >
> > > >
> > > > On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve <agrieve@chromium.org
> >
> > > > wrote:
> > > >
> > > > > Jesse, thanks for the explanation. Certainly my experience is just
> > with
> > > > > Android & iOS, so it's good to get opinions from the other
> platforms.
> > > > >
> > > > > I took a look at WebOS, but pkg/cordova.webos.js does seem to pull
> in
> > > all
> > > > > of the shared plugin modules and hooks them up with the common
> > > bootstrap.
> > > > > Why do you say that WebOS shares hardly any code?
> > > >
> > >
> > > What I meant about WebOS, was just that it overwrites most of the APIs.
> > > There is a distinct difference in the way the platforms without a
> native
> > > counterpart are authored. (bada, windows8, tizen, bb-webworks, ..)
> > >
> > >
> > > > >
> > > > > Blackberry certainly seems to be a bit different in that it looks
> > like
> > > it
> > > > > is actually 4 platforms in one. Not sure why we don't just make it
> > four
> > > > > separate platforms. Gord?
> > > > > That said, Blackberry uses the module system even more than other
> > > > > platforms. I think it would be a lot of work to make plugin within
> > > > > blackberry have it's own loading logic that selectively loads
> module
> > > > based
> > > > > on the sub-platform (if we went with a single-file pre-built
> > approach).
> > > > >
> > > > > With the single-file prebuilt approach, I'd guess it would look
> > > something
> > > > > like this:
> > > > >
> > > > > plugin.xml says which .js file to include for the platform:
> > > > >
> > > > > <platform name="android">
> > > > >   <source-file src="filetransfer.js" />
> > > > > </platform>
> > > >
> > >
> > > And maybe even:
> > > <platform name="android">
> > >   <source-file src="filetransfer-common.js" />
> > >   <source-file src="filetransfer-android.js" />
> > > </platform>
> > > ...
> > >
> > >
> > >
> > > > >
> > > > >
> > > > > There is certainly a bug-report advantage to having each in its own
> > .js
> > > > > file. If everything is in cordova.js, and we get bugs with "Error
> on
> > > line
> > > > > ##", we can't actually map that to a file. On the other hand, each
> > > > platform
> > > > > has bootstrap logic that must come after plugins are loaded. This
> > might
> > > > > turn into a source of errors if we have a bunch of .js files being
> > > added
> > > > > via <script> tags.
> > > > >
> > > > >
> > > > > One aspect of plugin JS that I don't want to lose, is our separate
> > pass
> > > > of
> > > > > module -> symbol (defaults/merges/clobbers). In fact, I think this
> is
> > > an
> > > > > area that we may wish to enhance in the future. E.g. a couple of
> > > releases
> > > > > ago we added the ability to print a deprecation message when old
> > > > namespaces
> > > > > are referenced. Other advantages of the system:
> > > > >   - Helps authors write modules side-effect free modules
> > > > >   - Allows us to detect symbol collisions
> > > > >   - Gives us control over when the modules are loaded
> > > > >      - e.g. We could add measurement to see how long this process
> > takes
> > > > >      - e.g. We could experiment with lazy-loaded modules by using
> JS
> > > > > getters that return require(module)
> > > > >      - e.g. We could use this to support exposing Cordova APIs to
> > > iframes
> > > > >
> > > > >
> > > > > It might be possible for us to maintain the module->symbol mapping
> > > system
> > > > > if we had plugins use pre-built .js files. E.g. their .js could be
> a
> > > > > collection of cordova.define() calls, followed by a
> > > > > cordova.registerModuleMappings() call. Is that what you're
> thinking?
> > > >
> > >
> > > Yes, something like this.
> > > The plugin would be wrapped in a module-closure, and 'define' it's
> > > interface.
> > >
> > > cordova.define("my/namespace", function(require, exports, module) { });
> > >
> > > Some of this would need to reworked as currently we have 2 aliases for
> > > every plugin:
> > > navigator.accelerometer === cordova.plugin.accelerometer
> > >
> > >
> > >
> > >
> > > > >
> > > > > In either way, I think I'd like to go ahead with this change of
> > moving
> > > > > from lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I
> > think
> > > > > this is a good first step for either proposal.
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen <
> > > > purplecabbage@gmail.com>wrote:
> > > > >
> > > > >> Hi Andrew,
> > > > >>
> > > > >> Having spent some time with this, I don't think it's awful, but I
> am
> > > > >> worried about complexity.
> > > > >>
> > > > >> To me, a better approach is:
> > > > >>
> > > > >> - all plugins are simply ripped out of cordova-js
> > > > >> - each plugin is distributed 'built' meaning for an API like file
> or
> > > > >> contacts, there is only 1 js file, and while it depends on
> > cordova.js,
> > > > >> it is not part of it. ( or possibly just a concat )
> > > > >> - plugman does the work of adding/removing but it is really just
> > > > >> changing script tags for the js portion
> > > > >>
> > > > >> This means all our core plugs will need to be modified as the
> > > > >> currently depend on the builder to wrap them.
> > > > >>
> > > > >> I spent some time working with your approach Andrew, and I think
> it
> > > > >> sounds better than it is. Blackberry has 4 inter-related branches
> to
> > > > >> consider, webos shares hardly any code with the other platforms,
> > ... I
> > > > >> am more keen on adding consistency than  I am to making the tool
> > work
> > > > >> around it.
> > > > >>
> > > > >> If we were only concerned with iOS, Android, and windows phone,
> then
> > > > >> your  approach might be best, but there are some messes in there.
> > > > >>
> > > > >> I will continue to push for the simpler solution, but I won't
> block
> > > > >> you anymore.
> > > > >> I do think you should dive a little deeper into your approach, and
> > > > >> possibly prove me wrong. I am completely open to further
> discussion
> > on
> > > > >> the point.
> > > > >>
> > > > >>
> > > > >> Cheers,
> > > > >>  Jesse
> > > > >>
> > > > >> Sent from my iPhone5
> > > > >>
> > > > >> On 2013-01-10, at 8:09 PM, Andrew Grieve <ag...@chromium.org>
> > > wrote:
> > > > >>
> > > > >> On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner <gt...@gmail.com>
> > > wrote:
> > > > >>
> > > > >> > Ideally the require paths should stay true to the following
> rules
> > > (not
> > > > >> that
> > > > >> > we follow them exactly now but we are close):
> > > > >> >
> > > > >> > 1. should always start with cordova (in case we ever share a
> > require
> > > > >> > framework)
> > > > >> > 2. should follow as close as possible to the folder structure.
> > > > >> >
> > > > >> > We don't really do this now (but we are close).  It is mainly to
> > > help
> > > > >> with
> > > > >> > navigation of the project from a require statement:
> > > > >> >
> > > > >> >    var foo = require('cordova/plugin/foo/submodule')
> > > > >> >
> > > > >> > Ideally I should be able to navigate to a file that lives in:
> > > > >> >
> > > > >> >    ~/cordova.js/plugin/foo/submodule.js
> > > > >> >
> > > > >> > But realistically we are probably going to see:
> > > > >> >
> > > > >> >   ~/cordova.js/plugin/foo/js/submodule.js
> > > > >> >
> > > > >> > Assuming we are dumping everything into a js folder here is the
> > > > >> "mapping"
> > > > >> > off the top of my head:
> > > > >> >
> > > > >> >   var foo = require('cordova/plugin/foo')
> > > > >> >   ~/cordova.js/plugin/foo/js/index.js
> > > > >> >
> > > > >> >   var foo = require('cordova/plugin/foo/ios')
> > > > >> >   ~/cordova.js/plugin/foo/js/ios.js
> > > > >> >
> > > > >> >   var foo = require('cordova/plugin/foo/blackberry/qnx')
> > > > >> >   ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> > > > >> >
> > > > >> > What does a plugin (native and js code) folder structure look
> > like?
> > > > >>
> > > > >>
> > > > >> Have a look at this plugin:
> > https://github.com/shazron/KeychainPlugin
> > > > >>
> > > > >> With the JS changes I'm proposing, it would look like:
> > > > >> /src/ios/*.h, *.m
> > > > >> /www  <- empty!
> > > > >> /src/js/common/keychain.js
> > > > >>   or
> > > > >> /src/js/ios/keychain.js
> > > > >>
> > > > >> So, the idea behind moving all of the plugins to
> > /plugin/$PLUGIN_NAME
> > > > >> within cordova-js, is that when they move out, there will be the
> > > > mapping:
> > > > >> cordova-js/plugin/$PLUGIN_NAME --->  $PLUGIN_REPO/src/js
> > > > >>
> > > > >>
> > > > >> When a plugin is installed into a project via cordova-cli, I
> suggest
> > > > that
> > > > >> we get a structure like this:
> > > > >>
> > > > >> MyApp/platforms/ios/... same as before ...
> > > > >> MyApp/cordova-js/... copy of cordova-js
> > > > >> MyApp/cordova-js/plugin/keychain/common/keychain.js
> > > > >> MyApp/plugins/keychain/plugin.xml
> > > > >> MyApp/www
> > > > >>
> > > > >> So, the idea here is that the cordova-js will have no top-level
> > > plugin/
> > > > >> directory, but one will be added when plugins are added.
> > > > >>
> > > > >> Also, like other sources, .js file should be listed in the
> > plugin.xml
> > > so
> > > > >> that they can be reliably removed.
> > > > >>
> > > > >>
> > > > >>
> > > > >> About the require paths. I think for files in cordova-js, the
> prefix
> > > > >> should
> > > > >> be "cordova/", but for plugin files, it should be "plugin/" (or
> > maybe
> > > > >> "cordovaplugin/"?), so that plugin JS doesn't accidentally clobber
> > > core
> > > > >> cordova modules.
> > > > >>
> > > > >> For the keychain example:
> require('cordovaplugin/keychain/keychain')
> > > > >>
> > > > >>
> > > > >> In terms of changes to the builder, we'd need to add the idea of
> > > > multiple
> > > > >> roots. Instead of just 'lib', there will also be 'plugin' as a
> root.
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> >
> > > > >> > On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <
> agrieve@google.com
> > >
> > > > >> wrote:
> > > > >> >
> > > > >> >> I'd like to take a first step towards moving plugin JS into
> > > separate
> > > > >> > repos
> > > > >> >> by first moving them around within cordova-js.
> > > > >> >>
> > > > >> >> Here is my proposal:
> > > > >> >>
> > > > >> >> Current structure:
> > > > >> >>       lib/common/plugin/*.js
> > > > >> >>       lib/$PLATFORM/plugin/*.js
> > > > >> >>
> > > > >> >> New structure:
> > > > >> >>       plugin/$PLUGIN_NAME/js/common/*.js
> > > > >> >>       plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> > > > >> >>
> > > > >> >> The require path will need to change. Going from:
> > > > >> >>       cordova.require('cordova/plugin/FileTransferError')
> > > > >> >> To:
> > > > >> >>       cordova.require('plugin/file/FileTransferError')
> > > > >> >>
> > > > >> >>
> > > > >> >> I'll obviously need to update the builder scripts accordingly.
> > The
> > > > idea
> > > > >> >> here is that we:
> > > > >> >>       1. "cordova plugin add" will copy files into a project's
> > > > plugins
> > > > >> >> directory
> > > > >> >>       2. "cordova build ios" will use the cordova-js packager
> and
> > > > pass
> > > > >> > it
> > > > >> >> the plugin/ directory to use
> > > > >> >>
> > > > >> >> This will not involve changing how we export modules onto
> > > namespaces
> > > > in
> > > > >> >> common.js / platform.js. That will come next though.
> > > > >> >>
> > > > >> >>
> > > > >> >> The resulting structure will look like:
> > > > >> >>
> > > > >> >> plugin/accelerometer/js/common/Acceleration.js
> > > > >> >> plugin/accelerometer/js/common/accelerometer.js
> > > > >> >> plugin/battery/js/common/battery.js
> > > > >> >> plugin/compass/js/common/Compass*.js
> > > > >> >> plugin/contacts/js/common/Contact*.js
> > > > >> >> plugin/device/js/common/device.js
> > > > >> >> plugin/geolocation/js/common/Coordinates.js
> > > > >> >> plugin/geolocation/js/common/Position*.js
> > > > >> >> plugin/globalization/js/common/Globalization*.js
> > > > >> >> plugin/inappbrowser/js/common/InAppBrowser.js
> > > > >> >> plugin/logger/js/common/logger.js
> > > > >> >> plugin/logger/js/common/console-via-logger.js
> > > > >> >> plugin/media/js/common/Capture*.js
> > > > >> >> plugin/media/js/common/ConfigurationData.js
> > > > >> >> plugin/media/js/common/Media*.js
> > > > >> >> plugin/network/js/common/Connection.js
> > > > >> >> plugin/notification/js/common/notification.js
> > > > >> >> plugin/camera/js/common/Camera*.js
> > > > >> >> plugin/echo/js/common/echo.js
> > > > >> >> plugin/file/js/common/Directory*.js
> > > > >> >> plugin/file/js/common/Entry.js
> > > > >> >> plugin/file/js/common/File*.js
> > > > >> >> plugin/file/js/common/Flags.js
> > > > >> >> plugin/file/js/common/LocalFileSystem.js
> > > > >> >> plugin/file/js/common/Metadata.js
> > > > >> >> plugin/file/js/common/ProgressEvent.js
> > > > >> >> plugin/splashscreen/js/common/splashscreen.js
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > @purplecabbage
> > > risingj.com
> > >
> >
>

Re: Moving plugin JS files around

Posted by Andrew Grieve <ag...@chromium.org>.

On Mon, Jan 14, 2013 at 4:04 PM, Gord Tanner <gt...@gmail.com> wrote:

> Yes,
>
> BlackBerry is really 3 platforms in one.  We used to have them as 3
> seperate platforms but was a headache for writing apps and ensuring that
> you had the right javascript file in the right place.
>
Just so I understand this, is it that blackberry has fat binaries? e.g. one
binary can be deployed to multiple platforms?

Otherwise, it's quite likely that cordova-cli will make the old
multi-platform headaches go away.


>
> Since I wrote most of the module stuff I agree I have abused it a little
> with some of the tricks of the trade we have in place with the build step.
>
> I would rather see us handle this via the exec bridge than including script
> files in the DOM (stay with me for a little bit).
>
> Not a final spec but an idea would be:
>
> var foo = require('cordova/plugin/foo')
>
> inside require we would realize we don't have foo preloaded in cordova.js
> and call exec>
>
> exec(success, fail, 'PluginManager', 'getPluginSource', {plugin: "foo",
> platform: "ios"})
>
> where success would be something like:
>
> function (func) {
>     cordova.define('cordova/plugin/foo', func);
> }
>
> Thoughts?
>

Gord, what's the motivation for this? Maybe that it addresses the having
alter <script> tags when adding/removing plugins?
You'd still need to deal with knowing which JS to include in your App
package (might be a bit bloated to include all JS for all platforms in all
apps)
It would mean making require() an async call (unless you use sync. XHRs),
and I think would have negative effects on performance.



>
>
> On Mon, Jan 14, 2013 at 3:41 PM, Jesse <pu...@gmail.com> wrote:
>
> > Comments inline below.
> >
> >
> > On Mon, Jan 14, 2013 at 11:43 AM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > Created a bug for the file moving part (CB-2214), but we can
> > > continue discussing here.
> > >
> > >
> > > On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve <ag...@chromium.org>
> > > wrote:
> > >
> > > > Jesse, thanks for the explanation. Certainly my experience is just
> with
> > > > Android & iOS, so it's good to get opinions from the other platforms.
> > > >
> > > > I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in
> > all
> > > > of the shared plugin modules and hooks them up with the common
> > bootstrap.
> > > > Why do you say that WebOS shares hardly any code?
> > >
> >
> > What I meant about WebOS, was just that it overwrites most of the APIs.
> > There is a distinct difference in the way the platforms without a native
> > counterpart are authored. (bada, windows8, tizen, bb-webworks, ..)
> >
> >
> > > >
> > > > Blackberry certainly seems to be a bit different in that it looks
> like
> > it
> > > > is actually 4 platforms in one. Not sure why we don't just make it
> four
> > > > separate platforms. Gord?
> > > > That said, Blackberry uses the module system even more than other
> > > > platforms. I think it would be a lot of work to make plugin within
> > > > blackberry have it's own loading logic that selectively loads module
> > > based
> > > > on the sub-platform (if we went with a single-file pre-built
> approach).
> > > >
> > > > With the single-file prebuilt approach, I'd guess it would look
> > something
> > > > like this:
> > > >
> > > > plugin.xml says which .js file to include for the platform:
> > > >
> > > > <platform name="android">
> > > >   <source-file src="filetransfer.js" />
> > > > </platform>
> > >
> >
> > And maybe even:
> > <platform name="android">
> >   <source-file src="filetransfer-common.js" />
> >   <source-file src="filetransfer-android.js" />
> > </platform>
> > ...
> >
> >
> >
> > > >
> > > >
> > > > There is certainly a bug-report advantage to having each in its own
> .js
> > > > file. If everything is in cordova.js, and we get bugs with "Error on
> > line
> > > > ##", we can't actually map that to a file. On the other hand, each
> > > platform
> > > > has bootstrap logic that must come after plugins are loaded. This
> might
> > > > turn into a source of errors if we have a bunch of .js files being
> > added
> > > > via <script> tags.
> > > >
> > > >
> > > > One aspect of plugin JS that I don't want to lose, is our separate
> pass
> > > of
> > > > module -> symbol (defaults/merges/clobbers). In fact, I think this is
> > an
> > > > area that we may wish to enhance in the future. E.g. a couple of
> > releases
> > > > ago we added the ability to print a deprecation message when old
> > > namespaces
> > > > are referenced. Other advantages of the system:
> > > >   - Helps authors write modules side-effect free modules
> > > >   - Allows us to detect symbol collisions
> > > >   - Gives us control over when the modules are loaded
> > > >      - e.g. We could add measurement to see how long this process
> takes
> > > >      - e.g. We could experiment with lazy-loaded modules by using JS
> > > > getters that return require(module)
> > > >      - e.g. We could use this to support exposing Cordova APIs to
> > iframes
> > > >
> > > >
> > > > It might be possible for us to maintain the module->symbol mapping
> > system
> > > > if we had plugins use pre-built .js files. E.g. their .js could be a
> > > > collection of cordova.define() calls, followed by a
> > > > cordova.registerModuleMappings() call. Is that what you're thinking?
> > >
> >
> > Yes, something like this.
> > The plugin would be wrapped in a module-closure, and 'define' it's
> > interface.
> >
> > cordova.define("my/namespace", function(require, exports, module) { });
> >
> > Some of this would need to reworked as currently we have 2 aliases for
> > every plugin:
> > navigator.accelerometer === cordova.plugin.accelerometer
> >
> >
> >
> >
> > > >
> > > > In either way, I think I'd like to go ahead with this change of
> moving
> > > > from lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I
> think
> > > > this is a good first step for either proposal.
> > > >
> > > >
> > > >
> > > > On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen <
> > > purplecabbage@gmail.com>wrote:
> > > >
> > > >> Hi Andrew,
> > > >>
> > > >> Having spent some time with this, I don't think it's awful, but I am
> > > >> worried about complexity.
> > > >>
> > > >> To me, a better approach is:
> > > >>
> > > >> - all plugins are simply ripped out of cordova-js
> > > >> - each plugin is distributed 'built' meaning for an API like file or
> > > >> contacts, there is only 1 js file, and while it depends on
> cordova.js,
> > > >> it is not part of it. ( or possibly just a concat )
> > > >> - plugman does the work of adding/removing but it is really just
> > > >> changing script tags for the js portion
> > > >>
> > > >> This means all our core plugs will need to be modified as the
> > > >> currently depend on the builder to wrap them.
> > > >>
> > > >> I spent some time working with your approach Andrew, and I think it
> > > >> sounds better than it is. Blackberry has 4 inter-related branches to
> > > >> consider, webos shares hardly any code with the other platforms,
> ... I
> > > >> am more keen on adding consistency than  I am to making the tool
> work
> > > >> around it.
> > > >>
> > > >> If we were only concerned with iOS, Android, and windows phone, then
> > > >> your  approach might be best, but there are some messes in there.
> > > >>
> > > >> I will continue to push for the simpler solution, but I won't block
> > > >> you anymore.
> > > >> I do think you should dive a little deeper into your approach, and
> > > >> possibly prove me wrong. I am completely open to further discussion
> on
> > > >> the point.
> > > >>
> > > >>
> > > >> Cheers,
> > > >>  Jesse
> > > >>
> > > >> Sent from my iPhone5
> > > >>
> > > >> On 2013-01-10, at 8:09 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> > > >>
> > > >> On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner <gt...@gmail.com>
> > wrote:
> > > >>
> > > >> > Ideally the require paths should stay true to the following rules
> > (not
> > > >> that
> > > >> > we follow them exactly now but we are close):
> > > >> >
> > > >> > 1. should always start with cordova (in case we ever share a
> require
> > > >> > framework)
> > > >> > 2. should follow as close as possible to the folder structure.
> > > >> >
> > > >> > We don't really do this now (but we are close).  It is mainly to
> > help
> > > >> with
> > > >> > navigation of the project from a require statement:
> > > >> >
> > > >> >    var foo = require('cordova/plugin/foo/submodule')
> > > >> >
> > > >> > Ideally I should be able to navigate to a file that lives in:
> > > >> >
> > > >> >    ~/cordova.js/plugin/foo/submodule.js
> > > >> >
> > > >> > But realistically we are probably going to see:
> > > >> >
> > > >> >   ~/cordova.js/plugin/foo/js/submodule.js
> > > >> >
> > > >> > Assuming we are dumping everything into a js folder here is the
> > > >> "mapping"
> > > >> > off the top of my head:
> > > >> >
> > > >> >   var foo = require('cordova/plugin/foo')
> > > >> >   ~/cordova.js/plugin/foo/js/index.js
> > > >> >
> > > >> >   var foo = require('cordova/plugin/foo/ios')
> > > >> >   ~/cordova.js/plugin/foo/js/ios.js
> > > >> >
> > > >> >   var foo = require('cordova/plugin/foo/blackberry/qnx')
> > > >> >   ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> > > >> >
> > > >> > What does a plugin (native and js code) folder structure look
> like?
> > > >>
> > > >>
> > > >> Have a look at this plugin:
> https://github.com/shazron/KeychainPlugin
> > > >>
> > > >> With the JS changes I'm proposing, it would look like:
> > > >> /src/ios/*.h, *.m
> > > >> /www  <- empty!
> > > >> /src/js/common/keychain.js
> > > >>   or
> > > >> /src/js/ios/keychain.js
> > > >>
> > > >> So, the idea behind moving all of the plugins to
> /plugin/$PLUGIN_NAME
> > > >> within cordova-js, is that when they move out, there will be the
> > > mapping:
> > > >> cordova-js/plugin/$PLUGIN_NAME --->  $PLUGIN_REPO/src/js
> > > >>
> > > >>
> > > >> When a plugin is installed into a project via cordova-cli, I suggest
> > > that
> > > >> we get a structure like this:
> > > >>
> > > >> MyApp/platforms/ios/... same as before ...
> > > >> MyApp/cordova-js/... copy of cordova-js
> > > >> MyApp/cordova-js/plugin/keychain/common/keychain.js
> > > >> MyApp/plugins/keychain/plugin.xml
> > > >> MyApp/www
> > > >>
> > > >> So, the idea here is that the cordova-js will have no top-level
> > plugin/
> > > >> directory, but one will be added when plugins are added.
> > > >>
> > > >> Also, like other sources, .js file should be listed in the
> plugin.xml
> > so
> > > >> that they can be reliably removed.
> > > >>
> > > >>
> > > >>
> > > >> About the require paths. I think for files in cordova-js, the prefix
> > > >> should
> > > >> be "cordova/", but for plugin files, it should be "plugin/" (or
> maybe
> > > >> "cordovaplugin/"?), so that plugin JS doesn't accidentally clobber
> > core
> > > >> cordova modules.
> > > >>
> > > >> For the keychain example: require('cordovaplugin/keychain/keychain')
> > > >>
> > > >>
> > > >> In terms of changes to the builder, we'd need to add the idea of
> > > multiple
> > > >> roots. Instead of just 'lib', there will also be 'plugin' as a root.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> >
> > > >> > On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <agrieve@google.com
> >
> > > >> wrote:
> > > >> >
> > > >> >> I'd like to take a first step towards moving plugin JS into
> > separate
> > > >> > repos
> > > >> >> by first moving them around within cordova-js.
> > > >> >>
> > > >> >> Here is my proposal:
> > > >> >>
> > > >> >> Current structure:
> > > >> >>       lib/common/plugin/*.js
> > > >> >>       lib/$PLATFORM/plugin/*.js
> > > >> >>
> > > >> >> New structure:
> > > >> >>       plugin/$PLUGIN_NAME/js/common/*.js
> > > >> >>       plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> > > >> >>
> > > >> >> The require path will need to change. Going from:
> > > >> >>       cordova.require('cordova/plugin/FileTransferError')
> > > >> >> To:
> > > >> >>       cordova.require('plugin/file/FileTransferError')
> > > >> >>
> > > >> >>
> > > >> >> I'll obviously need to update the builder scripts accordingly.
> The
> > > idea
> > > >> >> here is that we:
> > > >> >>       1. "cordova plugin add" will copy files into a project's
> > > plugins
> > > >> >> directory
> > > >> >>       2. "cordova build ios" will use the cordova-js packager and
> > > pass
> > > >> > it
> > > >> >> the plugin/ directory to use
> > > >> >>
> > > >> >> This will not involve changing how we export modules onto
> > namespaces
> > > in
> > > >> >> common.js / platform.js. That will come next though.
> > > >> >>
> > > >> >>
> > > >> >> The resulting structure will look like:
> > > >> >>
> > > >> >> plugin/accelerometer/js/common/Acceleration.js
> > > >> >> plugin/accelerometer/js/common/accelerometer.js
> > > >> >> plugin/battery/js/common/battery.js
> > > >> >> plugin/compass/js/common/Compass*.js
> > > >> >> plugin/contacts/js/common/Contact*.js
> > > >> >> plugin/device/js/common/device.js
> > > >> >> plugin/geolocation/js/common/Coordinates.js
> > > >> >> plugin/geolocation/js/common/Position*.js
> > > >> >> plugin/globalization/js/common/Globalization*.js
> > > >> >> plugin/inappbrowser/js/common/InAppBrowser.js
> > > >> >> plugin/logger/js/common/logger.js
> > > >> >> plugin/logger/js/common/console-via-logger.js
> > > >> >> plugin/media/js/common/Capture*.js
> > > >> >> plugin/media/js/common/ConfigurationData.js
> > > >> >> plugin/media/js/common/Media*.js
> > > >> >> plugin/network/js/common/Connection.js
> > > >> >> plugin/notification/js/common/notification.js
> > > >> >> plugin/camera/js/common/Camera*.js
> > > >> >> plugin/echo/js/common/echo.js
> > > >> >> plugin/file/js/common/Directory*.js
> > > >> >> plugin/file/js/common/Entry.js
> > > >> >> plugin/file/js/common/File*.js
> > > >> >> plugin/file/js/common/Flags.js
> > > >> >> plugin/file/js/common/LocalFileSystem.js
> > > >> >> plugin/file/js/common/Metadata.js
> > > >> >> plugin/file/js/common/ProgressEvent.js
> > > >> >> plugin/splashscreen/js/common/splashscreen.js
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > @purplecabbage
> > risingj.com
> >
>

Re: Moving plugin JS files around

Posted by Jesse <pu...@gmail.com>.

While I am not completely opposed to loading scripts that way, aside from
the fact that it is voodoo magic, and if it fails, the developer may have
no clue as to why ...
There are other factors that determine whether the script can be loaded.
Is it packaged with the app ??
Is it whitelisted ??

To me, simple wins every time, adding a script tag is as simple as it gets.
If a developer wants to load scripts on demand, they can use yes/no or some
other loader, but I see no reason to force them to use our loader.

IMHO, if the ultimate goal of Apache Cordova is to cease to exist, then
adding all these extra tooling steps and inter-dependencies is
counter-productive.


On Mon, Jan 14, 2013 at 1:04 PM, Gord Tanner <gt...@gmail.com> wrote:

> getPluginSource





-- 
@purplecabbage
risingj.com

Re: Moving plugin JS files around

Posted by Gord Tanner <gt...@gmail.com>.

Yes,

BlackBerry is really 3 platforms in one.  We used to have them as 3
seperate platforms but was a headache for writing apps and ensuring that
you had the right javascript file in the right place.

Since I wrote most of the module stuff I agree I have abused it a little
with some of the tricks of the trade we have in place with the build step.

I would rather see us handle this via the exec bridge than including script
files in the DOM (stay with me for a little bit).

Not a final spec but an idea would be:

var foo = require('cordova/plugin/foo')

inside require we would realize we don't have foo preloaded in cordova.js
and call exec>

exec(success, fail, 'PluginManager', 'getPluginSource', {plugin: "foo",
platform: "ios"})

where success would be something like:

function (func) {
    cordova.define('cordova/plugin/foo', func);
}

Thoughts?


On Mon, Jan 14, 2013 at 3:41 PM, Jesse <pu...@gmail.com> wrote:

> Comments inline below.
>
>
> On Mon, Jan 14, 2013 at 11:43 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > Created a bug for the file moving part (CB-2214), but we can
> > continue discussing here.
> >
> >
> > On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > Jesse, thanks for the explanation. Certainly my experience is just with
> > > Android & iOS, so it's good to get opinions from the other platforms.
> > >
> > > I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in
> all
> > > of the shared plugin modules and hooks them up with the common
> bootstrap.
> > > Why do you say that WebOS shares hardly any code?
> >
>
> What I meant about WebOS, was just that it overwrites most of the APIs.
> There is a distinct difference in the way the platforms without a native
> counterpart are authored. (bada, windows8, tizen, bb-webworks, ..)
>
>
> > >
> > > Blackberry certainly seems to be a bit different in that it looks like
> it
> > > is actually 4 platforms in one. Not sure why we don't just make it four
> > > separate platforms. Gord?
> > > That said, Blackberry uses the module system even more than other
> > > platforms. I think it would be a lot of work to make plugin within
> > > blackberry have it's own loading logic that selectively loads module
> > based
> > > on the sub-platform (if we went with a single-file pre-built approach).
> > >
> > > With the single-file prebuilt approach, I'd guess it would look
> something
> > > like this:
> > >
> > > plugin.xml says which .js file to include for the platform:
> > >
> > > <platform name="android">
> > >   <source-file src="filetransfer.js" />
> > > </platform>
> >
>
> And maybe even:
> <platform name="android">
>   <source-file src="filetransfer-common.js" />
>   <source-file src="filetransfer-android.js" />
> </platform>
> ...
>
>
>
> > >
> > >
> > > There is certainly a bug-report advantage to having each in its own .js
> > > file. If everything is in cordova.js, and we get bugs with "Error on
> line
> > > ##", we can't actually map that to a file. On the other hand, each
> > platform
> > > has bootstrap logic that must come after plugins are loaded. This might
> > > turn into a source of errors if we have a bunch of .js files being
> added
> > > via <script> tags.
> > >
> > >
> > > One aspect of plugin JS that I don't want to lose, is our separate pass
> > of
> > > module -> symbol (defaults/merges/clobbers). In fact, I think this is
> an
> > > area that we may wish to enhance in the future. E.g. a couple of
> releases
> > > ago we added the ability to print a deprecation message when old
> > namespaces
> > > are referenced. Other advantages of the system:
> > >   - Helps authors write modules side-effect free modules
> > >   - Allows us to detect symbol collisions
> > >   - Gives us control over when the modules are loaded
> > >      - e.g. We could add measurement to see how long this process takes
> > >      - e.g. We could experiment with lazy-loaded modules by using JS
> > > getters that return require(module)
> > >      - e.g. We could use this to support exposing Cordova APIs to
> iframes
> > >
> > >
> > > It might be possible for us to maintain the module->symbol mapping
> system
> > > if we had plugins use pre-built .js files. E.g. their .js could be a
> > > collection of cordova.define() calls, followed by a
> > > cordova.registerModuleMappings() call. Is that what you're thinking?
> >
>
> Yes, something like this.
> The plugin would be wrapped in a module-closure, and 'define' it's
> interface.
>
> cordova.define("my/namespace", function(require, exports, module) { });
>
> Some of this would need to reworked as currently we have 2 aliases for
> every plugin:
> navigator.accelerometer === cordova.plugin.accelerometer
>
>
>
>
> > >
> > > In either way, I think I'd like to go ahead with this change of moving
> > > from lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I think
> > > this is a good first step for either proposal.
> > >
> > >
> > >
> > > On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen <
> > purplecabbage@gmail.com>wrote:
> > >
> > >> Hi Andrew,
> > >>
> > >> Having spent some time with this, I don't think it's awful, but I am
> > >> worried about complexity.
> > >>
> > >> To me, a better approach is:
> > >>
> > >> - all plugins are simply ripped out of cordova-js
> > >> - each plugin is distributed 'built' meaning for an API like file or
> > >> contacts, there is only 1 js file, and while it depends on cordova.js,
> > >> it is not part of it. ( or possibly just a concat )
> > >> - plugman does the work of adding/removing but it is really just
> > >> changing script tags for the js portion
> > >>
> > >> This means all our core plugs will need to be modified as the
> > >> currently depend on the builder to wrap them.
> > >>
> > >> I spent some time working with your approach Andrew, and I think it
> > >> sounds better than it is. Blackberry has 4 inter-related branches to
> > >> consider, webos shares hardly any code with the other platforms, ... I
> > >> am more keen on adding consistency than  I am to making the tool work
> > >> around it.
> > >>
> > >> If we were only concerned with iOS, Android, and windows phone, then
> > >> your  approach might be best, but there are some messes in there.
> > >>
> > >> I will continue to push for the simpler solution, but I won't block
> > >> you anymore.
> > >> I do think you should dive a little deeper into your approach, and
> > >> possibly prove me wrong. I am completely open to further discussion on
> > >> the point.
> > >>
> > >>
> > >> Cheers,
> > >>  Jesse
> > >>
> > >> Sent from my iPhone5
> > >>
> > >> On 2013-01-10, at 8:09 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > >>
> > >> On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner <gt...@gmail.com>
> wrote:
> > >>
> > >> > Ideally the require paths should stay true to the following rules
> (not
> > >> that
> > >> > we follow them exactly now but we are close):
> > >> >
> > >> > 1. should always start with cordova (in case we ever share a require
> > >> > framework)
> > >> > 2. should follow as close as possible to the folder structure.
> > >> >
> > >> > We don't really do this now (but we are close).  It is mainly to
> help
> > >> with
> > >> > navigation of the project from a require statement:
> > >> >
> > >> >    var foo = require('cordova/plugin/foo/submodule')
> > >> >
> > >> > Ideally I should be able to navigate to a file that lives in:
> > >> >
> > >> >    ~/cordova.js/plugin/foo/submodule.js
> > >> >
> > >> > But realistically we are probably going to see:
> > >> >
> > >> >   ~/cordova.js/plugin/foo/js/submodule.js
> > >> >
> > >> > Assuming we are dumping everything into a js folder here is the
> > >> "mapping"
> > >> > off the top of my head:
> > >> >
> > >> >   var foo = require('cordova/plugin/foo')
> > >> >   ~/cordova.js/plugin/foo/js/index.js
> > >> >
> > >> >   var foo = require('cordova/plugin/foo/ios')
> > >> >   ~/cordova.js/plugin/foo/js/ios.js
> > >> >
> > >> >   var foo = require('cordova/plugin/foo/blackberry/qnx')
> > >> >   ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> > >> >
> > >> > What does a plugin (native and js code) folder structure look like?
> > >>
> > >>
> > >> Have a look at this plugin: https://github.com/shazron/KeychainPlugin
> > >>
> > >> With the JS changes I'm proposing, it would look like:
> > >> /src/ios/*.h, *.m
> > >> /www  <- empty!
> > >> /src/js/common/keychain.js
> > >>   or
> > >> /src/js/ios/keychain.js
> > >>
> > >> So, the idea behind moving all of the plugins to /plugin/$PLUGIN_NAME
> > >> within cordova-js, is that when they move out, there will be the
> > mapping:
> > >> cordova-js/plugin/$PLUGIN_NAME --->  $PLUGIN_REPO/src/js
> > >>
> > >>
> > >> When a plugin is installed into a project via cordova-cli, I suggest
> > that
> > >> we get a structure like this:
> > >>
> > >> MyApp/platforms/ios/... same as before ...
> > >> MyApp/cordova-js/... copy of cordova-js
> > >> MyApp/cordova-js/plugin/keychain/common/keychain.js
> > >> MyApp/plugins/keychain/plugin.xml
> > >> MyApp/www
> > >>
> > >> So, the idea here is that the cordova-js will have no top-level
> plugin/
> > >> directory, but one will be added when plugins are added.
> > >>
> > >> Also, like other sources, .js file should be listed in the plugin.xml
> so
> > >> that they can be reliably removed.
> > >>
> > >>
> > >>
> > >> About the require paths. I think for files in cordova-js, the prefix
> > >> should
> > >> be "cordova/", but for plugin files, it should be "plugin/" (or maybe
> > >> "cordovaplugin/"?), so that plugin JS doesn't accidentally clobber
> core
> > >> cordova modules.
> > >>
> > >> For the keychain example: require('cordovaplugin/keychain/keychain')
> > >>
> > >>
> > >> In terms of changes to the builder, we'd need to add the idea of
> > multiple
> > >> roots. Instead of just 'lib', there will also be 'plugin' as a root.
> > >>
> > >>
> > >>
> > >>
> > >> >
> > >> > On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
> > >> wrote:
> > >> >
> > >> >> I'd like to take a first step towards moving plugin JS into
> separate
> > >> > repos
> > >> >> by first moving them around within cordova-js.
> > >> >>
> > >> >> Here is my proposal:
> > >> >>
> > >> >> Current structure:
> > >> >>       lib/common/plugin/*.js
> > >> >>       lib/$PLATFORM/plugin/*.js
> > >> >>
> > >> >> New structure:
> > >> >>       plugin/$PLUGIN_NAME/js/common/*.js
> > >> >>       plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> > >> >>
> > >> >> The require path will need to change. Going from:
> > >> >>       cordova.require('cordova/plugin/FileTransferError')
> > >> >> To:
> > >> >>       cordova.require('plugin/file/FileTransferError')
> > >> >>
> > >> >>
> > >> >> I'll obviously need to update the builder scripts accordingly. The
> > idea
> > >> >> here is that we:
> > >> >>       1. "cordova plugin add" will copy files into a project's
> > plugins
> > >> >> directory
> > >> >>       2. "cordova build ios" will use the cordova-js packager and
> > pass
> > >> > it
> > >> >> the plugin/ directory to use
> > >> >>
> > >> >> This will not involve changing how we export modules onto
> namespaces
> > in
> > >> >> common.js / platform.js. That will come next though.
> > >> >>
> > >> >>
> > >> >> The resulting structure will look like:
> > >> >>
> > >> >> plugin/accelerometer/js/common/Acceleration.js
> > >> >> plugin/accelerometer/js/common/accelerometer.js
> > >> >> plugin/battery/js/common/battery.js
> > >> >> plugin/compass/js/common/Compass*.js
> > >> >> plugin/contacts/js/common/Contact*.js
> > >> >> plugin/device/js/common/device.js
> > >> >> plugin/geolocation/js/common/Coordinates.js
> > >> >> plugin/geolocation/js/common/Position*.js
> > >> >> plugin/globalization/js/common/Globalization*.js
> > >> >> plugin/inappbrowser/js/common/InAppBrowser.js
> > >> >> plugin/logger/js/common/logger.js
> > >> >> plugin/logger/js/common/console-via-logger.js
> > >> >> plugin/media/js/common/Capture*.js
> > >> >> plugin/media/js/common/ConfigurationData.js
> > >> >> plugin/media/js/common/Media*.js
> > >> >> plugin/network/js/common/Connection.js
> > >> >> plugin/notification/js/common/notification.js
> > >> >> plugin/camera/js/common/Camera*.js
> > >> >> plugin/echo/js/common/echo.js
> > >> >> plugin/file/js/common/Directory*.js
> > >> >> plugin/file/js/common/Entry.js
> > >> >> plugin/file/js/common/File*.js
> > >> >> plugin/file/js/common/Flags.js
> > >> >> plugin/file/js/common/LocalFileSystem.js
> > >> >> plugin/file/js/common/Metadata.js
> > >> >> plugin/file/js/common/ProgressEvent.js
> > >> >> plugin/splashscreen/js/common/splashscreen.js
> > >> >
> > >>
> > >
> > >
> >
>
>
>
> --
> @purplecabbage
> risingj.com
>

Re: Moving plugin JS files around

Posted by Filip Maj <fi...@adobe.com>.

Responses in-line below.

On 1/15/13 1:35 PM, "Andrew Grieve" <ag...@chromium.org> wrote:

>Okay, I'm feeling the need to reboot a bit on this. I'd like to think this
>through in terms of cordova-cli commands.
>
>First thing I'd like to clarify is where things go when we run "cordova
>platform add" vs "cordova plugin add"?
>I *think* currently how it works is that "cordova platform add ios":
>- Downloads cordova-ios (either from git or from a tar) into a cached
>location: "cordova-cli/lib"
>- Runs cordova-cli/lib/cordova-ios/bin/create project-path/platforms/ios
>com.company.app AppName
>
>Is this correct?

Yes.


>Now, what are the plans for "cordova plugin add"? Will it:
>- Download the plugin source to "cordova-cli/lib" as well? Or does it put
>it in project/plugins?

Puts the plugin source under the ./plugins directory of your project dir.

>Once it's downloaded the source,

FYI it may download but it doesn't have to if you point it to a local path.

> it uses plugman to copy source files into
>project/platforms/ios. How does "cordova plugin remove" work? Does it rely
>on the original plugin.xml file to tell it which files to delete? or does
>it write a manifest when it installs the plugin?

It also uses plugman to do removal (plugman does both). I'm not sure how
plug man does it, but I think yes, it uses plugin.xml to reverse the
operations that an install would do.

>I remember hearing that there were plans to use npm to install plugins,
>but
>looking at the docs, npm doesn't support installing to directories other
>than node_modules. Do we still plan to use this? Maybe just let it install
>into node_modules and then move them out of there? Maybe we have a
>project/plugins/node_modules directory?

I'm not sure. Max Ogden wrote one that uses npm. We are going with a
manifest + tool route separate from npm. The discovery of plugins may use
NPM, though.

>Here's the cordova-packager workflow. The lines suffixed with *** are the
>ones that are different from existing cordova-cli behaviour:
>
>"cordova project create":
>- Creates project template
>
>"cordova platform add ios"
>- Downloads cordova-ios (either from git or from a tar) into
>cordova-cli/lib
>- Since this is the first platform being added, this will trigger a
>similar
>download of cordova-js into cordova-cli/lib
>- Runs cordova-ios/bin/create platforms/ios com.company.app AppName
>- Copy cordova-cli/lib/cordova-js --> project/platforms/cordova-js   ***
>- Removes platforms/ios/www
>
>"cordova plugin add file"
>- Download plugin files
>- copy scripts listed in plugin.xml into
>platforms/cordova-js/lib/$COMMON_OR_PLATFORM/plugin/$PLUGIN_NAME/...  ***
>
>"cordova build":
>- run cordova packager for the added platforms.   ***
>- copy resulting JS into platform/www directories.
>
>
>Notes about this workflow:
>-The only change to the require paths (and cordova-js directory structure)
>in the workflow is the addition of the plugin-name directory under
>lib/common/plugin.
>-This should be pretty easy to debug since it's just automating the dev.
>workflow
>-This will eliminate the need to commit pre-built .js files into platform
>repos.
>-This will make it easier to have projects that build against
>cordova-js/master since it doesn't require pre-built .js files.
>
>
>
>Here's the "prebuild things" workflow. The lines suffixed with *** are the
>ones that are different from existing cordova-cli behaviour:
>
>"cordova project create":
>- Creates project template
>
>"cordova platform add ios"
>- Downloads cordova-ios (either from git or from a tar) into
>cordova-cli/lib
>- Runs cordova-ios/bin/create platforms/ios com.company.app AppName
>- Removes platforms/ios/www
>
>"cordova plugin add file"
>- Download plugin files
>- copy script listed in plugin.xml into
>platforms/ios/plugin-js/file-ios.js
>
>"cordova build":
>- copy prebuilt cordova.ios.js from platforms/ios/CordovaLib ->
>platforms/ios/www/cordova.js
>- concat platforms/ios/plugin-js/* into
>platforms/ios/www/cordova-plugins.js
>
>
>Notes about this workflow:
>-Then change to the require path will be more significant. Maybe
>"cordovaplugin/file/Entry"
>-We would need to build and commit each plugin's .js file
>-Packaging within the plugin when developing may have to be done either
>way
>in order to run its unit tests.
>-This eliminates the need to download the cordova-js repo, but does
>require
>that each platform have a pre-built version of cordova.js in them.
>-In order to run against cordova-js/master, you'll have to manually build
>the .js file and clobber platform/ios/CordovaLib/cordova.ios.js.
>-Changes to the packager will mean having to re-build all plugins, or
>remaining backwards-compatible with plugins built with old packager
>versions
>
>
>
>
>How we deal with mapping module -> symbol is tangental (I think) to which
>approach we take. My guess to this is to have cordova-cli record a list of
>all plugins that it has installed, and for each plugin to have a
>symbols.js
>file that will provide this info. If there is a dependency from one plugin
>on another, then it can require() the other plugin's symbols file to
>ensure
>that it gets loaded first.
>
>
>
>Phew! so, lots of questions & suggestions in there. I'm less sure than
>ever
>as to which approach is better, although I think I'm somewhat leaning
>towards the second one now instead of the first one.
>
>
>I'm going to hold off on moving any files around until we get a better
>grasp on this. Instead, I think I'll first work on creating a symbols.js
>file for each plugin.

Sounds good.

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>On Mon, Jan 14, 2013 at 8:40 PM, Jesse <pu...@gmail.com> wrote:
>>
>> >> Where do you see it overwriting things? I see a few clobbers / merges
>>>
>> ...
>> Sorry, off topic ...
>>
>> >> Are you sure? I just tested this ...
>> Yeah, I was wrong about cordova.plugin, I thought I saw it somewhere,
>>but
>> indeed, they are destroyed when bootstrapped.
>> One thing I did notice is that our API does not have a method to state
>that
>> for example,
>> "cordova/plugin/accelerometer" needs to be mapped to
>> navigator.accelerometer, although I am not sure this should be the job
>>of
>> the 'define' function.  Still chewing on this ...
>>
>>
>> On Mon, Jan 14, 2013 at 1:42 PM, Andrew Grieve <ag...@chromium.org>
>wrote:
>>
>> > Are you sure?
>>
>>
>>
>>
>>
>> --
>> @purplecabbage
>> risingj.com

Re: Moving plugin JS files around

Posted by Andrew Grieve <ag...@chromium.org>.

Okay, I'm feeling the need to reboot a bit on this. I'd like to think this
through in terms of cordova-cli commands.

First thing I'd like to clarify is where things go when we run "cordova
platform add" vs "cordova plugin add"?
I *think* currently how it works is that "cordova platform add ios":
- Downloads cordova-ios (either from git or from a tar) into a cached
location: "cordova-cli/lib"
- Runs cordova-cli/lib/cordova-ios/bin/create project-path/platforms/ios
com.company.app AppName

Is this correct?

Now, what are the plans for "cordova plugin add"? Will it:
- Download the plugin source to "cordova-cli/lib" as well? Or does it put
it in project/plugins?

Once it's downloaded the source, it uses plugman to copy source files into
project/platforms/ios. How does "cordova plugin remove" work? Does it rely
on the original plugin.xml file to tell it which files to delete? or does
it write a manifest when it installs the plugin?

I remember hearing that there were plans to use npm to install plugins, but
looking at the docs, npm doesn't support installing to directories other
than node_modules. Do we still plan to use this? Maybe just let it install
into node_modules and then move them out of there? Maybe we have a
project/plugins/node_modules directory?

Here's the cordova-packager workflow. The lines suffixed with *** are the
ones that are different from existing cordova-cli behaviour:

"cordova project create":
- Creates project template

"cordova platform add ios"
- Downloads cordova-ios (either from git or from a tar) into cordova-cli/lib
- Since this is the first platform being added, this will trigger a similar
download of cordova-js into cordova-cli/lib
- Runs cordova-ios/bin/create platforms/ios com.company.app AppName
- Copy cordova-cli/lib/cordova-js --> project/platforms/cordova-js   ***
- Removes platforms/ios/www

"cordova plugin add file"
- Download plugin files
- copy scripts listed in plugin.xml into
platforms/cordova-js/lib/$COMMON_OR_PLATFORM/plugin/$PLUGIN_NAME/...  ***

"cordova build":
- run cordova packager for the added platforms.   ***
- copy resulting JS into platform/www directories.

Notes about this workflow:
-The only change to the require paths (and cordova-js directory structure)
in the workflow is the addition of the plugin-name directory under
lib/common/plugin.
-This should be pretty easy to debug since it's just automating the dev.
workflow
-This will eliminate the need to commit pre-built .js files into platform
repos.
-This will make it easier to have projects that build against
cordova-js/master since it doesn't require pre-built .js files.

Here's the "prebuild things" workflow. The lines suffixed with *** are the
ones that are different from existing cordova-cli behaviour:

"cordova project create":
- Creates project template

"cordova platform add ios"
- Downloads cordova-ios (either from git or from a tar) into cordova-cli/lib
- Runs cordova-ios/bin/create platforms/ios com.company.app AppName
- Removes platforms/ios/www

"cordova plugin add file"
- Download plugin files
- copy script listed in plugin.xml into platforms/ios/plugin-js/file-ios.js

"cordova build":
- copy prebuilt cordova.ios.js from platforms/ios/CordovaLib ->
platforms/ios/www/cordova.js
- concat platforms/ios/plugin-js/* into platforms/ios/www/cordova-plugins.js

Notes about this workflow:
-Then change to the require path will be more significant. Maybe
"cordovaplugin/file/Entry"
-We would need to build and commit each plugin's .js file
-Packaging within the plugin when developing may have to be done either way
in order to run its unit tests.
-This eliminates the need to download the cordova-js repo, but does require
that each platform have a pre-built version of cordova.js in them.
-In order to run against cordova-js/master, you'll have to manually build
the .js file and clobber platform/ios/CordovaLib/cordova.ios.js.
-Changes to the packager will mean having to re-build all plugins, or
remaining backwards-compatible with plugins built with old packager versions

How we deal with mapping module -> symbol is tangental (I think) to which
approach we take. My guess to this is to have cordova-cli record a list of
all plugins that it has installed, and for each plugin to have a symbols.js
file that will provide this info. If there is a dependency from one plugin
on another, then it can require() the other plugin's symbols file to ensure
that it gets loaded first.

Phew! so, lots of questions & suggestions in there. I'm less sure than ever
as to which approach is better, although I think I'm somewhat leaning
towards the second one now instead of the first one.

I'm going to hold off on moving any files around until we get a better
grasp on this. Instead, I think I'll first work on creating a symbols.js
file for each plugin.

On Mon, Jan 14, 2013 at 8:40 PM, Jesse <pu...@gmail.com> wrote:
>
> >> Where do you see it overwriting things? I see a few clobbers / merges
>>
> ...
> Sorry, off topic ...
>
> >> Are you sure? I just tested this ...
> Yeah, I was wrong about cordova.plugin, I thought I saw it somewhere, but
> indeed, they are destroyed when bootstrapped.
> One thing I did notice is that our API does not have a method to state
that
> for example,
> "cordova/plugin/accelerometer" needs to be mapped to
> navigator.accelerometer, although I am not sure this should be the job of
> the 'define' function.  Still chewing on this ...
>
>
> On Mon, Jan 14, 2013 at 1:42 PM, Andrew Grieve <ag...@chromium.org>
wrote:
>
> > Are you sure?
>
>
>
>
>
> --
> @purplecabbage
> risingj.com

Re: Moving plugin JS files around

Posted by Jesse <pu...@gmail.com>.

>> Where do you see it overwriting things? I see a few clobbers / merges >>
...
Sorry, off topic ...

>> Are you sure? I just tested this ...
Yeah, I was wrong about cordova.plugin, I thought I saw it somewhere, but
indeed, they are destroyed when bootstrapped.
One thing I did notice is that our API does not have a method to state that
for example,
"cordova/plugin/accelerometer" needs to be mapped to
navigator.accelerometer, although I am not sure this should be the job of
the 'define' function.  Still chewing on this ...


On Mon, Jan 14, 2013 at 1:42 PM, Andrew Grieve <ag...@chromium.org> wrote:

> Are you sure?





-- 
@purplecabbage
risingj.com

Re: Moving plugin JS files around

Posted by Andrew Grieve <ag...@chromium.org>.

On Mon, Jan 14, 2013 at 3:41 PM, Jesse <pu...@gmail.com> wrote:

> Comments inline below.
>
>
> On Mon, Jan 14, 2013 at 11:43 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > Created a bug for the file moving part (CB-2214), but we can
> > continue discussing here.
> >
> >
> > On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > Jesse, thanks for the explanation. Certainly my experience is just with
> > > Android & iOS, so it's good to get opinions from the other platforms.
> > >
> > > I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in
> all
> > > of the shared plugin modules and hooks them up with the common
> bootstrap.
> > > Why do you say that WebOS shares hardly any code?
> >
>
> What I meant about WebOS, was just that it overwrites most of the APIs.
> There is a distinct difference in the way the platforms without a native
> counterpart are authored. (bada, windows8, tizen, bb-webworks, ..)
>

Where do you see it overwriting things? I see a few clobbers / merges in
their platform.js files, but it looks like they re-use the bulk of the
common code. The main difference seems to be that they implement exec() via
a require() call, and the native code on iOS/Android maps to .js code in
their plugin directory.

What would the plugin-specific build system look like for our core plugins?
When you say that they will have pre-built JS, is that just using the
cordova packager as well? Or do you think some other functionality is
required?



>
>
> > >
> > > Blackberry certainly seems to be a bit different in that it looks like
> it
> > > is actually 4 platforms in one. Not sure why we don't just make it four
> > > separate platforms. Gord?
> > > That said, Blackberry uses the module system even more than other
> > > platforms. I think it would be a lot of work to make plugin within
> > > blackberry have it's own loading logic that selectively loads module
> > based
> > > on the sub-platform (if we went with a single-file pre-built approach).
> > >
> > > With the single-file prebuilt approach, I'd guess it would look
> something
> > > like this:
> > >
> > > plugin.xml says which .js file to include for the platform:
> > >
> > > <platform name="android">
> > >   <source-file src="filetransfer.js" />
> > > </platform>
> >
>
> And maybe even:
> <platform name="android">
>   <source-file src="filetransfer-common.js" />
>   <source-file src="filetransfer-android.js" />
> </platform>
> ...
>
>
>
> > >
> > >
> > > There is certainly a bug-report advantage to having each in its own .js
> > > file. If everything is in cordova.js, and we get bugs with "Error on
> line
> > > ##", we can't actually map that to a file. On the other hand, each
> > platform
> > > has bootstrap logic that must come after plugins are loaded. This might
> > > turn into a source of errors if we have a bunch of .js files being
> added
> > > via <script> tags.
> > >
> > >
> > > One aspect of plugin JS that I don't want to lose, is our separate pass
> > of
> > > module -> symbol (defaults/merges/clobbers). In fact, I think this is
> an
> > > area that we may wish to enhance in the future. E.g. a couple of
> releases
> > > ago we added the ability to print a deprecation message when old
> > namespaces
> > > are referenced. Other advantages of the system:
> > >   - Helps authors write modules side-effect free modules
> > >   - Allows us to detect symbol collisions
> > >   - Gives us control over when the modules are loaded
> > >      - e.g. We could add measurement to see how long this process takes
> > >      - e.g. We could experiment with lazy-loaded modules by using JS
> > > getters that return require(module)
> > >      - e.g. We could use this to support exposing Cordova APIs to
> iframes
> > >
> > >
> > > It might be possible for us to maintain the module->symbol mapping
> system
> > > if we had plugins use pre-built .js files. E.g. their .js could be a
> > > collection of cordova.define() calls, followed by a
> > > cordova.registerModuleMappings() call. Is that what you're thinking?
> >
>
> Yes, something like this.
> The plugin would be wrapped in a module-closure, and 'define' it's
> interface.
>
> cordova.define("my/namespace", function(require, exports, module) { });
>
> Some of this would need to reworked as currently we have 2 aliases for
> every plugin:
> navigator.accelerometer === cordova.plugin.accelerometer
>
> Are you sure? I just tested this in mobile-spec on iOS, and cordova.plugin
is undefined.


>
>
>
> > >
> > > In either way, I think I'd like to go ahead with this change of moving
> > > from lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I think
> > > this is a good first step for either proposal.
> > >
> > >
> > >
> > > On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen <
> > purplecabbage@gmail.com>wrote:
> > >
> > >> Hi Andrew,
> > >>
> > >> Having spent some time with this, I don't think it's awful, but I am
> > >> worried about complexity.
> > >>
> > >> To me, a better approach is:
> > >>
> > >> - all plugins are simply ripped out of cordova-js
> > >> - each plugin is distributed 'built' meaning for an API like file or
> > >> contacts, there is only 1 js file, and while it depends on cordova.js,
> > >> it is not part of it. ( or possibly just a concat )
> > >> - plugman does the work of adding/removing but it is really just
> > >> changing script tags for the js portion
> > >>
> > >> This means all our core plugs will need to be modified as the
> > >> currently depend on the builder to wrap them.
> > >>
> > >> I spent some time working with your approach Andrew, and I think it
> > >> sounds better than it is. Blackberry has 4 inter-related branches to
> > >> consider, webos shares hardly any code with the other platforms, ... I
> > >> am more keen on adding consistency than  I am to making the tool work
> > >> around it.
> > >>
> > >> If we were only concerned with iOS, Android, and windows phone, then
> > >> your  approach might be best, but there are some messes in there.
> > >>
> > >> I will continue to push for the simpler solution, but I won't block
> > >> you anymore.
> > >> I do think you should dive a little deeper into your approach, and
> > >> possibly prove me wrong. I am completely open to further discussion on
> > >> the point.
> > >>
> > >>
> > >> Cheers,
> > >>  Jesse
> > >>
> > >> Sent from my iPhone5
> > >>
> > >> On 2013-01-10, at 8:09 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
> > >>
> > >> On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner <gt...@gmail.com>
> wrote:
> > >>
> > >> > Ideally the require paths should stay true to the following rules
> (not
> > >> that
> > >> > we follow them exactly now but we are close):
> > >> >
> > >> > 1. should always start with cordova (in case we ever share a require
> > >> > framework)
> > >> > 2. should follow as close as possible to the folder structure.
> > >> >
> > >> > We don't really do this now (but we are close).  It is mainly to
> help
> > >> with
> > >> > navigation of the project from a require statement:
> > >> >
> > >> >    var foo = require('cordova/plugin/foo/submodule')
> > >> >
> > >> > Ideally I should be able to navigate to a file that lives in:
> > >> >
> > >> >    ~/cordova.js/plugin/foo/submodule.js
> > >> >
> > >> > But realistically we are probably going to see:
> > >> >
> > >> >   ~/cordova.js/plugin/foo/js/submodule.js
> > >> >
> > >> > Assuming we are dumping everything into a js folder here is the
> > >> "mapping"
> > >> > off the top of my head:
> > >> >
> > >> >   var foo = require('cordova/plugin/foo')
> > >> >   ~/cordova.js/plugin/foo/js/index.js
> > >> >
> > >> >   var foo = require('cordova/plugin/foo/ios')
> > >> >   ~/cordova.js/plugin/foo/js/ios.js
> > >> >
> > >> >   var foo = require('cordova/plugin/foo/blackberry/qnx')
> > >> >   ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> > >> >
> > >> > What does a plugin (native and js code) folder structure look like?
> > >>
> > >>
> > >> Have a look at this plugin: https://github.com/shazron/KeychainPlugin
> > >>
> > >> With the JS changes I'm proposing, it would look like:
> > >> /src/ios/*.h, *.m
> > >> /www  <- empty!
> > >> /src/js/common/keychain.js
> > >>   or
> > >> /src/js/ios/keychain.js
> > >>
> > >> So, the idea behind moving all of the plugins to /plugin/$PLUGIN_NAME
> > >> within cordova-js, is that when they move out, there will be the
> > mapping:
> > >> cordova-js/plugin/$PLUGIN_NAME --->  $PLUGIN_REPO/src/js
> > >>
> > >>
> > >> When a plugin is installed into a project via cordova-cli, I suggest
> > that
> > >> we get a structure like this:
> > >>
> > >> MyApp/platforms/ios/... same as before ...
> > >> MyApp/cordova-js/... copy of cordova-js
> > >> MyApp/cordova-js/plugin/keychain/common/keychain.js
> > >> MyApp/plugins/keychain/plugin.xml
> > >> MyApp/www
> > >>
> > >> So, the idea here is that the cordova-js will have no top-level
> plugin/
> > >> directory, but one will be added when plugins are added.
> > >>
> > >> Also, like other sources, .js file should be listed in the plugin.xml
> so
> > >> that they can be reliably removed.
> > >>
> > >>
> > >>
> > >> About the require paths. I think for files in cordova-js, the prefix
> > >> should
> > >> be "cordova/", but for plugin files, it should be "plugin/" (or maybe
> > >> "cordovaplugin/"?), so that plugin JS doesn't accidentally clobber
> core
> > >> cordova modules.
> > >>
> > >> For the keychain example: require('cordovaplugin/keychain/keychain')
> > >>
> > >>
> > >> In terms of changes to the builder, we'd need to add the idea of
> > multiple
> > >> roots. Instead of just 'lib', there will also be 'plugin' as a root.
> > >>
> > >>
> > >>
> > >>
> > >> >
> > >> > On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
> > >> wrote:
> > >> >
> > >> >> I'd like to take a first step towards moving plugin JS into
> separate
> > >> > repos
> > >> >> by first moving them around within cordova-js.
> > >> >>
> > >> >> Here is my proposal:
> > >> >>
> > >> >> Current structure:
> > >> >>       lib/common/plugin/*.js
> > >> >>       lib/$PLATFORM/plugin/*.js
> > >> >>
> > >> >> New structure:
> > >> >>       plugin/$PLUGIN_NAME/js/common/*.js
> > >> >>       plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> > >> >>
> > >> >> The require path will need to change. Going from:
> > >> >>       cordova.require('cordova/plugin/FileTransferError')
> > >> >> To:
> > >> >>       cordova.require('plugin/file/FileTransferError')
> > >> >>
> > >> >>
> > >> >> I'll obviously need to update the builder scripts accordingly. The
> > idea
> > >> >> here is that we:
> > >> >>       1. "cordova plugin add" will copy files into a project's
> > plugins
> > >> >> directory
> > >> >>       2. "cordova build ios" will use the cordova-js packager and
> > pass
> > >> > it
> > >> >> the plugin/ directory to use
> > >> >>
> > >> >> This will not involve changing how we export modules onto
> namespaces
> > in
> > >> >> common.js / platform.js. That will come next though.
> > >> >>
> > >> >>
> > >> >> The resulting structure will look like:
> > >> >>
> > >> >> plugin/accelerometer/js/common/Acceleration.js
> > >> >> plugin/accelerometer/js/common/accelerometer.js
> > >> >> plugin/battery/js/common/battery.js
> > >> >> plugin/compass/js/common/Compass*.js
> > >> >> plugin/contacts/js/common/Contact*.js
> > >> >> plugin/device/js/common/device.js
> > >> >> plugin/geolocation/js/common/Coordinates.js
> > >> >> plugin/geolocation/js/common/Position*.js
> > >> >> plugin/globalization/js/common/Globalization*.js
> > >> >> plugin/inappbrowser/js/common/InAppBrowser.js
> > >> >> plugin/logger/js/common/logger.js
> > >> >> plugin/logger/js/common/console-via-logger.js
> > >> >> plugin/media/js/common/Capture*.js
> > >> >> plugin/media/js/common/ConfigurationData.js
> > >> >> plugin/media/js/common/Media*.js
> > >> >> plugin/network/js/common/Connection.js
> > >> >> plugin/notification/js/common/notification.js
> > >> >> plugin/camera/js/common/Camera*.js
> > >> >> plugin/echo/js/common/echo.js
> > >> >> plugin/file/js/common/Directory*.js
> > >> >> plugin/file/js/common/Entry.js
> > >> >> plugin/file/js/common/File*.js
> > >> >> plugin/file/js/common/Flags.js
> > >> >> plugin/file/js/common/LocalFileSystem.js
> > >> >> plugin/file/js/common/Metadata.js
> > >> >> plugin/file/js/common/ProgressEvent.js
> > >> >> plugin/splashscreen/js/common/splashscreen.js
> > >> >
> > >>
> > >
> > >
> >
>
>
>
> --
> @purplecabbage
> risingj.com
>

Re: Moving plugin JS files around

Posted by Jesse <pu...@gmail.com>.

Comments inline below.


On Mon, Jan 14, 2013 at 11:43 AM, Andrew Grieve <ag...@chromium.org>wrote:

> Created a bug for the file moving part (CB-2214), but we can
> continue discussing here.
>
>
> On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > Jesse, thanks for the explanation. Certainly my experience is just with
> > Android & iOS, so it's good to get opinions from the other platforms.
> >
> > I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in all
> > of the shared plugin modules and hooks them up with the common bootstrap.
> > Why do you say that WebOS shares hardly any code?
>

What I meant about WebOS, was just that it overwrites most of the APIs.
There is a distinct difference in the way the platforms without a native
counterpart are authored. (bada, windows8, tizen, bb-webworks, ..)


> >
> > Blackberry certainly seems to be a bit different in that it looks like it
> > is actually 4 platforms in one. Not sure why we don't just make it four
> > separate platforms. Gord?
> > That said, Blackberry uses the module system even more than other
> > platforms. I think it would be a lot of work to make plugin within
> > blackberry have it's own loading logic that selectively loads module
> based
> > on the sub-platform (if we went with a single-file pre-built approach).
> >
> > With the single-file prebuilt approach, I'd guess it would look something
> > like this:
> >
> > plugin.xml says which .js file to include for the platform:
> >
> > <platform name="android">
> >   <source-file src="filetransfer.js" />
> > </platform>
>

And maybe even:
<platform name="android">
  <source-file src="filetransfer-common.js" />
  <source-file src="filetransfer-android.js" />
</platform>
...



> >
> >
> > There is certainly a bug-report advantage to having each in its own .js
> > file. If everything is in cordova.js, and we get bugs with "Error on line
> > ##", we can't actually map that to a file. On the other hand, each
> platform
> > has bootstrap logic that must come after plugins are loaded. This might
> > turn into a source of errors if we have a bunch of .js files being added
> > via <script> tags.
> >
> >
> > One aspect of plugin JS that I don't want to lose, is our separate pass
> of
> > module -> symbol (defaults/merges/clobbers). In fact, I think this is an
> > area that we may wish to enhance in the future. E.g. a couple of releases
> > ago we added the ability to print a deprecation message when old
> namespaces
> > are referenced. Other advantages of the system:
> >   - Helps authors write modules side-effect free modules
> >   - Allows us to detect symbol collisions
> >   - Gives us control over when the modules are loaded
> >      - e.g. We could add measurement to see how long this process takes
> >      - e.g. We could experiment with lazy-loaded modules by using JS
> > getters that return require(module)
> >      - e.g. We could use this to support exposing Cordova APIs to iframes
> >
> >
> > It might be possible for us to maintain the module->symbol mapping system
> > if we had plugins use pre-built .js files. E.g. their .js could be a
> > collection of cordova.define() calls, followed by a
> > cordova.registerModuleMappings() call. Is that what you're thinking?
>

Yes, something like this.
The plugin would be wrapped in a module-closure, and 'define' it's
interface.

cordova.define("my/namespace", function(require, exports, module) { });

Some of this would need to reworked as currently we have 2 aliases for
every plugin:
navigator.accelerometer === cordova.plugin.accelerometer




> >
> > In either way, I think I'd like to go ahead with this change of moving
> > from lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I think
> > this is a good first step for either proposal.
> >
> >
> >
> > On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen <
> purplecabbage@gmail.com>wrote:
> >
> >> Hi Andrew,
> >>
> >> Having spent some time with this, I don't think it's awful, but I am
> >> worried about complexity.
> >>
> >> To me, a better approach is:
> >>
> >> - all plugins are simply ripped out of cordova-js
> >> - each plugin is distributed 'built' meaning for an API like file or
> >> contacts, there is only 1 js file, and while it depends on cordova.js,
> >> it is not part of it. ( or possibly just a concat )
> >> - plugman does the work of adding/removing but it is really just
> >> changing script tags for the js portion
> >>
> >> This means all our core plugs will need to be modified as the
> >> currently depend on the builder to wrap them.
> >>
> >> I spent some time working with your approach Andrew, and I think it
> >> sounds better than it is. Blackberry has 4 inter-related branches to
> >> consider, webos shares hardly any code with the other platforms, ... I
> >> am more keen on adding consistency than  I am to making the tool work
> >> around it.
> >>
> >> If we were only concerned with iOS, Android, and windows phone, then
> >> your  approach might be best, but there are some messes in there.
> >>
> >> I will continue to push for the simpler solution, but I won't block
> >> you anymore.
> >> I do think you should dive a little deeper into your approach, and
> >> possibly prove me wrong. I am completely open to further discussion on
> >> the point.
> >>
> >>
> >> Cheers,
> >>  Jesse
> >>
> >> Sent from my iPhone5
> >>
> >> On 2013-01-10, at 8:09 PM, Andrew Grieve <ag...@chromium.org> wrote:
> >>
> >> On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner <gt...@gmail.com> wrote:
> >>
> >> > Ideally the require paths should stay true to the following rules (not
> >> that
> >> > we follow them exactly now but we are close):
> >> >
> >> > 1. should always start with cordova (in case we ever share a require
> >> > framework)
> >> > 2. should follow as close as possible to the folder structure.
> >> >
> >> > We don't really do this now (but we are close).  It is mainly to help
> >> with
> >> > navigation of the project from a require statement:
> >> >
> >> >    var foo = require('cordova/plugin/foo/submodule')
> >> >
> >> > Ideally I should be able to navigate to a file that lives in:
> >> >
> >> >    ~/cordova.js/plugin/foo/submodule.js
> >> >
> >> > But realistically we are probably going to see:
> >> >
> >> >   ~/cordova.js/plugin/foo/js/submodule.js
> >> >
> >> > Assuming we are dumping everything into a js folder here is the
> >> "mapping"
> >> > off the top of my head:
> >> >
> >> >   var foo = require('cordova/plugin/foo')
> >> >   ~/cordova.js/plugin/foo/js/index.js
> >> >
> >> >   var foo = require('cordova/plugin/foo/ios')
> >> >   ~/cordova.js/plugin/foo/js/ios.js
> >> >
> >> >   var foo = require('cordova/plugin/foo/blackberry/qnx')
> >> >   ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> >> >
> >> > What does a plugin (native and js code) folder structure look like?
> >>
> >>
> >> Have a look at this plugin: https://github.com/shazron/KeychainPlugin
> >>
> >> With the JS changes I'm proposing, it would look like:
> >> /src/ios/*.h, *.m
> >> /www  <- empty!
> >> /src/js/common/keychain.js
> >>   or
> >> /src/js/ios/keychain.js
> >>
> >> So, the idea behind moving all of the plugins to /plugin/$PLUGIN_NAME
> >> within cordova-js, is that when they move out, there will be the
> mapping:
> >> cordova-js/plugin/$PLUGIN_NAME --->  $PLUGIN_REPO/src/js
> >>
> >>
> >> When a plugin is installed into a project via cordova-cli, I suggest
> that
> >> we get a structure like this:
> >>
> >> MyApp/platforms/ios/... same as before ...
> >> MyApp/cordova-js/... copy of cordova-js
> >> MyApp/cordova-js/plugin/keychain/common/keychain.js
> >> MyApp/plugins/keychain/plugin.xml
> >> MyApp/www
> >>
> >> So, the idea here is that the cordova-js will have no top-level plugin/
> >> directory, but one will be added when plugins are added.
> >>
> >> Also, like other sources, .js file should be listed in the plugin.xml so
> >> that they can be reliably removed.
> >>
> >>
> >>
> >> About the require paths. I think for files in cordova-js, the prefix
> >> should
> >> be "cordova/", but for plugin files, it should be "plugin/" (or maybe
> >> "cordovaplugin/"?), so that plugin JS doesn't accidentally clobber core
> >> cordova modules.
> >>
> >> For the keychain example: require('cordovaplugin/keychain/keychain')
> >>
> >>
> >> In terms of changes to the builder, we'd need to add the idea of
> multiple
> >> roots. Instead of just 'lib', there will also be 'plugin' as a root.
> >>
> >>
> >>
> >>
> >> >
> >> > On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
> >> wrote:
> >> >
> >> >> I'd like to take a first step towards moving plugin JS into separate
> >> > repos
> >> >> by first moving them around within cordova-js.
> >> >>
> >> >> Here is my proposal:
> >> >>
> >> >> Current structure:
> >> >>       lib/common/plugin/*.js
> >> >>       lib/$PLATFORM/plugin/*.js
> >> >>
> >> >> New structure:
> >> >>       plugin/$PLUGIN_NAME/js/common/*.js
> >> >>       plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> >> >>
> >> >> The require path will need to change. Going from:
> >> >>       cordova.require('cordova/plugin/FileTransferError')
> >> >> To:
> >> >>       cordova.require('plugin/file/FileTransferError')
> >> >>
> >> >>
> >> >> I'll obviously need to update the builder scripts accordingly. The
> idea
> >> >> here is that we:
> >> >>       1. "cordova plugin add" will copy files into a project's
> plugins
> >> >> directory
> >> >>       2. "cordova build ios" will use the cordova-js packager and
> pass
> >> > it
> >> >> the plugin/ directory to use
> >> >>
> >> >> This will not involve changing how we export modules onto namespaces
> in
> >> >> common.js / platform.js. That will come next though.
> >> >>
> >> >>
> >> >> The resulting structure will look like:
> >> >>
> >> >> plugin/accelerometer/js/common/Acceleration.js
> >> >> plugin/accelerometer/js/common/accelerometer.js
> >> >> plugin/battery/js/common/battery.js
> >> >> plugin/compass/js/common/Compass*.js
> >> >> plugin/contacts/js/common/Contact*.js
> >> >> plugin/device/js/common/device.js
> >> >> plugin/geolocation/js/common/Coordinates.js
> >> >> plugin/geolocation/js/common/Position*.js
> >> >> plugin/globalization/js/common/Globalization*.js
> >> >> plugin/inappbrowser/js/common/InAppBrowser.js
> >> >> plugin/logger/js/common/logger.js
> >> >> plugin/logger/js/common/console-via-logger.js
> >> >> plugin/media/js/common/Capture*.js
> >> >> plugin/media/js/common/ConfigurationData.js
> >> >> plugin/media/js/common/Media*.js
> >> >> plugin/network/js/common/Connection.js
> >> >> plugin/notification/js/common/notification.js
> >> >> plugin/camera/js/common/Camera*.js
> >> >> plugin/echo/js/common/echo.js
> >> >> plugin/file/js/common/Directory*.js
> >> >> plugin/file/js/common/Entry.js
> >> >> plugin/file/js/common/File*.js
> >> >> plugin/file/js/common/Flags.js
> >> >> plugin/file/js/common/LocalFileSystem.js
> >> >> plugin/file/js/common/Metadata.js
> >> >> plugin/file/js/common/ProgressEvent.js
> >> >> plugin/splashscreen/js/common/splashscreen.js
> >> >
> >>
> >
> >
>



-- 
@purplecabbage
risingj.com

Re: Moving plugin JS files around

Posted by Andrew Grieve <ag...@chromium.org>.

Created a bug for the file moving part (CB-2214), but we can
continue discussing here.


On Mon, Jan 14, 2013 at 2:39 PM, Andrew Grieve <ag...@chromium.org> wrote:

> Jesse, thanks for the explanation. Certainly my experience is just with
> Android & iOS, so it's good to get opinions from the other platforms.
>
> I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in all
> of the shared plugin modules and hooks them up with the common bootstrap.
> Why do you say that WebOS shares hardly any code?
>
> Blackberry certainly seems to be a bit different in that it looks like it
> is actually 4 platforms in one. Not sure why we don't just make it four
> separate platforms. Gord?
> That said, Blackberry uses the module system even more than other
> platforms. I think it would be a lot of work to make plugin within
> blackberry have it's own loading logic that selectively loads module based
> on the sub-platform (if we went with a single-file pre-built approach).
>
> With the single-file prebuilt approach, I'd guess it would look something
> like this:
>
> plugin.xml says which .js file to include for the platform:
>
> <platform name="android">
>   <source-file src="filetransfer.js" />
> </platform>
>
>
> There is certainly a bug-report advantage to having each in its own .js
> file. If everything is in cordova.js, and we get bugs with "Error on line
> ##", we can't actually map that to a file. On the other hand, each platform
> has bootstrap logic that must come after plugins are loaded. This might
> turn into a source of errors if we have a bunch of .js files being added
> via <script> tags.
>
>
> One aspect of plugin JS that I don't want to lose, is our separate pass of
> module -> symbol (defaults/merges/clobbers). In fact, I think this is an
> area that we may wish to enhance in the future. E.g. a couple of releases
> ago we added the ability to print a deprecation message when old namespaces
> are referenced. Other advantages of the system:
>   - Helps authors write modules side-effect free modules
>   - Allows us to detect symbol collisions
>   - Gives us control over when the modules are loaded
>      - e.g. We could add measurement to see how long this process takes
>      - e.g. We could experiment with lazy-loaded modules by using JS
> getters that return require(module)
>      - e.g. We could use this to support exposing Cordova APIs to iframes
>
>
> It might be possible for us to maintain the module->symbol mapping system
> if we had plugins use pre-built .js files. E.g. their .js could be a
> collection of cordova.define() calls, followed by a
> cordova.registerModuleMappings() call. Is that what you're thinking?
>
> In either way, I think I'd like to go ahead with this change of moving
> from lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I think
> this is a good first step for either proposal.
>
>
>
> On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen <pu...@gmail.com>wrote:
>
>> Hi Andrew,
>>
>> Having spent some time with this, I don't think it's awful, but I am
>> worried about complexity.
>>
>> To me, a better approach is:
>>
>> - all plugins are simply ripped out of cordova-js
>> - each plugin is distributed 'built' meaning for an API like file or
>> contacts, there is only 1 js file, and while it depends on cordova.js,
>> it is not part of it. ( or possibly just a concat )
>> - plugman does the work of adding/removing but it is really just
>> changing script tags for the js portion
>>
>> This means all our core plugs will need to be modified as the
>> currently depend on the builder to wrap them.
>>
>> I spent some time working with your approach Andrew, and I think it
>> sounds better than it is. Blackberry has 4 inter-related branches to
>> consider, webos shares hardly any code with the other platforms, ... I
>> am more keen on adding consistency than  I am to making the tool work
>> around it.
>>
>> If we were only concerned with iOS, Android, and windows phone, then
>> your  approach might be best, but there are some messes in there.
>>
>> I will continue to push for the simpler solution, but I won't block
>> you anymore.
>> I do think you should dive a little deeper into your approach, and
>> possibly prove me wrong. I am completely open to further discussion on
>> the point.
>>
>>
>> Cheers,
>>  Jesse
>>
>> Sent from my iPhone5
>>
>> On 2013-01-10, at 8:09 PM, Andrew Grieve <ag...@chromium.org> wrote:
>>
>> On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner <gt...@gmail.com> wrote:
>>
>> > Ideally the require paths should stay true to the following rules (not
>> that
>> > we follow them exactly now but we are close):
>> >
>> > 1. should always start with cordova (in case we ever share a require
>> > framework)
>> > 2. should follow as close as possible to the folder structure.
>> >
>> > We don't really do this now (but we are close).  It is mainly to help
>> with
>> > navigation of the project from a require statement:
>> >
>> >    var foo = require('cordova/plugin/foo/submodule')
>> >
>> > Ideally I should be able to navigate to a file that lives in:
>> >
>> >    ~/cordova.js/plugin/foo/submodule.js
>> >
>> > But realistically we are probably going to see:
>> >
>> >   ~/cordova.js/plugin/foo/js/submodule.js
>> >
>> > Assuming we are dumping everything into a js folder here is the
>> "mapping"
>> > off the top of my head:
>> >
>> >   var foo = require('cordova/plugin/foo')
>> >   ~/cordova.js/plugin/foo/js/index.js
>> >
>> >   var foo = require('cordova/plugin/foo/ios')
>> >   ~/cordova.js/plugin/foo/js/ios.js
>> >
>> >   var foo = require('cordova/plugin/foo/blackberry/qnx')
>> >   ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>> >
>> > What does a plugin (native and js code) folder structure look like?
>>
>>
>> Have a look at this plugin: https://github.com/shazron/KeychainPlugin
>>
>> With the JS changes I'm proposing, it would look like:
>> /src/ios/*.h, *.m
>> /www  <- empty!
>> /src/js/common/keychain.js
>>   or
>> /src/js/ios/keychain.js
>>
>> So, the idea behind moving all of the plugins to /plugin/$PLUGIN_NAME
>> within cordova-js, is that when they move out, there will be the mapping:
>> cordova-js/plugin/$PLUGIN_NAME --->  $PLUGIN_REPO/src/js
>>
>>
>> When a plugin is installed into a project via cordova-cli, I suggest that
>> we get a structure like this:
>>
>> MyApp/platforms/ios/... same as before ...
>> MyApp/cordova-js/... copy of cordova-js
>> MyApp/cordova-js/plugin/keychain/common/keychain.js
>> MyApp/plugins/keychain/plugin.xml
>> MyApp/www
>>
>> So, the idea here is that the cordova-js will have no top-level plugin/
>> directory, but one will be added when plugins are added.
>>
>> Also, like other sources, .js file should be listed in the plugin.xml so
>> that they can be reliably removed.
>>
>>
>>
>> About the require paths. I think for files in cordova-js, the prefix
>> should
>> be "cordova/", but for plugin files, it should be "plugin/" (or maybe
>> "cordovaplugin/"?), so that plugin JS doesn't accidentally clobber core
>> cordova modules.
>>
>> For the keychain example: require('cordovaplugin/keychain/keychain')
>>
>>
>> In terms of changes to the builder, we'd need to add the idea of multiple
>> roots. Instead of just 'lib', there will also be 'plugin' as a root.
>>
>>
>>
>>
>> >
>> > On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
>> wrote:
>> >
>> >> I'd like to take a first step towards moving plugin JS into separate
>> > repos
>> >> by first moving them around within cordova-js.
>> >>
>> >> Here is my proposal:
>> >>
>> >> Current structure:
>> >>       lib/common/plugin/*.js
>> >>       lib/$PLATFORM/plugin/*.js
>> >>
>> >> New structure:
>> >>       plugin/$PLUGIN_NAME/js/common/*.js
>> >>       plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
>> >>
>> >> The require path will need to change. Going from:
>> >>       cordova.require('cordova/plugin/FileTransferError')
>> >> To:
>> >>       cordova.require('plugin/file/FileTransferError')
>> >>
>> >>
>> >> I'll obviously need to update the builder scripts accordingly. The idea
>> >> here is that we:
>> >>       1. "cordova plugin add" will copy files into a project's plugins
>> >> directory
>> >>       2. "cordova build ios" will use the cordova-js packager and pass
>> > it
>> >> the plugin/ directory to use
>> >>
>> >> This will not involve changing how we export modules onto namespaces in
>> >> common.js / platform.js. That will come next though.
>> >>
>> >>
>> >> The resulting structure will look like:
>> >>
>> >> plugin/accelerometer/js/common/Acceleration.js
>> >> plugin/accelerometer/js/common/accelerometer.js
>> >> plugin/battery/js/common/battery.js
>> >> plugin/compass/js/common/Compass*.js
>> >> plugin/contacts/js/common/Contact*.js
>> >> plugin/device/js/common/device.js
>> >> plugin/geolocation/js/common/Coordinates.js
>> >> plugin/geolocation/js/common/Position*.js
>> >> plugin/globalization/js/common/Globalization*.js
>> >> plugin/inappbrowser/js/common/InAppBrowser.js
>> >> plugin/logger/js/common/logger.js
>> >> plugin/logger/js/common/console-via-logger.js
>> >> plugin/media/js/common/Capture*.js
>> >> plugin/media/js/common/ConfigurationData.js
>> >> plugin/media/js/common/Media*.js
>> >> plugin/network/js/common/Connection.js
>> >> plugin/notification/js/common/notification.js
>> >> plugin/camera/js/common/Camera*.js
>> >> plugin/echo/js/common/echo.js
>> >> plugin/file/js/common/Directory*.js
>> >> plugin/file/js/common/Entry.js
>> >> plugin/file/js/common/File*.js
>> >> plugin/file/js/common/Flags.js
>> >> plugin/file/js/common/LocalFileSystem.js
>> >> plugin/file/js/common/Metadata.js
>> >> plugin/file/js/common/ProgressEvent.js
>> >> plugin/splashscreen/js/common/splashscreen.js
>> >
>>
>
>

Re: Moving plugin JS files around

Posted by Andrew Grieve <ag...@chromium.org>.

Jesse, thanks for the explanation. Certainly my experience is just with
Android & iOS, so it's good to get opinions from the other platforms.

I took a look at WebOS, but pkg/cordova.webos.js does seem to pull in all
of the shared plugin modules and hooks them up with the common bootstrap.
Why do you say that WebOS shares hardly any code?

Blackberry certainly seems to be a bit different in that it looks like it
is actually 4 platforms in one. Not sure why we don't just make it four
separate platforms. Gord?
That said, Blackberry uses the module system even more than other
platforms. I think it would be a lot of work to make plugin within
blackberry have it's own loading logic that selectively loads module based
on the sub-platform (if we went with a single-file pre-built approach).

With the single-file prebuilt approach, I'd guess it would look something
like this:

plugin.xml says which .js file to include for the platform:

<platform name="android">
  <source-file src="filetransfer.js" />
</platform>


There is certainly a bug-report advantage to having each in its own .js
file. If everything is in cordova.js, and we get bugs with "Error on line
##", we can't actually map that to a file. On the other hand, each platform
has bootstrap logic that must come after plugins are loaded. This might
turn into a source of errors if we have a bunch of .js files being added
via <script> tags.


One aspect of plugin JS that I don't want to lose, is our separate pass of
module -> symbol (defaults/merges/clobbers). In fact, I think this is an
area that we may wish to enhance in the future. E.g. a couple of releases
ago we added the ability to print a deprecation message when old namespaces
are referenced. Other advantages of the system:
  - Helps authors write modules side-effect free modules
  - Allows us to detect symbol collisions
  - Gives us control over when the modules are loaded
     - e.g. We could add measurement to see how long this process takes
     - e.g. We could experiment with lazy-loaded modules by using JS
getters that return require(module)
     - e.g. We could use this to support exposing Cordova APIs to iframes


It might be possible for us to maintain the module->symbol mapping system
if we had plugins use pre-built .js files. E.g. their .js could be a
collection of cordova.define() calls, followed by a
cordova.registerModuleMappings() call. Is that what you're thinking?

In either way, I think I'd like to go ahead with this change of moving from
lib/$PLATFORM/plugin to plugin/PLUGIN_NAME/PLATFORM, since I think this is
a good first step for either proposal.



On Fri, Jan 11, 2013 at 1:48 PM, Jesse MacFadyen <pu...@gmail.com>wrote:

> Hi Andrew,
>
> Having spent some time with this, I don't think it's awful, but I am
> worried about complexity.
>
> To me, a better approach is:
>
> - all plugins are simply ripped out of cordova-js
> - each plugin is distributed 'built' meaning for an API like file or
> contacts, there is only 1 js file, and while it depends on cordova.js,
> it is not part of it. ( or possibly just a concat )
> - plugman does the work of adding/removing but it is really just
> changing script tags for the js portion
>
> This means all our core plugs will need to be modified as the
> currently depend on the builder to wrap them.
>
> I spent some time working with your approach Andrew, and I think it
> sounds better than it is. Blackberry has 4 inter-related branches to
> consider, webos shares hardly any code with the other platforms, ... I
> am more keen on adding consistency than  I am to making the tool work
> around it.
>
> If we were only concerned with iOS, Android, and windows phone, then
> your  approach might be best, but there are some messes in there.
>
> I will continue to push for the simpler solution, but I won't block
> you anymore.
> I do think you should dive a little deeper into your approach, and
> possibly prove me wrong. I am completely open to further discussion on
> the point.
>
>
> Cheers,
>  Jesse
>
> Sent from my iPhone5
>
> On 2013-01-10, at 8:09 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
> On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner <gt...@gmail.com> wrote:
>
> > Ideally the require paths should stay true to the following rules (not
> that
> > we follow them exactly now but we are close):
> >
> > 1. should always start with cordova (in case we ever share a require
> > framework)
> > 2. should follow as close as possible to the folder structure.
> >
> > We don't really do this now (but we are close).  It is mainly to help
> with
> > navigation of the project from a require statement:
> >
> >    var foo = require('cordova/plugin/foo/submodule')
> >
> > Ideally I should be able to navigate to a file that lives in:
> >
> >    ~/cordova.js/plugin/foo/submodule.js
> >
> > But realistically we are probably going to see:
> >
> >   ~/cordova.js/plugin/foo/js/submodule.js
> >
> > Assuming we are dumping everything into a js folder here is the "mapping"
> > off the top of my head:
> >
> >   var foo = require('cordova/plugin/foo')
> >   ~/cordova.js/plugin/foo/js/index.js
> >
> >   var foo = require('cordova/plugin/foo/ios')
> >   ~/cordova.js/plugin/foo/js/ios.js
> >
> >   var foo = require('cordova/plugin/foo/blackberry/qnx')
> >   ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> >
> > What does a plugin (native and js code) folder structure look like?
>
>
> Have a look at this plugin: https://github.com/shazron/KeychainPlugin
>
> With the JS changes I'm proposing, it would look like:
> /src/ios/*.h, *.m
> /www  <- empty!
> /src/js/common/keychain.js
>   or
> /src/js/ios/keychain.js
>
> So, the idea behind moving all of the plugins to /plugin/$PLUGIN_NAME
> within cordova-js, is that when they move out, there will be the mapping:
> cordova-js/plugin/$PLUGIN_NAME --->  $PLUGIN_REPO/src/js
>
>
> When a plugin is installed into a project via cordova-cli, I suggest that
> we get a structure like this:
>
> MyApp/platforms/ios/... same as before ...
> MyApp/cordova-js/... copy of cordova-js
> MyApp/cordova-js/plugin/keychain/common/keychain.js
> MyApp/plugins/keychain/plugin.xml
> MyApp/www
>
> So, the idea here is that the cordova-js will have no top-level plugin/
> directory, but one will be added when plugins are added.
>
> Also, like other sources, .js file should be listed in the plugin.xml so
> that they can be reliably removed.
>
>
>
> About the require paths. I think for files in cordova-js, the prefix should
> be "cordova/", but for plugin files, it should be "plugin/" (or maybe
> "cordovaplugin/"?), so that plugin JS doesn't accidentally clobber core
> cordova modules.
>
> For the keychain example: require('cordovaplugin/keychain/keychain')
>
>
> In terms of changes to the builder, we'd need to add the idea of multiple
> roots. Instead of just 'lib', there will also be 'plugin' as a root.
>
>
>
>
> >
> > On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
> wrote:
> >
> >> I'd like to take a first step towards moving plugin JS into separate
> > repos
> >> by first moving them around within cordova-js.
> >>
> >> Here is my proposal:
> >>
> >> Current structure:
> >>       lib/common/plugin/*.js
> >>       lib/$PLATFORM/plugin/*.js
> >>
> >> New structure:
> >>       plugin/$PLUGIN_NAME/js/common/*.js
> >>       plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> >>
> >> The require path will need to change. Going from:
> >>       cordova.require('cordova/plugin/FileTransferError')
> >> To:
> >>       cordova.require('plugin/file/FileTransferError')
> >>
> >>
> >> I'll obviously need to update the builder scripts accordingly. The idea
> >> here is that we:
> >>       1. "cordova plugin add" will copy files into a project's plugins
> >> directory
> >>       2. "cordova build ios" will use the cordova-js packager and pass
> > it
> >> the plugin/ directory to use
> >>
> >> This will not involve changing how we export modules onto namespaces in
> >> common.js / platform.js. That will come next though.
> >>
> >>
> >> The resulting structure will look like:
> >>
> >> plugin/accelerometer/js/common/Acceleration.js
> >> plugin/accelerometer/js/common/accelerometer.js
> >> plugin/battery/js/common/battery.js
> >> plugin/compass/js/common/Compass*.js
> >> plugin/contacts/js/common/Contact*.js
> >> plugin/device/js/common/device.js
> >> plugin/geolocation/js/common/Coordinates.js
> >> plugin/geolocation/js/common/Position*.js
> >> plugin/globalization/js/common/Globalization*.js
> >> plugin/inappbrowser/js/common/InAppBrowser.js
> >> plugin/logger/js/common/logger.js
> >> plugin/logger/js/common/console-via-logger.js
> >> plugin/media/js/common/Capture*.js
> >> plugin/media/js/common/ConfigurationData.js
> >> plugin/media/js/common/Media*.js
> >> plugin/network/js/common/Connection.js
> >> plugin/notification/js/common/notification.js
> >> plugin/camera/js/common/Camera*.js
> >> plugin/echo/js/common/echo.js
> >> plugin/file/js/common/Directory*.js
> >> plugin/file/js/common/Entry.js
> >> plugin/file/js/common/File*.js
> >> plugin/file/js/common/Flags.js
> >> plugin/file/js/common/LocalFileSystem.js
> >> plugin/file/js/common/Metadata.js
> >> plugin/file/js/common/ProgressEvent.js
> >> plugin/splashscreen/js/common/splashscreen.js
> >
>

Re: Moving plugin JS files around

Posted by Jesse MacFadyen <pu...@gmail.com>.

Hi Andrew,

Having spent some time with this, I don't think it's awful, but I am
worried about complexity.

To me, a better approach is:

- all plugins are simply ripped out of cordova-js
- each plugin is distributed 'built' meaning for an API like file or
contacts, there is only 1 js file, and while it depends on cordova.js,
it is not part of it. ( or possibly just a concat )
- plugman does the work of adding/removing but it is really just
changing script tags for the js portion

This means all our core plugs will need to be modified as the
currently depend on the builder to wrap them.

I spent some time working with your approach Andrew, and I think it
sounds better than it is. Blackberry has 4 inter-related branches to
consider, webos shares hardly any code with the other platforms, ... I
am more keen on adding consistency than  I am to making the tool work
around it.

If we were only concerned with iOS, Android, and windows phone, then
your  approach might be best, but there are some messes in there.

I will continue to push for the simpler solution, but I won't block
you anymore.
I do think you should dive a little deeper into your approach, and
possibly prove me wrong. I am completely open to further discussion on
the point.

Cheers,
 Jesse

Sent from my iPhone5

On 2013-01-10, at 8:09 PM, Andrew Grieve <ag...@chromium.org> wrote:

On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner <gt...@gmail.com> wrote:

> Ideally the require paths should stay true to the following rules (not that
> we follow them exactly now but we are close):
>
> 1. should always start with cordova (in case we ever share a require
> framework)
> 2. should follow as close as possible to the folder structure.
>
> We don't really do this now (but we are close).  It is mainly to help with
> navigation of the project from a require statement:
>
>    var foo = require('cordova/plugin/foo/submodule')
>
> Ideally I should be able to navigate to a file that lives in:
>
>    ~/cordova.js/plugin/foo/submodule.js
>
> But realistically we are probably going to see:
>
>   ~/cordova.js/plugin/foo/js/submodule.js
>
> Assuming we are dumping everything into a js folder here is the "mapping"
> off the top of my head:
>
>   var foo = require('cordova/plugin/foo')
>   ~/cordova.js/plugin/foo/js/index.js
>
>   var foo = require('cordova/plugin/foo/ios')
>   ~/cordova.js/plugin/foo/js/ios.js
>
>   var foo = require('cordova/plugin/foo/blackberry/qnx')
>   ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>
> What does a plugin (native and js code) folder structure look like?

Have a look at this plugin: https://github.com/shazron/KeychainPlugin

With the JS changes I'm proposing, it would look like:
/src/ios/*.h, *.m
/www  <- empty!
/src/js/common/keychain.js
  or
/src/js/ios/keychain.js

So, the idea behind moving all of the plugins to /plugin/$PLUGIN_NAME
within cordova-js, is that when they move out, there will be the mapping:
cordova-js/plugin/$PLUGIN_NAME --->  $PLUGIN_REPO/src/js

When a plugin is installed into a project via cordova-cli, I suggest that
we get a structure like this:

MyApp/platforms/ios/... same as before ...
MyApp/cordova-js/... copy of cordova-js
MyApp/cordova-js/plugin/keychain/common/keychain.js
MyApp/plugins/keychain/plugin.xml
MyApp/www

So, the idea here is that the cordova-js will have no top-level plugin/
directory, but one will be added when plugins are added.

Also, like other sources, .js file should be listed in the plugin.xml so
that they can be reliably removed.

About the require paths. I think for files in cordova-js, the prefix should
be "cordova/", but for plugin files, it should be "plugin/" (or maybe
"cordovaplugin/"?), so that plugin JS doesn't accidentally clobber core
cordova modules.

For the keychain example: require('cordovaplugin/keychain/keychain')

In terms of changes to the builder, we'd need to add the idea of multiple
roots. Instead of just 'lib', there will also be 'plugin' as a root.

>
> On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com> wrote:
>
>> I'd like to take a first step towards moving plugin JS into separate
> repos
>> by first moving them around within cordova-js.
>>
>> Here is my proposal:
>>
>> Current structure:
>>       lib/common/plugin/*.js
>>       lib/$PLATFORM/plugin/*.js
>>
>> New structure:
>>       plugin/$PLUGIN_NAME/js/common/*.js
>>       plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
>>
>> The require path will need to change. Going from:
>>       cordova.require('cordova/plugin/FileTransferError')
>> To:
>>       cordova.require('plugin/file/FileTransferError')
>>
>>
>> I'll obviously need to update the builder scripts accordingly. The idea
>> here is that we:
>>       1. "cordova plugin add" will copy files into a project's plugins
>> directory
>>       2. "cordova build ios" will use the cordova-js packager and pass
> it
>> the plugin/ directory to use
>>
>> This will not involve changing how we export modules onto namespaces in
>> common.js / platform.js. That will come next though.
>>
>>
>> The resulting structure will look like:
>>
>> plugin/accelerometer/js/common/Acceleration.js
>> plugin/accelerometer/js/common/accelerometer.js
>> plugin/battery/js/common/battery.js
>> plugin/compass/js/common/Compass*.js
>> plugin/contacts/js/common/Contact*.js
>> plugin/device/js/common/device.js
>> plugin/geolocation/js/common/Coordinates.js
>> plugin/geolocation/js/common/Position*.js
>> plugin/globalization/js/common/Globalization*.js
>> plugin/inappbrowser/js/common/InAppBrowser.js
>> plugin/logger/js/common/logger.js
>> plugin/logger/js/common/console-via-logger.js
>> plugin/media/js/common/Capture*.js
>> plugin/media/js/common/ConfigurationData.js
>> plugin/media/js/common/Media*.js
>> plugin/network/js/common/Connection.js
>> plugin/notification/js/common/notification.js
>> plugin/camera/js/common/Camera*.js
>> plugin/echo/js/common/echo.js
>> plugin/file/js/common/Directory*.js
>> plugin/file/js/common/Entry.js
>> plugin/file/js/common/File*.js
>> plugin/file/js/common/Flags.js
>> plugin/file/js/common/LocalFileSystem.js
>> plugin/file/js/common/Metadata.js
>> plugin/file/js/common/ProgressEvent.js
>> plugin/splashscreen/js/common/splashscreen.js
>

Re: Moving plugin JS files around

Posted by Andrew Grieve <ag...@chromium.org>.

On Wed, Jan 9, 2013 at 10:28 AM, Gord Tanner <gt...@gmail.com> wrote:

> Ideally the require paths should stay true to the following rules (not that
> we follow them exactly now but we are close):
>
> 1. should always start with cordova (in case we ever share a require
> framework)
> 2. should follow as close as possible to the folder structure.
>
> We don't really do this now (but we are close).  It is mainly to help with
> navigation of the project from a require statement:
>
>      var foo = require('cordova/plugin/foo/submodule')
>
> Ideally I should be able to navigate to a file that lives in:
>
>      ~/cordova.js/plugin/foo/submodule.js
>
> But realistically we are probably going to see:
>
>     ~/cordova.js/plugin/foo/js/submodule.js
>
> Assuming we are dumping everything into a js folder here is the "mapping"
> off the top of my head:
>
>     var foo = require('cordova/plugin/foo')
>     ~/cordova.js/plugin/foo/js/index.js
>
>     var foo = require('cordova/plugin/foo/ios')
>     ~/cordova.js/plugin/foo/js/ios.js
>
>     var foo = require('cordova/plugin/foo/blackberry/qnx')
>     ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>
> What does a plugin (native and js code) folder structure look like?
>


Have a look at this plugin: https://github.com/shazron/KeychainPlugin

With the JS changes I'm proposing, it would look like:
/src/ios/*.h, *.m
/www  <- empty!
/src/js/common/keychain.js
    or
/src/js/ios/keychain.js

So, the idea behind moving all of the plugins to /plugin/$PLUGIN_NAME
within cordova-js, is that when they move out, there will be the mapping:
cordova-js/plugin/$PLUGIN_NAME --->  $PLUGIN_REPO/src/js


When a plugin is installed into a project via cordova-cli, I suggest that
we get a structure like this:

MyApp/platforms/ios/... same as before ...
MyApp/cordova-js/... copy of cordova-js
MyApp/cordova-js/plugin/keychain/common/keychain.js
MyApp/plugins/keychain/plugin.xml
MyApp/www

So, the idea here is that the cordova-js will have no top-level plugin/
directory, but one will be added when plugins are added.

Also, like other sources, .js file should be listed in the plugin.xml so
that they can be reliably removed.



About the require paths. I think for files in cordova-js, the prefix should
be "cordova/", but for plugin files, it should be "plugin/" (or maybe
"cordovaplugin/"?), so that plugin JS doesn't accidentally clobber core
cordova modules.

For the keychain example: require('cordovaplugin/keychain/keychain')


In terms of changes to the builder, we'd need to add the idea of multiple
roots. Instead of just 'lib', there will also be 'plugin' as a root.




>
> On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com> wrote:
>
> > I'd like to take a first step towards moving plugin JS into separate
> repos
> > by first moving them around within cordova-js.
> >
> > Here is my proposal:
> >
> > Current structure:
> >         lib/common/plugin/*.js
> >         lib/$PLATFORM/plugin/*.js
> >
> > New structure:
> >         plugin/$PLUGIN_NAME/js/common/*.js
> >         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> >
> > The require path will need to change. Going from:
> >         cordova.require('cordova/plugin/FileTransferError')
> > To:
> >         cordova.require('plugin/file/FileTransferError')
> >
> >
> > I'll obviously need to update the builder scripts accordingly. The idea
> > here is that we:
> >         1. "cordova plugin add" will copy files into a project's plugins
> > directory
> >         2. "cordova build ios" will use the cordova-js packager and pass
> it
> > the plugin/ directory to use
> >
> > This will not involve changing how we export modules onto namespaces in
> > common.js / platform.js. That will come next though.
> >
> >
> > The resulting structure will look like:
> >
> > plugin/accelerometer/js/common/Acceleration.js
> > plugin/accelerometer/js/common/accelerometer.js
> > plugin/battery/js/common/battery.js
> > plugin/compass/js/common/Compass*.js
> > plugin/contacts/js/common/Contact*.js
> > plugin/device/js/common/device.js
> > plugin/geolocation/js/common/Coordinates.js
> > plugin/geolocation/js/common/Position*.js
> > plugin/globalization/js/common/Globalization*.js
> > plugin/inappbrowser/js/common/InAppBrowser.js
> > plugin/logger/js/common/logger.js
> > plugin/logger/js/common/console-via-logger.js
> > plugin/media/js/common/Capture*.js
> > plugin/media/js/common/ConfigurationData.js
> > plugin/media/js/common/Media*.js
> > plugin/network/js/common/Connection.js
> > plugin/notification/js/common/notification.js
> > plugin/camera/js/common/Camera*.js
> > plugin/echo/js/common/echo.js
> > plugin/file/js/common/Directory*.js
> > plugin/file/js/common/Entry.js
> > plugin/file/js/common/File*.js
> > plugin/file/js/common/Flags.js
> > plugin/file/js/common/LocalFileSystem.js
> > plugin/file/js/common/Metadata.js
> > plugin/file/js/common/ProgressEvent.js
> > plugin/splashscreen/js/common/splashscreen.js
> >
>

Re: Moving plugin JS files around

Posted by Filip Maj <fi...@adobe.com>.

Updated: http://wiki.apache.org/cordova/PluginDesign

Anis, can you do us a solid and review the document based on your latest
experience authoring plug man? Like make sure the doc is not missing
anything and is up to date?

On 2/1/13 12:09 PM, "Andrew Grieve" <ag...@chromium.org> wrote:

>Great! thanks!
>
>
>On Fri, Feb 1, 2013 at 3:06 PM, Brian LeRoux <b...@brian.io> wrote:
>
>> Seems like a wiki thing.
>>
>> On Fri, Feb 1, 2013 at 12:01 PM, Filip Maj <fi...@adobe.com> wrote:
>> > Its just a document..
>> >
>> > Ill move it / create a spot for it in the wiki ?
>> >
>> > On 2/1/13 11:56 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >
>> >>Yup, you only need to update the NOTICE and only if we are
>>distributing.
>> >>
>> >>On Fri, Feb 1, 2013 at 11:47 AM, Filip Maj <fi...@adobe.com> wrote:
>> >>> isn't mit compatible with apache license?
>> >>>
>> >>> On 2/1/13 11:41 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>> >>>
>> >>>>Did anyone act on putting this on the wiki?
>> >>>>
>> >>>>We'd need to ask Andrew to re-license from MIT -> Apache before we
>>did
>> >>>>so
>> >>>>I
>> >>>>think.
>> >>>>
>> >>>>
>> >>>>On Wed, Jan 9, 2013 at 2:10 PM, Shazron <sh...@gmail.com> wrote:
>> >>>>
>> >>>>> +1
>> >>>>>
>> >>>>>
>> >>>>> On Wed, Jan 9, 2013 at 10:57 AM, Filip Maj <fi...@adobe.com> wrote:
>> >>>>>
>> >>>>> > https://github.com/alunny/cordova-plugin-spec
>> >>>>> >
>> >>>>> >
>> >>>>> > We should move this to our wiki asap
>> >>>>> >
>> >>>>> > On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:
>> >>>>> >
>> >>>>> > >Ideally the require paths should stay true to the following
>>rules
>> >>>>>(not
>> >>>>> > >that
>> >>>>> > >we follow them exactly now but we are close):
>> >>>>> > >
>> >>>>> > >1. should always start with cordova (in case we ever share a
>> >>>>>require
>> >>>>> > >framework)
>> >>>>> > >2. should follow as close as possible to the folder structure.
>> >>>>> > >
>> >>>>> > >We don't really do this now (but we are close).  It is mainly
>>to
>> >>>>>help
>> >>>>> with
>> >>>>> > >navigation of the project from a require statement:
>> >>>>> > >
>> >>>>> > >     var foo = require('cordova/plugin/foo/submodule')
>> >>>>> > >
>> >>>>> > >Ideally I should be able to navigate to a file that lives in:
>> >>>>> > >
>> >>>>> > >     ~/cordova.js/plugin/foo/submodule.js
>> >>>>> > >
>> >>>>> > >But realistically we are probably going to see:
>> >>>>> > >
>> >>>>> > >    ~/cordova.js/plugin/foo/js/submodule.js
>> >>>>> > >
>> >>>>> > >Assuming we are dumping everything into a js folder here is the
>> >>>>> "mapping"
>> >>>>> > >off the top of my head:
>> >>>>> > >
>> >>>>> > >    var foo = require('cordova/plugin/foo')
>> >>>>> > >    ~/cordova.js/plugin/foo/js/index.js
>> >>>>> > >
>> >>>>> > >    var foo = require('cordova/plugin/foo/ios')
>> >>>>> > >    ~/cordova.js/plugin/foo/js/ios.js
>> >>>>> > >
>> >>>>> > >    var foo = require('cordova/plugin/foo/blackberry/qnx')
>> >>>>> > >    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>> >>>>> > >
>> >>>>> > >What does a plugin (native and js code) folder structure look
>> like?
>> >>>>> > >
>> >>>>> > >
>> >>>>> > >On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve
>><agrieve@google.com
>> >
>> >>>>> wrote:
>> >>>>> > >
>> >>>>> > >> I'd like to take a first step towards moving plugin JS into
>> >>>>>separate
>> >>>>> > >>repos
>> >>>>> > >> by first moving them around within cordova-js.
>> >>>>> > >>
>> >>>>> > >> Here is my proposal:
>> >>>>> > >>
>> >>>>> > >> Current structure:
>> >>>>> > >>         lib/common/plugin/*.js
>> >>>>> > >>         lib/$PLATFORM/plugin/*.js
>> >>>>> > >>
>> >>>>> > >> New structure:
>> >>>>> > >>         plugin/$PLUGIN_NAME/js/common/*.js
>> >>>>> > >>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
>> >>>>> > >>
>> >>>>> > >> The require path will need to change. Going from:
>> >>>>> > >>         cordova.require('cordova/plugin/FileTransferError')
>> >>>>> > >> To:
>> >>>>> > >>         cordova.require('plugin/file/FileTransferError')
>> >>>>> > >>
>> >>>>> > >>
>> >>>>> > >> I'll obviously need to update the builder scripts
>>accordingly.
>> >>>>>The
>> >>>>> idea
>> >>>>> > >> here is that we:
>> >>>>> > >>         1. "cordova plugin add" will copy files into a
>>project's
>> >>>>> plugins
>> >>>>> > >> directory
>> >>>>> > >>         2. "cordova build ios" will use the cordova-js
>>packager
>> >>>>>and
>> >>>>> > >>pass it
>> >>>>> > >> the plugin/ directory to use
>> >>>>> > >>
>> >>>>> > >> This will not involve changing how we export modules onto
>> >>>>>namespaces
>> >>>>> in
>> >>>>> > >> common.js / platform.js. That will come next though.
>> >>>>> > >>
>> >>>>> > >>
>> >>>>> > >> The resulting structure will look like:
>> >>>>> > >>
>> >>>>> > >> plugin/accelerometer/js/common/Acceleration.js
>> >>>>> > >> plugin/accelerometer/js/common/accelerometer.js
>> >>>>> > >> plugin/battery/js/common/battery.js
>> >>>>> > >> plugin/compass/js/common/Compass*.js
>> >>>>> > >> plugin/contacts/js/common/Contact*.js
>> >>>>> > >> plugin/device/js/common/device.js
>> >>>>> > >> plugin/geolocation/js/common/Coordinates.js
>> >>>>> > >> plugin/geolocation/js/common/Position*.js
>> >>>>> > >> plugin/globalization/js/common/Globalization*.js
>> >>>>> > >> plugin/inappbrowser/js/common/InAppBrowser.js
>> >>>>> > >> plugin/logger/js/common/logger.js
>> >>>>> > >> plugin/logger/js/common/console-via-logger.js
>> >>>>> > >> plugin/media/js/common/Capture*.js
>> >>>>> > >> plugin/media/js/common/ConfigurationData.js
>> >>>>> > >> plugin/media/js/common/Media*.js
>> >>>>> > >> plugin/network/js/common/Connection.js
>> >>>>> > >> plugin/notification/js/common/notification.js
>> >>>>> > >> plugin/camera/js/common/Camera*.js
>> >>>>> > >> plugin/echo/js/common/echo.js
>> >>>>> > >> plugin/file/js/common/Directory*.js
>> >>>>> > >> plugin/file/js/common/Entry.js
>> >>>>> > >> plugin/file/js/common/File*.js
>> >>>>> > >> plugin/file/js/common/Flags.js
>> >>>>> > >> plugin/file/js/common/LocalFileSystem.js
>> >>>>> > >> plugin/file/js/common/Metadata.js
>> >>>>> > >> plugin/file/js/common/ProgressEvent.js
>> >>>>> > >> plugin/splashscreen/js/common/splashscreen.js
>> >>>>> > >>
>> >>>>> >
>> >>>>> >
>> >>>>>
>> >>>
>> >
>>

Re: Moving plugin JS files around

Posted by Andrew Grieve <ag...@chromium.org>.

Great! thanks!


On Fri, Feb 1, 2013 at 3:06 PM, Brian LeRoux <b...@brian.io> wrote:

> Seems like a wiki thing.
>
> On Fri, Feb 1, 2013 at 12:01 PM, Filip Maj <fi...@adobe.com> wrote:
> > Its just a document..
> >
> > Ill move it / create a spot for it in the wiki ?
> >
> > On 2/1/13 11:56 AM, "Brian LeRoux" <b...@brian.io> wrote:
> >
> >>Yup, you only need to update the NOTICE and only if we are distributing.
> >>
> >>On Fri, Feb 1, 2013 at 11:47 AM, Filip Maj <fi...@adobe.com> wrote:
> >>> isn't mit compatible with apache license?
> >>>
> >>> On 2/1/13 11:41 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
> >>>
> >>>>Did anyone act on putting this on the wiki?
> >>>>
> >>>>We'd need to ask Andrew to re-license from MIT -> Apache before we did
> >>>>so
> >>>>I
> >>>>think.
> >>>>
> >>>>
> >>>>On Wed, Jan 9, 2013 at 2:10 PM, Shazron <sh...@gmail.com> wrote:
> >>>>
> >>>>> +1
> >>>>>
> >>>>>
> >>>>> On Wed, Jan 9, 2013 at 10:57 AM, Filip Maj <fi...@adobe.com> wrote:
> >>>>>
> >>>>> > https://github.com/alunny/cordova-plugin-spec
> >>>>> >
> >>>>> >
> >>>>> > We should move this to our wiki asap
> >>>>> >
> >>>>> > On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:
> >>>>> >
> >>>>> > >Ideally the require paths should stay true to the following rules
> >>>>>(not
> >>>>> > >that
> >>>>> > >we follow them exactly now but we are close):
> >>>>> > >
> >>>>> > >1. should always start with cordova (in case we ever share a
> >>>>>require
> >>>>> > >framework)
> >>>>> > >2. should follow as close as possible to the folder structure.
> >>>>> > >
> >>>>> > >We don't really do this now (but we are close).  It is mainly to
> >>>>>help
> >>>>> with
> >>>>> > >navigation of the project from a require statement:
> >>>>> > >
> >>>>> > >     var foo = require('cordova/plugin/foo/submodule')
> >>>>> > >
> >>>>> > >Ideally I should be able to navigate to a file that lives in:
> >>>>> > >
> >>>>> > >     ~/cordova.js/plugin/foo/submodule.js
> >>>>> > >
> >>>>> > >But realistically we are probably going to see:
> >>>>> > >
> >>>>> > >    ~/cordova.js/plugin/foo/js/submodule.js
> >>>>> > >
> >>>>> > >Assuming we are dumping everything into a js folder here is the
> >>>>> "mapping"
> >>>>> > >off the top of my head:
> >>>>> > >
> >>>>> > >    var foo = require('cordova/plugin/foo')
> >>>>> > >    ~/cordova.js/plugin/foo/js/index.js
> >>>>> > >
> >>>>> > >    var foo = require('cordova/plugin/foo/ios')
> >>>>> > >    ~/cordova.js/plugin/foo/js/ios.js
> >>>>> > >
> >>>>> > >    var foo = require('cordova/plugin/foo/blackberry/qnx')
> >>>>> > >    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> >>>>> > >
> >>>>> > >What does a plugin (native and js code) folder structure look
> like?
> >>>>> > >
> >>>>> > >
> >>>>> > >On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <agrieve@google.com
> >
> >>>>> wrote:
> >>>>> > >
> >>>>> > >> I'd like to take a first step towards moving plugin JS into
> >>>>>separate
> >>>>> > >>repos
> >>>>> > >> by first moving them around within cordova-js.
> >>>>> > >>
> >>>>> > >> Here is my proposal:
> >>>>> > >>
> >>>>> > >> Current structure:
> >>>>> > >>         lib/common/plugin/*.js
> >>>>> > >>         lib/$PLATFORM/plugin/*.js
> >>>>> > >>
> >>>>> > >> New structure:
> >>>>> > >>         plugin/$PLUGIN_NAME/js/common/*.js
> >>>>> > >>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> >>>>> > >>
> >>>>> > >> The require path will need to change. Going from:
> >>>>> > >>         cordova.require('cordova/plugin/FileTransferError')
> >>>>> > >> To:
> >>>>> > >>         cordova.require('plugin/file/FileTransferError')
> >>>>> > >>
> >>>>> > >>
> >>>>> > >> I'll obviously need to update the builder scripts accordingly.
> >>>>>The
> >>>>> idea
> >>>>> > >> here is that we:
> >>>>> > >>         1. "cordova plugin add" will copy files into a project's
> >>>>> plugins
> >>>>> > >> directory
> >>>>> > >>         2. "cordova build ios" will use the cordova-js packager
> >>>>>and
> >>>>> > >>pass it
> >>>>> > >> the plugin/ directory to use
> >>>>> > >>
> >>>>> > >> This will not involve changing how we export modules onto
> >>>>>namespaces
> >>>>> in
> >>>>> > >> common.js / platform.js. That will come next though.
> >>>>> > >>
> >>>>> > >>
> >>>>> > >> The resulting structure will look like:
> >>>>> > >>
> >>>>> > >> plugin/accelerometer/js/common/Acceleration.js
> >>>>> > >> plugin/accelerometer/js/common/accelerometer.js
> >>>>> > >> plugin/battery/js/common/battery.js
> >>>>> > >> plugin/compass/js/common/Compass*.js
> >>>>> > >> plugin/contacts/js/common/Contact*.js
> >>>>> > >> plugin/device/js/common/device.js
> >>>>> > >> plugin/geolocation/js/common/Coordinates.js
> >>>>> > >> plugin/geolocation/js/common/Position*.js
> >>>>> > >> plugin/globalization/js/common/Globalization*.js
> >>>>> > >> plugin/inappbrowser/js/common/InAppBrowser.js
> >>>>> > >> plugin/logger/js/common/logger.js
> >>>>> > >> plugin/logger/js/common/console-via-logger.js
> >>>>> > >> plugin/media/js/common/Capture*.js
> >>>>> > >> plugin/media/js/common/ConfigurationData.js
> >>>>> > >> plugin/media/js/common/Media*.js
> >>>>> > >> plugin/network/js/common/Connection.js
> >>>>> > >> plugin/notification/js/common/notification.js
> >>>>> > >> plugin/camera/js/common/Camera*.js
> >>>>> > >> plugin/echo/js/common/echo.js
> >>>>> > >> plugin/file/js/common/Directory*.js
> >>>>> > >> plugin/file/js/common/Entry.js
> >>>>> > >> plugin/file/js/common/File*.js
> >>>>> > >> plugin/file/js/common/Flags.js
> >>>>> > >> plugin/file/js/common/LocalFileSystem.js
> >>>>> > >> plugin/file/js/common/Metadata.js
> >>>>> > >> plugin/file/js/common/ProgressEvent.js
> >>>>> > >> plugin/splashscreen/js/common/splashscreen.js
> >>>>> > >>
> >>>>> >
> >>>>> >
> >>>>>
> >>>
> >
>

Re: Moving plugin JS files around

Posted by Brian LeRoux <b...@brian.io>.

Seems like a wiki thing.

On Fri, Feb 1, 2013 at 12:01 PM, Filip Maj <fi...@adobe.com> wrote:
> Its just a document..
>
> Ill move it / create a spot for it in the wiki ?
>
> On 2/1/13 11:56 AM, "Brian LeRoux" <b...@brian.io> wrote:
>
>>Yup, you only need to update the NOTICE and only if we are distributing.
>>
>>On Fri, Feb 1, 2013 at 11:47 AM, Filip Maj <fi...@adobe.com> wrote:
>>> isn't mit compatible with apache license?
>>>
>>> On 2/1/13 11:41 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>>>
>>>>Did anyone act on putting this on the wiki?
>>>>
>>>>We'd need to ask Andrew to re-license from MIT -> Apache before we did
>>>>so
>>>>I
>>>>think.
>>>>
>>>>
>>>>On Wed, Jan 9, 2013 at 2:10 PM, Shazron <sh...@gmail.com> wrote:
>>>>
>>>>> +1
>>>>>
>>>>>
>>>>> On Wed, Jan 9, 2013 at 10:57 AM, Filip Maj <fi...@adobe.com> wrote:
>>>>>
>>>>> > https://github.com/alunny/cordova-plugin-spec
>>>>> >
>>>>> >
>>>>> > We should move this to our wiki asap
>>>>> >
>>>>> > On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:
>>>>> >
>>>>> > >Ideally the require paths should stay true to the following rules
>>>>>(not
>>>>> > >that
>>>>> > >we follow them exactly now but we are close):
>>>>> > >
>>>>> > >1. should always start with cordova (in case we ever share a
>>>>>require
>>>>> > >framework)
>>>>> > >2. should follow as close as possible to the folder structure.
>>>>> > >
>>>>> > >We don't really do this now (but we are close).  It is mainly to
>>>>>help
>>>>> with
>>>>> > >navigation of the project from a require statement:
>>>>> > >
>>>>> > >     var foo = require('cordova/plugin/foo/submodule')
>>>>> > >
>>>>> > >Ideally I should be able to navigate to a file that lives in:
>>>>> > >
>>>>> > >     ~/cordova.js/plugin/foo/submodule.js
>>>>> > >
>>>>> > >But realistically we are probably going to see:
>>>>> > >
>>>>> > >    ~/cordova.js/plugin/foo/js/submodule.js
>>>>> > >
>>>>> > >Assuming we are dumping everything into a js folder here is the
>>>>> "mapping"
>>>>> > >off the top of my head:
>>>>> > >
>>>>> > >    var foo = require('cordova/plugin/foo')
>>>>> > >    ~/cordova.js/plugin/foo/js/index.js
>>>>> > >
>>>>> > >    var foo = require('cordova/plugin/foo/ios')
>>>>> > >    ~/cordova.js/plugin/foo/js/ios.js
>>>>> > >
>>>>> > >    var foo = require('cordova/plugin/foo/blackberry/qnx')
>>>>> > >    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>>>>> > >
>>>>> > >What does a plugin (native and js code) folder structure look like?
>>>>> > >
>>>>> > >
>>>>> > >On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
>>>>> wrote:
>>>>> > >
>>>>> > >> I'd like to take a first step towards moving plugin JS into
>>>>>separate
>>>>> > >>repos
>>>>> > >> by first moving them around within cordova-js.
>>>>> > >>
>>>>> > >> Here is my proposal:
>>>>> > >>
>>>>> > >> Current structure:
>>>>> > >>         lib/common/plugin/*.js
>>>>> > >>         lib/$PLATFORM/plugin/*.js
>>>>> > >>
>>>>> > >> New structure:
>>>>> > >>         plugin/$PLUGIN_NAME/js/common/*.js
>>>>> > >>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
>>>>> > >>
>>>>> > >> The require path will need to change. Going from:
>>>>> > >>         cordova.require('cordova/plugin/FileTransferError')
>>>>> > >> To:
>>>>> > >>         cordova.require('plugin/file/FileTransferError')
>>>>> > >>
>>>>> > >>
>>>>> > >> I'll obviously need to update the builder scripts accordingly.
>>>>>The
>>>>> idea
>>>>> > >> here is that we:
>>>>> > >>         1. "cordova plugin add" will copy files into a project's
>>>>> plugins
>>>>> > >> directory
>>>>> > >>         2. "cordova build ios" will use the cordova-js packager
>>>>>and
>>>>> > >>pass it
>>>>> > >> the plugin/ directory to use
>>>>> > >>
>>>>> > >> This will not involve changing how we export modules onto
>>>>>namespaces
>>>>> in
>>>>> > >> common.js / platform.js. That will come next though.
>>>>> > >>
>>>>> > >>
>>>>> > >> The resulting structure will look like:
>>>>> > >>
>>>>> > >> plugin/accelerometer/js/common/Acceleration.js
>>>>> > >> plugin/accelerometer/js/common/accelerometer.js
>>>>> > >> plugin/battery/js/common/battery.js
>>>>> > >> plugin/compass/js/common/Compass*.js
>>>>> > >> plugin/contacts/js/common/Contact*.js
>>>>> > >> plugin/device/js/common/device.js
>>>>> > >> plugin/geolocation/js/common/Coordinates.js
>>>>> > >> plugin/geolocation/js/common/Position*.js
>>>>> > >> plugin/globalization/js/common/Globalization*.js
>>>>> > >> plugin/inappbrowser/js/common/InAppBrowser.js
>>>>> > >> plugin/logger/js/common/logger.js
>>>>> > >> plugin/logger/js/common/console-via-logger.js
>>>>> > >> plugin/media/js/common/Capture*.js
>>>>> > >> plugin/media/js/common/ConfigurationData.js
>>>>> > >> plugin/media/js/common/Media*.js
>>>>> > >> plugin/network/js/common/Connection.js
>>>>> > >> plugin/notification/js/common/notification.js
>>>>> > >> plugin/camera/js/common/Camera*.js
>>>>> > >> plugin/echo/js/common/echo.js
>>>>> > >> plugin/file/js/common/Directory*.js
>>>>> > >> plugin/file/js/common/Entry.js
>>>>> > >> plugin/file/js/common/File*.js
>>>>> > >> plugin/file/js/common/Flags.js
>>>>> > >> plugin/file/js/common/LocalFileSystem.js
>>>>> > >> plugin/file/js/common/Metadata.js
>>>>> > >> plugin/file/js/common/ProgressEvent.js
>>>>> > >> plugin/splashscreen/js/common/splashscreen.js
>>>>> > >>
>>>>> >
>>>>> >
>>>>>
>>>
>

Re: Moving plugin JS files around

Posted by Filip Maj <fi...@adobe.com>.

Its just a document..

Ill move it / create a spot for it in the wiki ?

On 2/1/13 11:56 AM, "Brian LeRoux" <b...@brian.io> wrote:

>Yup, you only need to update the NOTICE and only if we are distributing.
>
>On Fri, Feb 1, 2013 at 11:47 AM, Filip Maj <fi...@adobe.com> wrote:
>> isn't mit compatible with apache license?
>>
>> On 2/1/13 11:41 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>>
>>>Did anyone act on putting this on the wiki?
>>>
>>>We'd need to ask Andrew to re-license from MIT -> Apache before we did
>>>so
>>>I
>>>think.
>>>
>>>
>>>On Wed, Jan 9, 2013 at 2:10 PM, Shazron <sh...@gmail.com> wrote:
>>>
>>>> +1
>>>>
>>>>
>>>> On Wed, Jan 9, 2013 at 10:57 AM, Filip Maj <fi...@adobe.com> wrote:
>>>>
>>>> > https://github.com/alunny/cordova-plugin-spec
>>>> >
>>>> >
>>>> > We should move this to our wiki asap
>>>> >
>>>> > On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:
>>>> >
>>>> > >Ideally the require paths should stay true to the following rules
>>>>(not
>>>> > >that
>>>> > >we follow them exactly now but we are close):
>>>> > >
>>>> > >1. should always start with cordova (in case we ever share a
>>>>require
>>>> > >framework)
>>>> > >2. should follow as close as possible to the folder structure.
>>>> > >
>>>> > >We don't really do this now (but we are close).  It is mainly to
>>>>help
>>>> with
>>>> > >navigation of the project from a require statement:
>>>> > >
>>>> > >     var foo = require('cordova/plugin/foo/submodule')
>>>> > >
>>>> > >Ideally I should be able to navigate to a file that lives in:
>>>> > >
>>>> > >     ~/cordova.js/plugin/foo/submodule.js
>>>> > >
>>>> > >But realistically we are probably going to see:
>>>> > >
>>>> > >    ~/cordova.js/plugin/foo/js/submodule.js
>>>> > >
>>>> > >Assuming we are dumping everything into a js folder here is the
>>>> "mapping"
>>>> > >off the top of my head:
>>>> > >
>>>> > >    var foo = require('cordova/plugin/foo')
>>>> > >    ~/cordova.js/plugin/foo/js/index.js
>>>> > >
>>>> > >    var foo = require('cordova/plugin/foo/ios')
>>>> > >    ~/cordova.js/plugin/foo/js/ios.js
>>>> > >
>>>> > >    var foo = require('cordova/plugin/foo/blackberry/qnx')
>>>> > >    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>>>> > >
>>>> > >What does a plugin (native and js code) folder structure look like?
>>>> > >
>>>> > >
>>>> > >On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
>>>> wrote:
>>>> > >
>>>> > >> I'd like to take a first step towards moving plugin JS into
>>>>separate
>>>> > >>repos
>>>> > >> by first moving them around within cordova-js.
>>>> > >>
>>>> > >> Here is my proposal:
>>>> > >>
>>>> > >> Current structure:
>>>> > >>         lib/common/plugin/*.js
>>>> > >>         lib/$PLATFORM/plugin/*.js
>>>> > >>
>>>> > >> New structure:
>>>> > >>         plugin/$PLUGIN_NAME/js/common/*.js
>>>> > >>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
>>>> > >>
>>>> > >> The require path will need to change. Going from:
>>>> > >>         cordova.require('cordova/plugin/FileTransferError')
>>>> > >> To:
>>>> > >>         cordova.require('plugin/file/FileTransferError')
>>>> > >>
>>>> > >>
>>>> > >> I'll obviously need to update the builder scripts accordingly.
>>>>The
>>>> idea
>>>> > >> here is that we:
>>>> > >>         1. "cordova plugin add" will copy files into a project's
>>>> plugins
>>>> > >> directory
>>>> > >>         2. "cordova build ios" will use the cordova-js packager
>>>>and
>>>> > >>pass it
>>>> > >> the plugin/ directory to use
>>>> > >>
>>>> > >> This will not involve changing how we export modules onto
>>>>namespaces
>>>> in
>>>> > >> common.js / platform.js. That will come next though.
>>>> > >>
>>>> > >>
>>>> > >> The resulting structure will look like:
>>>> > >>
>>>> > >> plugin/accelerometer/js/common/Acceleration.js
>>>> > >> plugin/accelerometer/js/common/accelerometer.js
>>>> > >> plugin/battery/js/common/battery.js
>>>> > >> plugin/compass/js/common/Compass*.js
>>>> > >> plugin/contacts/js/common/Contact*.js
>>>> > >> plugin/device/js/common/device.js
>>>> > >> plugin/geolocation/js/common/Coordinates.js
>>>> > >> plugin/geolocation/js/common/Position*.js
>>>> > >> plugin/globalization/js/common/Globalization*.js
>>>> > >> plugin/inappbrowser/js/common/InAppBrowser.js
>>>> > >> plugin/logger/js/common/logger.js
>>>> > >> plugin/logger/js/common/console-via-logger.js
>>>> > >> plugin/media/js/common/Capture*.js
>>>> > >> plugin/media/js/common/ConfigurationData.js
>>>> > >> plugin/media/js/common/Media*.js
>>>> > >> plugin/network/js/common/Connection.js
>>>> > >> plugin/notification/js/common/notification.js
>>>> > >> plugin/camera/js/common/Camera*.js
>>>> > >> plugin/echo/js/common/echo.js
>>>> > >> plugin/file/js/common/Directory*.js
>>>> > >> plugin/file/js/common/Entry.js
>>>> > >> plugin/file/js/common/File*.js
>>>> > >> plugin/file/js/common/Flags.js
>>>> > >> plugin/file/js/common/LocalFileSystem.js
>>>> > >> plugin/file/js/common/Metadata.js
>>>> > >> plugin/file/js/common/ProgressEvent.js
>>>> > >> plugin/splashscreen/js/common/splashscreen.js
>>>> > >>
>>>> >
>>>> >
>>>>
>>

Re: Moving plugin JS files around

Posted by Brian LeRoux <b...@brian.io>.

Yup, you only need to update the NOTICE and only if we are distributing.

On Fri, Feb 1, 2013 at 11:47 AM, Filip Maj <fi...@adobe.com> wrote:
> isn't mit compatible with apache license?
>
> On 2/1/13 11:41 AM, "Andrew Grieve" <ag...@chromium.org> wrote:
>
>>Did anyone act on putting this on the wiki?
>>
>>We'd need to ask Andrew to re-license from MIT -> Apache before we did so
>>I
>>think.
>>
>>
>>On Wed, Jan 9, 2013 at 2:10 PM, Shazron <sh...@gmail.com> wrote:
>>
>>> +1
>>>
>>>
>>> On Wed, Jan 9, 2013 at 10:57 AM, Filip Maj <fi...@adobe.com> wrote:
>>>
>>> > https://github.com/alunny/cordova-plugin-spec
>>> >
>>> >
>>> > We should move this to our wiki asap
>>> >
>>> > On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:
>>> >
>>> > >Ideally the require paths should stay true to the following rules
>>>(not
>>> > >that
>>> > >we follow them exactly now but we are close):
>>> > >
>>> > >1. should always start with cordova (in case we ever share a require
>>> > >framework)
>>> > >2. should follow as close as possible to the folder structure.
>>> > >
>>> > >We don't really do this now (but we are close).  It is mainly to help
>>> with
>>> > >navigation of the project from a require statement:
>>> > >
>>> > >     var foo = require('cordova/plugin/foo/submodule')
>>> > >
>>> > >Ideally I should be able to navigate to a file that lives in:
>>> > >
>>> > >     ~/cordova.js/plugin/foo/submodule.js
>>> > >
>>> > >But realistically we are probably going to see:
>>> > >
>>> > >    ~/cordova.js/plugin/foo/js/submodule.js
>>> > >
>>> > >Assuming we are dumping everything into a js folder here is the
>>> "mapping"
>>> > >off the top of my head:
>>> > >
>>> > >    var foo = require('cordova/plugin/foo')
>>> > >    ~/cordova.js/plugin/foo/js/index.js
>>> > >
>>> > >    var foo = require('cordova/plugin/foo/ios')
>>> > >    ~/cordova.js/plugin/foo/js/ios.js
>>> > >
>>> > >    var foo = require('cordova/plugin/foo/blackberry/qnx')
>>> > >    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>>> > >
>>> > >What does a plugin (native and js code) folder structure look like?
>>> > >
>>> > >
>>> > >On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
>>> wrote:
>>> > >
>>> > >> I'd like to take a first step towards moving plugin JS into
>>>separate
>>> > >>repos
>>> > >> by first moving them around within cordova-js.
>>> > >>
>>> > >> Here is my proposal:
>>> > >>
>>> > >> Current structure:
>>> > >>         lib/common/plugin/*.js
>>> > >>         lib/$PLATFORM/plugin/*.js
>>> > >>
>>> > >> New structure:
>>> > >>         plugin/$PLUGIN_NAME/js/common/*.js
>>> > >>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
>>> > >>
>>> > >> The require path will need to change. Going from:
>>> > >>         cordova.require('cordova/plugin/FileTransferError')
>>> > >> To:
>>> > >>         cordova.require('plugin/file/FileTransferError')
>>> > >>
>>> > >>
>>> > >> I'll obviously need to update the builder scripts accordingly. The
>>> idea
>>> > >> here is that we:
>>> > >>         1. "cordova plugin add" will copy files into a project's
>>> plugins
>>> > >> directory
>>> > >>         2. "cordova build ios" will use the cordova-js packager and
>>> > >>pass it
>>> > >> the plugin/ directory to use
>>> > >>
>>> > >> This will not involve changing how we export modules onto
>>>namespaces
>>> in
>>> > >> common.js / platform.js. That will come next though.
>>> > >>
>>> > >>
>>> > >> The resulting structure will look like:
>>> > >>
>>> > >> plugin/accelerometer/js/common/Acceleration.js
>>> > >> plugin/accelerometer/js/common/accelerometer.js
>>> > >> plugin/battery/js/common/battery.js
>>> > >> plugin/compass/js/common/Compass*.js
>>> > >> plugin/contacts/js/common/Contact*.js
>>> > >> plugin/device/js/common/device.js
>>> > >> plugin/geolocation/js/common/Coordinates.js
>>> > >> plugin/geolocation/js/common/Position*.js
>>> > >> plugin/globalization/js/common/Globalization*.js
>>> > >> plugin/inappbrowser/js/common/InAppBrowser.js
>>> > >> plugin/logger/js/common/logger.js
>>> > >> plugin/logger/js/common/console-via-logger.js
>>> > >> plugin/media/js/common/Capture*.js
>>> > >> plugin/media/js/common/ConfigurationData.js
>>> > >> plugin/media/js/common/Media*.js
>>> > >> plugin/network/js/common/Connection.js
>>> > >> plugin/notification/js/common/notification.js
>>> > >> plugin/camera/js/common/Camera*.js
>>> > >> plugin/echo/js/common/echo.js
>>> > >> plugin/file/js/common/Directory*.js
>>> > >> plugin/file/js/common/Entry.js
>>> > >> plugin/file/js/common/File*.js
>>> > >> plugin/file/js/common/Flags.js
>>> > >> plugin/file/js/common/LocalFileSystem.js
>>> > >> plugin/file/js/common/Metadata.js
>>> > >> plugin/file/js/common/ProgressEvent.js
>>> > >> plugin/splashscreen/js/common/splashscreen.js
>>> > >>
>>> >
>>> >
>>>
>

Re: Moving plugin JS files around

Posted by Filip Maj <fi...@adobe.com>.

isn't mit compatible with apache license?

On 2/1/13 11:41 AM, "Andrew Grieve" <ag...@chromium.org> wrote:

>Did anyone act on putting this on the wiki?
>
>We'd need to ask Andrew to re-license from MIT -> Apache before we did so
>I
>think.
>
>
>On Wed, Jan 9, 2013 at 2:10 PM, Shazron <sh...@gmail.com> wrote:
>
>> +1
>>
>>
>> On Wed, Jan 9, 2013 at 10:57 AM, Filip Maj <fi...@adobe.com> wrote:
>>
>> > https://github.com/alunny/cordova-plugin-spec
>> >
>> >
>> > We should move this to our wiki asap
>> >
>> > On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:
>> >
>> > >Ideally the require paths should stay true to the following rules
>>(not
>> > >that
>> > >we follow them exactly now but we are close):
>> > >
>> > >1. should always start with cordova (in case we ever share a require
>> > >framework)
>> > >2. should follow as close as possible to the folder structure.
>> > >
>> > >We don't really do this now (but we are close).  It is mainly to help
>> with
>> > >navigation of the project from a require statement:
>> > >
>> > >     var foo = require('cordova/plugin/foo/submodule')
>> > >
>> > >Ideally I should be able to navigate to a file that lives in:
>> > >
>> > >     ~/cordova.js/plugin/foo/submodule.js
>> > >
>> > >But realistically we are probably going to see:
>> > >
>> > >    ~/cordova.js/plugin/foo/js/submodule.js
>> > >
>> > >Assuming we are dumping everything into a js folder here is the
>> "mapping"
>> > >off the top of my head:
>> > >
>> > >    var foo = require('cordova/plugin/foo')
>> > >    ~/cordova.js/plugin/foo/js/index.js
>> > >
>> > >    var foo = require('cordova/plugin/foo/ios')
>> > >    ~/cordova.js/plugin/foo/js/ios.js
>> > >
>> > >    var foo = require('cordova/plugin/foo/blackberry/qnx')
>> > >    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>> > >
>> > >What does a plugin (native and js code) folder structure look like?
>> > >
>> > >
>> > >On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
>> wrote:
>> > >
>> > >> I'd like to take a first step towards moving plugin JS into
>>separate
>> > >>repos
>> > >> by first moving them around within cordova-js.
>> > >>
>> > >> Here is my proposal:
>> > >>
>> > >> Current structure:
>> > >>         lib/common/plugin/*.js
>> > >>         lib/$PLATFORM/plugin/*.js
>> > >>
>> > >> New structure:
>> > >>         plugin/$PLUGIN_NAME/js/common/*.js
>> > >>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
>> > >>
>> > >> The require path will need to change. Going from:
>> > >>         cordova.require('cordova/plugin/FileTransferError')
>> > >> To:
>> > >>         cordova.require('plugin/file/FileTransferError')
>> > >>
>> > >>
>> > >> I'll obviously need to update the builder scripts accordingly. The
>> idea
>> > >> here is that we:
>> > >>         1. "cordova plugin add" will copy files into a project's
>> plugins
>> > >> directory
>> > >>         2. "cordova build ios" will use the cordova-js packager and
>> > >>pass it
>> > >> the plugin/ directory to use
>> > >>
>> > >> This will not involve changing how we export modules onto
>>namespaces
>> in
>> > >> common.js / platform.js. That will come next though.
>> > >>
>> > >>
>> > >> The resulting structure will look like:
>> > >>
>> > >> plugin/accelerometer/js/common/Acceleration.js
>> > >> plugin/accelerometer/js/common/accelerometer.js
>> > >> plugin/battery/js/common/battery.js
>> > >> plugin/compass/js/common/Compass*.js
>> > >> plugin/contacts/js/common/Contact*.js
>> > >> plugin/device/js/common/device.js
>> > >> plugin/geolocation/js/common/Coordinates.js
>> > >> plugin/geolocation/js/common/Position*.js
>> > >> plugin/globalization/js/common/Globalization*.js
>> > >> plugin/inappbrowser/js/common/InAppBrowser.js
>> > >> plugin/logger/js/common/logger.js
>> > >> plugin/logger/js/common/console-via-logger.js
>> > >> plugin/media/js/common/Capture*.js
>> > >> plugin/media/js/common/ConfigurationData.js
>> > >> plugin/media/js/common/Media*.js
>> > >> plugin/network/js/common/Connection.js
>> > >> plugin/notification/js/common/notification.js
>> > >> plugin/camera/js/common/Camera*.js
>> > >> plugin/echo/js/common/echo.js
>> > >> plugin/file/js/common/Directory*.js
>> > >> plugin/file/js/common/Entry.js
>> > >> plugin/file/js/common/File*.js
>> > >> plugin/file/js/common/Flags.js
>> > >> plugin/file/js/common/LocalFileSystem.js
>> > >> plugin/file/js/common/Metadata.js
>> > >> plugin/file/js/common/ProgressEvent.js
>> > >> plugin/splashscreen/js/common/splashscreen.js
>> > >>
>> >
>> >
>>

Re: Moving plugin JS files around

Posted by Andrew Grieve <ag...@chromium.org>.

Did anyone act on putting this on the wiki?

We'd need to ask Andrew to re-license from MIT -> Apache before we did so I
think.


On Wed, Jan 9, 2013 at 2:10 PM, Shazron <sh...@gmail.com> wrote:

> +1
>
>
> On Wed, Jan 9, 2013 at 10:57 AM, Filip Maj <fi...@adobe.com> wrote:
>
> > https://github.com/alunny/cordova-plugin-spec
> >
> >
> > We should move this to our wiki asap
> >
> > On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:
> >
> > >Ideally the require paths should stay true to the following rules (not
> > >that
> > >we follow them exactly now but we are close):
> > >
> > >1. should always start with cordova (in case we ever share a require
> > >framework)
> > >2. should follow as close as possible to the folder structure.
> > >
> > >We don't really do this now (but we are close).  It is mainly to help
> with
> > >navigation of the project from a require statement:
> > >
> > >     var foo = require('cordova/plugin/foo/submodule')
> > >
> > >Ideally I should be able to navigate to a file that lives in:
> > >
> > >     ~/cordova.js/plugin/foo/submodule.js
> > >
> > >But realistically we are probably going to see:
> > >
> > >    ~/cordova.js/plugin/foo/js/submodule.js
> > >
> > >Assuming we are dumping everything into a js folder here is the
> "mapping"
> > >off the top of my head:
> > >
> > >    var foo = require('cordova/plugin/foo')
> > >    ~/cordova.js/plugin/foo/js/index.js
> > >
> > >    var foo = require('cordova/plugin/foo/ios')
> > >    ~/cordova.js/plugin/foo/js/ios.js
> > >
> > >    var foo = require('cordova/plugin/foo/blackberry/qnx')
> > >    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> > >
> > >What does a plugin (native and js code) folder structure look like?
> > >
> > >
> > >On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
> wrote:
> > >
> > >> I'd like to take a first step towards moving plugin JS into separate
> > >>repos
> > >> by first moving them around within cordova-js.
> > >>
> > >> Here is my proposal:
> > >>
> > >> Current structure:
> > >>         lib/common/plugin/*.js
> > >>         lib/$PLATFORM/plugin/*.js
> > >>
> > >> New structure:
> > >>         plugin/$PLUGIN_NAME/js/common/*.js
> > >>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> > >>
> > >> The require path will need to change. Going from:
> > >>         cordova.require('cordova/plugin/FileTransferError')
> > >> To:
> > >>         cordova.require('plugin/file/FileTransferError')
> > >>
> > >>
> > >> I'll obviously need to update the builder scripts accordingly. The
> idea
> > >> here is that we:
> > >>         1. "cordova plugin add" will copy files into a project's
> plugins
> > >> directory
> > >>         2. "cordova build ios" will use the cordova-js packager and
> > >>pass it
> > >> the plugin/ directory to use
> > >>
> > >> This will not involve changing how we export modules onto namespaces
> in
> > >> common.js / platform.js. That will come next though.
> > >>
> > >>
> > >> The resulting structure will look like:
> > >>
> > >> plugin/accelerometer/js/common/Acceleration.js
> > >> plugin/accelerometer/js/common/accelerometer.js
> > >> plugin/battery/js/common/battery.js
> > >> plugin/compass/js/common/Compass*.js
> > >> plugin/contacts/js/common/Contact*.js
> > >> plugin/device/js/common/device.js
> > >> plugin/geolocation/js/common/Coordinates.js
> > >> plugin/geolocation/js/common/Position*.js
> > >> plugin/globalization/js/common/Globalization*.js
> > >> plugin/inappbrowser/js/common/InAppBrowser.js
> > >> plugin/logger/js/common/logger.js
> > >> plugin/logger/js/common/console-via-logger.js
> > >> plugin/media/js/common/Capture*.js
> > >> plugin/media/js/common/ConfigurationData.js
> > >> plugin/media/js/common/Media*.js
> > >> plugin/network/js/common/Connection.js
> > >> plugin/notification/js/common/notification.js
> > >> plugin/camera/js/common/Camera*.js
> > >> plugin/echo/js/common/echo.js
> > >> plugin/file/js/common/Directory*.js
> > >> plugin/file/js/common/Entry.js
> > >> plugin/file/js/common/File*.js
> > >> plugin/file/js/common/Flags.js
> > >> plugin/file/js/common/LocalFileSystem.js
> > >> plugin/file/js/common/Metadata.js
> > >> plugin/file/js/common/ProgressEvent.js
> > >> plugin/splashscreen/js/common/splashscreen.js
> > >>
> >
> >
>

Re: Moving plugin JS files around

Posted by Andrew Grieve <ag...@chromium.org>.

Coolio. Won't be moving any files until everyone agrees.

The requirements (in my eyes) are:
- Should be easy for plugins to write x-platform JS
  - Cordova packager eases this with it's directory structure
- Should be easy to install / remove plugins
  - I don't think people should need to add/remove script tags in the HTML
when plugins are added/removed


On Wed, Jan 9, 2013 at 4:20 PM, Jesse <pu...@gmail.com> wrote:

> Well, I kinda have to demonstrate it, I am in proof of concept mode now.
>
> I will at least elaborate on my disagreement ...
>
> >> The building tool already is a requirement of every platform, no?
> The build tool is currently only a requirement at 'package/release' time,
> so it is a requirement of ours, but not our users.  My guess is that >75%
> of people using Apache Cordova do not have cordova-js setup, they simply
> use the pre-built versioned js file that comes with each major release.
>
> Specifically, from Andrew's proposal, I am concerned with item 2:
> >> 2. "cordova build ios" will use the cordova-js packager and pass it
> >> the plugin/ directory to use
>
> I don't think there is benefit in the added complexity of having all
> plugins munged by the js packager before the output project is built, every
> time the output project is built.
>
> My original email was partially intended to buy time so I can (better)
> formalize my ideas, and hopefully demonstrate exactly what I mean. Also, I
> wanted to state that we need to talk more about it before we go hard.
>
> The term 'kinda passive aggressive' IS passive aggressive.
>
>
> On Wed, Jan 9, 2013 at 12:45 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > The building tool already is a requirement of every platform, no?
> >
> > Could you describe your solution Jesse? Saying you don't agree w/
> > something but failing to back it up is kinda passive aggressive.
> >
> > On Wed, Jan 9, 2013 at 11:23 AM, Jesse <pu...@gmail.com> wrote:
> > > Andrew,
> > > The approach you mention makes the cordova-js builder tool a
> requirement
> > of
> > > every platform.
> > > I don't think this is the correct approach.
> > >
> > > I will be sharing my implementation soon, in my own branch.
> > >
> > >
> > >
> > > On Wed, Jan 9, 2013 at 11:10 AM, Shazron <sh...@gmail.com> wrote:
> > >
> > >> +1
> > >>
> > >>
> > >> On Wed, Jan 9, 2013 at 10:57 AM, Filip Maj <fi...@adobe.com> wrote:
> > >>
> > >> > https://github.com/alunny/cordova-plugin-spec
> > >> >
> > >> >
> > >> > We should move this to our wiki asap
> > >> >
> > >> > On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:
> > >> >
> > >> > >Ideally the require paths should stay true to the following rules
> > (not
> > >> > >that
> > >> > >we follow them exactly now but we are close):
> > >> > >
> > >> > >1. should always start with cordova (in case we ever share a
> require
> > >> > >framework)
> > >> > >2. should follow as close as possible to the folder structure.
> > >> > >
> > >> > >We don't really do this now (but we are close).  It is mainly to
> help
> > >> with
> > >> > >navigation of the project from a require statement:
> > >> > >
> > >> > >     var foo = require('cordova/plugin/foo/submodule')
> > >> > >
> > >> > >Ideally I should be able to navigate to a file that lives in:
> > >> > >
> > >> > >     ~/cordova.js/plugin/foo/submodule.js
> > >> > >
> > >> > >But realistically we are probably going to see:
> > >> > >
> > >> > >    ~/cordova.js/plugin/foo/js/submodule.js
> > >> > >
> > >> > >Assuming we are dumping everything into a js folder here is the
> > >> "mapping"
> > >> > >off the top of my head:
> > >> > >
> > >> > >    var foo = require('cordova/plugin/foo')
> > >> > >    ~/cordova.js/plugin/foo/js/index.js
> > >> > >
> > >> > >    var foo = require('cordova/plugin/foo/ios')
> > >> > >    ~/cordova.js/plugin/foo/js/ios.js
> > >> > >
> > >> > >    var foo = require('cordova/plugin/foo/blackberry/qnx')
> > >> > >    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> > >> > >
> > >> > >What does a plugin (native and js code) folder structure look like?
> > >> > >
> > >> > >
> > >> > >On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
> > >> wrote:
> > >> > >
> > >> > >> I'd like to take a first step towards moving plugin JS into
> > separate
> > >> > >>repos
> > >> > >> by first moving them around within cordova-js.
> > >> > >>
> > >> > >> Here is my proposal:
> > >> > >>
> > >> > >> Current structure:
> > >> > >>         lib/common/plugin/*.js
> > >> > >>         lib/$PLATFORM/plugin/*.js
> > >> > >>
> > >> > >> New structure:
> > >> > >>         plugin/$PLUGIN_NAME/js/common/*.js
> > >> > >>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> > >> > >>
> > >> > >> The require path will need to change. Going from:
> > >> > >>         cordova.require('cordova/plugin/FileTransferError')
> > >> > >> To:
> > >> > >>         cordova.require('plugin/file/FileTransferError')
> > >> > >>
> > >> > >>
> > >> > >> I'll obviously need to update the builder scripts accordingly.
> The
> > >> idea
> > >> > >> here is that we:
> > >> > >>         1. "cordova plugin add" will copy files into a project's
> > >> plugins
> > >> > >> directory
> > >> > >>         2. "cordova build ios" will use the cordova-js packager
> and
> > >> > >>pass it
> > >> > >> the plugin/ directory to use
> > >> > >>
> > >> > >> This will not involve changing how we export modules onto
> > namespaces
> > >> in
> > >> > >> common.js / platform.js. That will come next though.
> > >> > >>
> > >> > >>
> > >> > >> The resulting structure will look like:
> > >> > >>
> > >> > >> plugin/accelerometer/js/common/Acceleration.js
> > >> > >> plugin/accelerometer/js/common/accelerometer.js
> > >> > >> plugin/battery/js/common/battery.js
> > >> > >> plugin/compass/js/common/Compass*.js
> > >> > >> plugin/contacts/js/common/Contact*.js
> > >> > >> plugin/device/js/common/device.js
> > >> > >> plugin/geolocation/js/common/Coordinates.js
> > >> > >> plugin/geolocation/js/common/Position*.js
> > >> > >> plugin/globalization/js/common/Globalization*.js
> > >> > >> plugin/inappbrowser/js/common/InAppBrowser.js
> > >> > >> plugin/logger/js/common/logger.js
> > >> > >> plugin/logger/js/common/console-via-logger.js
> > >> > >> plugin/media/js/common/Capture*.js
> > >> > >> plugin/media/js/common/ConfigurationData.js
> > >> > >> plugin/media/js/common/Media*.js
> > >> > >> plugin/network/js/common/Connection.js
> > >> > >> plugin/notification/js/common/notification.js
> > >> > >> plugin/camera/js/common/Camera*.js
> > >> > >> plugin/echo/js/common/echo.js
> > >> > >> plugin/file/js/common/Directory*.js
> > >> > >> plugin/file/js/common/Entry.js
> > >> > >> plugin/file/js/common/File*.js
> > >> > >> plugin/file/js/common/Flags.js
> > >> > >> plugin/file/js/common/LocalFileSystem.js
> > >> > >> plugin/file/js/common/Metadata.js
> > >> > >> plugin/file/js/common/ProgressEvent.js
> > >> > >> plugin/splashscreen/js/common/splashscreen.js
> > >> > >>
> > >> >
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > @purplecabbage
> > > risingj.com
> >
>
>
>
> --
> @purplecabbage
> risingj.com
>

Re: Moving plugin JS files around

Posted by Jesse <pu...@gmail.com>.

Well, I kinda have to demonstrate it, I am in proof of concept mode now.

I will at least elaborate on my disagreement ...

>> The building tool already is a requirement of every platform, no?
The build tool is currently only a requirement at 'package/release' time,
so it is a requirement of ours, but not our users.  My guess is that >75%
of people using Apache Cordova do not have cordova-js setup, they simply
use the pre-built versioned js file that comes with each major release.

Specifically, from Andrew's proposal, I am concerned with item 2:
>> 2. "cordova build ios" will use the cordova-js packager and pass it
>> the plugin/ directory to use

I don't think there is benefit in the added complexity of having all
plugins munged by the js packager before the output project is built, every
time the output project is built.

My original email was partially intended to buy time so I can (better)
formalize my ideas, and hopefully demonstrate exactly what I mean. Also, I
wanted to state that we need to talk more about it before we go hard.

The term 'kinda passive aggressive' IS passive aggressive.


On Wed, Jan 9, 2013 at 12:45 PM, Brian LeRoux <b...@brian.io> wrote:

> The building tool already is a requirement of every platform, no?
>
> Could you describe your solution Jesse? Saying you don't agree w/
> something but failing to back it up is kinda passive aggressive.
>
> On Wed, Jan 9, 2013 at 11:23 AM, Jesse <pu...@gmail.com> wrote:
> > Andrew,
> > The approach you mention makes the cordova-js builder tool a requirement
> of
> > every platform.
> > I don't think this is the correct approach.
> >
> > I will be sharing my implementation soon, in my own branch.
> >
> >
> >
> > On Wed, Jan 9, 2013 at 11:10 AM, Shazron <sh...@gmail.com> wrote:
> >
> >> +1
> >>
> >>
> >> On Wed, Jan 9, 2013 at 10:57 AM, Filip Maj <fi...@adobe.com> wrote:
> >>
> >> > https://github.com/alunny/cordova-plugin-spec
> >> >
> >> >
> >> > We should move this to our wiki asap
> >> >
> >> > On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:
> >> >
> >> > >Ideally the require paths should stay true to the following rules
> (not
> >> > >that
> >> > >we follow them exactly now but we are close):
> >> > >
> >> > >1. should always start with cordova (in case we ever share a require
> >> > >framework)
> >> > >2. should follow as close as possible to the folder structure.
> >> > >
> >> > >We don't really do this now (but we are close).  It is mainly to help
> >> with
> >> > >navigation of the project from a require statement:
> >> > >
> >> > >     var foo = require('cordova/plugin/foo/submodule')
> >> > >
> >> > >Ideally I should be able to navigate to a file that lives in:
> >> > >
> >> > >     ~/cordova.js/plugin/foo/submodule.js
> >> > >
> >> > >But realistically we are probably going to see:
> >> > >
> >> > >    ~/cordova.js/plugin/foo/js/submodule.js
> >> > >
> >> > >Assuming we are dumping everything into a js folder here is the
> >> "mapping"
> >> > >off the top of my head:
> >> > >
> >> > >    var foo = require('cordova/plugin/foo')
> >> > >    ~/cordova.js/plugin/foo/js/index.js
> >> > >
> >> > >    var foo = require('cordova/plugin/foo/ios')
> >> > >    ~/cordova.js/plugin/foo/js/ios.js
> >> > >
> >> > >    var foo = require('cordova/plugin/foo/blackberry/qnx')
> >> > >    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> >> > >
> >> > >What does a plugin (native and js code) folder structure look like?
> >> > >
> >> > >
> >> > >On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
> >> wrote:
> >> > >
> >> > >> I'd like to take a first step towards moving plugin JS into
> separate
> >> > >>repos
> >> > >> by first moving them around within cordova-js.
> >> > >>
> >> > >> Here is my proposal:
> >> > >>
> >> > >> Current structure:
> >> > >>         lib/common/plugin/*.js
> >> > >>         lib/$PLATFORM/plugin/*.js
> >> > >>
> >> > >> New structure:
> >> > >>         plugin/$PLUGIN_NAME/js/common/*.js
> >> > >>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> >> > >>
> >> > >> The require path will need to change. Going from:
> >> > >>         cordova.require('cordova/plugin/FileTransferError')
> >> > >> To:
> >> > >>         cordova.require('plugin/file/FileTransferError')
> >> > >>
> >> > >>
> >> > >> I'll obviously need to update the builder scripts accordingly. The
> >> idea
> >> > >> here is that we:
> >> > >>         1. "cordova plugin add" will copy files into a project's
> >> plugins
> >> > >> directory
> >> > >>         2. "cordova build ios" will use the cordova-js packager and
> >> > >>pass it
> >> > >> the plugin/ directory to use
> >> > >>
> >> > >> This will not involve changing how we export modules onto
> namespaces
> >> in
> >> > >> common.js / platform.js. That will come next though.
> >> > >>
> >> > >>
> >> > >> The resulting structure will look like:
> >> > >>
> >> > >> plugin/accelerometer/js/common/Acceleration.js
> >> > >> plugin/accelerometer/js/common/accelerometer.js
> >> > >> plugin/battery/js/common/battery.js
> >> > >> plugin/compass/js/common/Compass*.js
> >> > >> plugin/contacts/js/common/Contact*.js
> >> > >> plugin/device/js/common/device.js
> >> > >> plugin/geolocation/js/common/Coordinates.js
> >> > >> plugin/geolocation/js/common/Position*.js
> >> > >> plugin/globalization/js/common/Globalization*.js
> >> > >> plugin/inappbrowser/js/common/InAppBrowser.js
> >> > >> plugin/logger/js/common/logger.js
> >> > >> plugin/logger/js/common/console-via-logger.js
> >> > >> plugin/media/js/common/Capture*.js
> >> > >> plugin/media/js/common/ConfigurationData.js
> >> > >> plugin/media/js/common/Media*.js
> >> > >> plugin/network/js/common/Connection.js
> >> > >> plugin/notification/js/common/notification.js
> >> > >> plugin/camera/js/common/Camera*.js
> >> > >> plugin/echo/js/common/echo.js
> >> > >> plugin/file/js/common/Directory*.js
> >> > >> plugin/file/js/common/Entry.js
> >> > >> plugin/file/js/common/File*.js
> >> > >> plugin/file/js/common/Flags.js
> >> > >> plugin/file/js/common/LocalFileSystem.js
> >> > >> plugin/file/js/common/Metadata.js
> >> > >> plugin/file/js/common/ProgressEvent.js
> >> > >> plugin/splashscreen/js/common/splashscreen.js
> >> > >>
> >> >
> >> >
> >>
> >
> >
> >
> > --
> > @purplecabbage
> > risingj.com
>



-- 
@purplecabbage
risingj.com

Re: Moving plugin JS files around

Posted by Brian LeRoux <b...@brian.io>.

The building tool already is a requirement of every platform, no?

Could you describe your solution Jesse? Saying you don't agree w/
something but failing to back it up is kinda passive aggressive.

On Wed, Jan 9, 2013 at 11:23 AM, Jesse <pu...@gmail.com> wrote:
> Andrew,
> The approach you mention makes the cordova-js builder tool a requirement of
> every platform.
> I don't think this is the correct approach.
>
> I will be sharing my implementation soon, in my own branch.
>
>
>
> On Wed, Jan 9, 2013 at 11:10 AM, Shazron <sh...@gmail.com> wrote:
>
>> +1
>>
>>
>> On Wed, Jan 9, 2013 at 10:57 AM, Filip Maj <fi...@adobe.com> wrote:
>>
>> > https://github.com/alunny/cordova-plugin-spec
>> >
>> >
>> > We should move this to our wiki asap
>> >
>> > On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:
>> >
>> > >Ideally the require paths should stay true to the following rules (not
>> > >that
>> > >we follow them exactly now but we are close):
>> > >
>> > >1. should always start with cordova (in case we ever share a require
>> > >framework)
>> > >2. should follow as close as possible to the folder structure.
>> > >
>> > >We don't really do this now (but we are close).  It is mainly to help
>> with
>> > >navigation of the project from a require statement:
>> > >
>> > >     var foo = require('cordova/plugin/foo/submodule')
>> > >
>> > >Ideally I should be able to navigate to a file that lives in:
>> > >
>> > >     ~/cordova.js/plugin/foo/submodule.js
>> > >
>> > >But realistically we are probably going to see:
>> > >
>> > >    ~/cordova.js/plugin/foo/js/submodule.js
>> > >
>> > >Assuming we are dumping everything into a js folder here is the
>> "mapping"
>> > >off the top of my head:
>> > >
>> > >    var foo = require('cordova/plugin/foo')
>> > >    ~/cordova.js/plugin/foo/js/index.js
>> > >
>> > >    var foo = require('cordova/plugin/foo/ios')
>> > >    ~/cordova.js/plugin/foo/js/ios.js
>> > >
>> > >    var foo = require('cordova/plugin/foo/blackberry/qnx')
>> > >    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>> > >
>> > >What does a plugin (native and js code) folder structure look like?
>> > >
>> > >
>> > >On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
>> wrote:
>> > >
>> > >> I'd like to take a first step towards moving plugin JS into separate
>> > >>repos
>> > >> by first moving them around within cordova-js.
>> > >>
>> > >> Here is my proposal:
>> > >>
>> > >> Current structure:
>> > >>         lib/common/plugin/*.js
>> > >>         lib/$PLATFORM/plugin/*.js
>> > >>
>> > >> New structure:
>> > >>         plugin/$PLUGIN_NAME/js/common/*.js
>> > >>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
>> > >>
>> > >> The require path will need to change. Going from:
>> > >>         cordova.require('cordova/plugin/FileTransferError')
>> > >> To:
>> > >>         cordova.require('plugin/file/FileTransferError')
>> > >>
>> > >>
>> > >> I'll obviously need to update the builder scripts accordingly. The
>> idea
>> > >> here is that we:
>> > >>         1. "cordova plugin add" will copy files into a project's
>> plugins
>> > >> directory
>> > >>         2. "cordova build ios" will use the cordova-js packager and
>> > >>pass it
>> > >> the plugin/ directory to use
>> > >>
>> > >> This will not involve changing how we export modules onto namespaces
>> in
>> > >> common.js / platform.js. That will come next though.
>> > >>
>> > >>
>> > >> The resulting structure will look like:
>> > >>
>> > >> plugin/accelerometer/js/common/Acceleration.js
>> > >> plugin/accelerometer/js/common/accelerometer.js
>> > >> plugin/battery/js/common/battery.js
>> > >> plugin/compass/js/common/Compass*.js
>> > >> plugin/contacts/js/common/Contact*.js
>> > >> plugin/device/js/common/device.js
>> > >> plugin/geolocation/js/common/Coordinates.js
>> > >> plugin/geolocation/js/common/Position*.js
>> > >> plugin/globalization/js/common/Globalization*.js
>> > >> plugin/inappbrowser/js/common/InAppBrowser.js
>> > >> plugin/logger/js/common/logger.js
>> > >> plugin/logger/js/common/console-via-logger.js
>> > >> plugin/media/js/common/Capture*.js
>> > >> plugin/media/js/common/ConfigurationData.js
>> > >> plugin/media/js/common/Media*.js
>> > >> plugin/network/js/common/Connection.js
>> > >> plugin/notification/js/common/notification.js
>> > >> plugin/camera/js/common/Camera*.js
>> > >> plugin/echo/js/common/echo.js
>> > >> plugin/file/js/common/Directory*.js
>> > >> plugin/file/js/common/Entry.js
>> > >> plugin/file/js/common/File*.js
>> > >> plugin/file/js/common/Flags.js
>> > >> plugin/file/js/common/LocalFileSystem.js
>> > >> plugin/file/js/common/Metadata.js
>> > >> plugin/file/js/common/ProgressEvent.js
>> > >> plugin/splashscreen/js/common/splashscreen.js
>> > >>
>> >
>> >
>>
>
>
>
> --
> @purplecabbage
> risingj.com

Re: Moving plugin JS files around

Posted by Jesse <pu...@gmail.com>.

Andrew,
The approach you mention makes the cordova-js builder tool a requirement of
every platform.
I don't think this is the correct approach.

I will be sharing my implementation soon, in my own branch.



On Wed, Jan 9, 2013 at 11:10 AM, Shazron <sh...@gmail.com> wrote:

> +1
>
>
> On Wed, Jan 9, 2013 at 10:57 AM, Filip Maj <fi...@adobe.com> wrote:
>
> > https://github.com/alunny/cordova-plugin-spec
> >
> >
> > We should move this to our wiki asap
> >
> > On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:
> >
> > >Ideally the require paths should stay true to the following rules (not
> > >that
> > >we follow them exactly now but we are close):
> > >
> > >1. should always start with cordova (in case we ever share a require
> > >framework)
> > >2. should follow as close as possible to the folder structure.
> > >
> > >We don't really do this now (but we are close).  It is mainly to help
> with
> > >navigation of the project from a require statement:
> > >
> > >     var foo = require('cordova/plugin/foo/submodule')
> > >
> > >Ideally I should be able to navigate to a file that lives in:
> > >
> > >     ~/cordova.js/plugin/foo/submodule.js
> > >
> > >But realistically we are probably going to see:
> > >
> > >    ~/cordova.js/plugin/foo/js/submodule.js
> > >
> > >Assuming we are dumping everything into a js folder here is the
> "mapping"
> > >off the top of my head:
> > >
> > >    var foo = require('cordova/plugin/foo')
> > >    ~/cordova.js/plugin/foo/js/index.js
> > >
> > >    var foo = require('cordova/plugin/foo/ios')
> > >    ~/cordova.js/plugin/foo/js/ios.js
> > >
> > >    var foo = require('cordova/plugin/foo/blackberry/qnx')
> > >    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> > >
> > >What does a plugin (native and js code) folder structure look like?
> > >
> > >
> > >On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com>
> wrote:
> > >
> > >> I'd like to take a first step towards moving plugin JS into separate
> > >>repos
> > >> by first moving them around within cordova-js.
> > >>
> > >> Here is my proposal:
> > >>
> > >> Current structure:
> > >>         lib/common/plugin/*.js
> > >>         lib/$PLATFORM/plugin/*.js
> > >>
> > >> New structure:
> > >>         plugin/$PLUGIN_NAME/js/common/*.js
> > >>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> > >>
> > >> The require path will need to change. Going from:
> > >>         cordova.require('cordova/plugin/FileTransferError')
> > >> To:
> > >>         cordova.require('plugin/file/FileTransferError')
> > >>
> > >>
> > >> I'll obviously need to update the builder scripts accordingly. The
> idea
> > >> here is that we:
> > >>         1. "cordova plugin add" will copy files into a project's
> plugins
> > >> directory
> > >>         2. "cordova build ios" will use the cordova-js packager and
> > >>pass it
> > >> the plugin/ directory to use
> > >>
> > >> This will not involve changing how we export modules onto namespaces
> in
> > >> common.js / platform.js. That will come next though.
> > >>
> > >>
> > >> The resulting structure will look like:
> > >>
> > >> plugin/accelerometer/js/common/Acceleration.js
> > >> plugin/accelerometer/js/common/accelerometer.js
> > >> plugin/battery/js/common/battery.js
> > >> plugin/compass/js/common/Compass*.js
> > >> plugin/contacts/js/common/Contact*.js
> > >> plugin/device/js/common/device.js
> > >> plugin/geolocation/js/common/Coordinates.js
> > >> plugin/geolocation/js/common/Position*.js
> > >> plugin/globalization/js/common/Globalization*.js
> > >> plugin/inappbrowser/js/common/InAppBrowser.js
> > >> plugin/logger/js/common/logger.js
> > >> plugin/logger/js/common/console-via-logger.js
> > >> plugin/media/js/common/Capture*.js
> > >> plugin/media/js/common/ConfigurationData.js
> > >> plugin/media/js/common/Media*.js
> > >> plugin/network/js/common/Connection.js
> > >> plugin/notification/js/common/notification.js
> > >> plugin/camera/js/common/Camera*.js
> > >> plugin/echo/js/common/echo.js
> > >> plugin/file/js/common/Directory*.js
> > >> plugin/file/js/common/Entry.js
> > >> plugin/file/js/common/File*.js
> > >> plugin/file/js/common/Flags.js
> > >> plugin/file/js/common/LocalFileSystem.js
> > >> plugin/file/js/common/Metadata.js
> > >> plugin/file/js/common/ProgressEvent.js
> > >> plugin/splashscreen/js/common/splashscreen.js
> > >>
> >
> >
>



-- 
@purplecabbage
risingj.com

Re: Moving plugin JS files around

Posted by Shazron <sh...@gmail.com>.

+1


On Wed, Jan 9, 2013 at 10:57 AM, Filip Maj <fi...@adobe.com> wrote:

> https://github.com/alunny/cordova-plugin-spec
>
>
> We should move this to our wiki asap
>
> On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:
>
> >Ideally the require paths should stay true to the following rules (not
> >that
> >we follow them exactly now but we are close):
> >
> >1. should always start with cordova (in case we ever share a require
> >framework)
> >2. should follow as close as possible to the folder structure.
> >
> >We don't really do this now (but we are close).  It is mainly to help with
> >navigation of the project from a require statement:
> >
> >     var foo = require('cordova/plugin/foo/submodule')
> >
> >Ideally I should be able to navigate to a file that lives in:
> >
> >     ~/cordova.js/plugin/foo/submodule.js
> >
> >But realistically we are probably going to see:
> >
> >    ~/cordova.js/plugin/foo/js/submodule.js
> >
> >Assuming we are dumping everything into a js folder here is the "mapping"
> >off the top of my head:
> >
> >    var foo = require('cordova/plugin/foo')
> >    ~/cordova.js/plugin/foo/js/index.js
> >
> >    var foo = require('cordova/plugin/foo/ios')
> >    ~/cordova.js/plugin/foo/js/ios.js
> >
> >    var foo = require('cordova/plugin/foo/blackberry/qnx')
> >    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
> >
> >What does a plugin (native and js code) folder structure look like?
> >
> >
> >On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com> wrote:
> >
> >> I'd like to take a first step towards moving plugin JS into separate
> >>repos
> >> by first moving them around within cordova-js.
> >>
> >> Here is my proposal:
> >>
> >> Current structure:
> >>         lib/common/plugin/*.js
> >>         lib/$PLATFORM/plugin/*.js
> >>
> >> New structure:
> >>         plugin/$PLUGIN_NAME/js/common/*.js
> >>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
> >>
> >> The require path will need to change. Going from:
> >>         cordova.require('cordova/plugin/FileTransferError')
> >> To:
> >>         cordova.require('plugin/file/FileTransferError')
> >>
> >>
> >> I'll obviously need to update the builder scripts accordingly. The idea
> >> here is that we:
> >>         1. "cordova plugin add" will copy files into a project's plugins
> >> directory
> >>         2. "cordova build ios" will use the cordova-js packager and
> >>pass it
> >> the plugin/ directory to use
> >>
> >> This will not involve changing how we export modules onto namespaces in
> >> common.js / platform.js. That will come next though.
> >>
> >>
> >> The resulting structure will look like:
> >>
> >> plugin/accelerometer/js/common/Acceleration.js
> >> plugin/accelerometer/js/common/accelerometer.js
> >> plugin/battery/js/common/battery.js
> >> plugin/compass/js/common/Compass*.js
> >> plugin/contacts/js/common/Contact*.js
> >> plugin/device/js/common/device.js
> >> plugin/geolocation/js/common/Coordinates.js
> >> plugin/geolocation/js/common/Position*.js
> >> plugin/globalization/js/common/Globalization*.js
> >> plugin/inappbrowser/js/common/InAppBrowser.js
> >> plugin/logger/js/common/logger.js
> >> plugin/logger/js/common/console-via-logger.js
> >> plugin/media/js/common/Capture*.js
> >> plugin/media/js/common/ConfigurationData.js
> >> plugin/media/js/common/Media*.js
> >> plugin/network/js/common/Connection.js
> >> plugin/notification/js/common/notification.js
> >> plugin/camera/js/common/Camera*.js
> >> plugin/echo/js/common/echo.js
> >> plugin/file/js/common/Directory*.js
> >> plugin/file/js/common/Entry.js
> >> plugin/file/js/common/File*.js
> >> plugin/file/js/common/Flags.js
> >> plugin/file/js/common/LocalFileSystem.js
> >> plugin/file/js/common/Metadata.js
> >> plugin/file/js/common/ProgressEvent.js
> >> plugin/splashscreen/js/common/splashscreen.js
> >>
>
>

Re: Moving plugin JS files around

Posted by Filip Maj <fi...@adobe.com>.

https://github.com/alunny/cordova-plugin-spec


We should move this to our wiki asap

On 1/9/13 7:28 AM, "Gord Tanner" <gt...@gmail.com> wrote:

>Ideally the require paths should stay true to the following rules (not
>that
>we follow them exactly now but we are close):
>
>1. should always start with cordova (in case we ever share a require
>framework)
>2. should follow as close as possible to the folder structure.
>
>We don't really do this now (but we are close).  It is mainly to help with
>navigation of the project from a require statement:
>
>     var foo = require('cordova/plugin/foo/submodule')
>
>Ideally I should be able to navigate to a file that lives in:
>
>     ~/cordova.js/plugin/foo/submodule.js
>
>But realistically we are probably going to see:
>
>    ~/cordova.js/plugin/foo/js/submodule.js
>
>Assuming we are dumping everything into a js folder here is the "mapping"
>off the top of my head:
>
>    var foo = require('cordova/plugin/foo')
>    ~/cordova.js/plugin/foo/js/index.js
>
>    var foo = require('cordova/plugin/foo/ios')
>    ~/cordova.js/plugin/foo/js/ios.js
>
>    var foo = require('cordova/plugin/foo/blackberry/qnx')
>    ~/cordova.js/plugin/foo/js/blackberry/qnx.js
>
>What does a plugin (native and js code) folder structure look like?
>
>
>On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com> wrote:
>
>> I'd like to take a first step towards moving plugin JS into separate
>>repos
>> by first moving them around within cordova-js.
>>
>> Here is my proposal:
>>
>> Current structure:
>>         lib/common/plugin/*.js
>>         lib/$PLATFORM/plugin/*.js
>>
>> New structure:
>>         plugin/$PLUGIN_NAME/js/common/*.js
>>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
>>
>> The require path will need to change. Going from:
>>         cordova.require('cordova/plugin/FileTransferError')
>> To:
>>         cordova.require('plugin/file/FileTransferError')
>>
>>
>> I'll obviously need to update the builder scripts accordingly. The idea
>> here is that we:
>>         1. "cordova plugin add" will copy files into a project's plugins
>> directory
>>         2. "cordova build ios" will use the cordova-js packager and
>>pass it
>> the plugin/ directory to use
>>
>> This will not involve changing how we export modules onto namespaces in
>> common.js / platform.js. That will come next though.
>>
>>
>> The resulting structure will look like:
>>
>> plugin/accelerometer/js/common/Acceleration.js
>> plugin/accelerometer/js/common/accelerometer.js
>> plugin/battery/js/common/battery.js
>> plugin/compass/js/common/Compass*.js
>> plugin/contacts/js/common/Contact*.js
>> plugin/device/js/common/device.js
>> plugin/geolocation/js/common/Coordinates.js
>> plugin/geolocation/js/common/Position*.js
>> plugin/globalization/js/common/Globalization*.js
>> plugin/inappbrowser/js/common/InAppBrowser.js
>> plugin/logger/js/common/logger.js
>> plugin/logger/js/common/console-via-logger.js
>> plugin/media/js/common/Capture*.js
>> plugin/media/js/common/ConfigurationData.js
>> plugin/media/js/common/Media*.js
>> plugin/network/js/common/Connection.js
>> plugin/notification/js/common/notification.js
>> plugin/camera/js/common/Camera*.js
>> plugin/echo/js/common/echo.js
>> plugin/file/js/common/Directory*.js
>> plugin/file/js/common/Entry.js
>> plugin/file/js/common/File*.js
>> plugin/file/js/common/Flags.js
>> plugin/file/js/common/LocalFileSystem.js
>> plugin/file/js/common/Metadata.js
>> plugin/file/js/common/ProgressEvent.js
>> plugin/splashscreen/js/common/splashscreen.js
>>

Re: Moving plugin JS files around

Posted by Gord Tanner <gt...@gmail.com>.

Ideally the require paths should stay true to the following rules (not that
we follow them exactly now but we are close):

1. should always start with cordova (in case we ever share a require
framework)
2. should follow as close as possible to the folder structure.

We don't really do this now (but we are close).  It is mainly to help with
navigation of the project from a require statement:

     var foo = require('cordova/plugin/foo/submodule')

Ideally I should be able to navigate to a file that lives in:

     ~/cordova.js/plugin/foo/submodule.js

But realistically we are probably going to see:

    ~/cordova.js/plugin/foo/js/submodule.js

Assuming we are dumping everything into a js folder here is the "mapping"
off the top of my head:

    var foo = require('cordova/plugin/foo')
    ~/cordova.js/plugin/foo/js/index.js

    var foo = require('cordova/plugin/foo/ios')
    ~/cordova.js/plugin/foo/js/ios.js

    var foo = require('cordova/plugin/foo/blackberry/qnx')
    ~/cordova.js/plugin/foo/js/blackberry/qnx.js

What does a plugin (native and js code) folder structure look like?


On Wed, Jan 9, 2013 at 9:42 AM, Andrew Grieve <ag...@google.com> wrote:

> I'd like to take a first step towards moving plugin JS into separate repos
> by first moving them around within cordova-js.
>
> Here is my proposal:
>
> Current structure:
>         lib/common/plugin/*.js
>         lib/$PLATFORM/plugin/*.js
>
> New structure:
>         plugin/$PLUGIN_NAME/js/common/*.js
>         plugin/$PLUGIN_NAME/js/$PLATFORM/*.js
>
> The require path will need to change. Going from:
>         cordova.require('cordova/plugin/FileTransferError')
> To:
>         cordova.require('plugin/file/FileTransferError')
>
>
> I'll obviously need to update the builder scripts accordingly. The idea
> here is that we:
>         1. "cordova plugin add" will copy files into a project's plugins
> directory
>         2. "cordova build ios" will use the cordova-js packager and pass it
> the plugin/ directory to use
>
> This will not involve changing how we export modules onto namespaces in
> common.js / platform.js. That will come next though.
>
>
> The resulting structure will look like:
>
> plugin/accelerometer/js/common/Acceleration.js
> plugin/accelerometer/js/common/accelerometer.js
> plugin/battery/js/common/battery.js
> plugin/compass/js/common/Compass*.js
> plugin/contacts/js/common/Contact*.js
> plugin/device/js/common/device.js
> plugin/geolocation/js/common/Coordinates.js
> plugin/geolocation/js/common/Position*.js
> plugin/globalization/js/common/Globalization*.js
> plugin/inappbrowser/js/common/InAppBrowser.js
> plugin/logger/js/common/logger.js
> plugin/logger/js/common/console-via-logger.js
> plugin/media/js/common/Capture*.js
> plugin/media/js/common/ConfigurationData.js
> plugin/media/js/common/Media*.js
> plugin/network/js/common/Connection.js
> plugin/notification/js/common/notification.js
> plugin/camera/js/common/Camera*.js
> plugin/echo/js/common/echo.js
> plugin/file/js/common/Directory*.js
> plugin/file/js/common/Entry.js
> plugin/file/js/common/File*.js
> plugin/file/js/common/Flags.js
> plugin/file/js/common/LocalFileSystem.js
> plugin/file/js/common/Metadata.js
> plugin/file/js/common/ProgressEvent.js
> plugin/splashscreen/js/common/splashscreen.js
>