incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shazron <shaz...@gmail.com>
Subject Re: Plugin Format and Spec
Date Mon, 25 Jun 2012 22:59:36 GMT
pluginstall blocker:
https://github.com/alunny/node-xcode/issues/3
https://issues.apache.org/jira/browse/CB-631

Only works with node 0.6.17


On Mon, Jun 25, 2012 at 2:09 PM, Jesse <purplecabbage@gmail.com> wrote:
> We could use an 'engine' type specification similar to npm :
> "engine": "node >= 0.4.1"
>
> http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/
>
>
> On Mon, Jun 25, 2012 at 2:02 PM, Filip Maj <fil@adobe.com> wrote:
>
>> Ideally, I would think we do NOT plan on doing that post-2.0. That said,
>> our current deprecation policy, last I checked, was "6 months from now",
>> which does not guarantee that the API will not change between minor
>> revisions.
>>
>> Thus, the conversation turns back to project versioning and deprecation.
>>
>> Mike and I spoke about this this morning. I think both of us support the
>> idea of moving to semantic versioning for 2.0 and beyond.
>>
>> On 6/25/12 1:45 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>>
>> >Agreed fil, but are we planning on doing that for future releases ? If yes
>> >that YAH we should support versions and the solution you described is
>> >certainly an option. But if I were a plugin developer, I would not want to
>> >update it every month to keep up with Cordova releases.
>> >I don't disagree that there could be an Cordova version in the manifest
>> >file that allows plugin developers to target a specific version of Cordova
>> >(which would mean that the plugin was tested with that version but might
>> >also work with newer versions).
>> >
>> >On Mon, Jun 25, 2012 at 1:33 PM, Filip Maj <fil@adobe.com> wrote:
>> >
>> >> Yes, it has changed every month. Pretty much every minor revision from
>> >>1.0
>> >> to 1.9 has changed the API (at least on Android).
>> >>
>> >> On 6/25/12 1:26 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>> >>
>> >> >Right but does the plugin interface change every month too ? A plugin
>> >>that
>> >> >works with Cordova 1.x.x is not supposed to work with Cordova 1.y.y
?
>> >> >
>> >> >On Mon, Jun 25, 2012 at 1:18 PM, Filip Maj <fil@adobe.com> wrote:
>> >> >
>> >> >> You don't see any reason why plugins should support different
>> >>versions
>> >> >>of
>> >> >> cordova? Cordova gets released every month. This seems like a pretty
>> >> >> important thing to figure out IMO
>> >> >>
>> >> >> On 6/25/12 1:12 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>> >> >>
>> >> >> >I think we should agree on a spec (plugin package and plugin
>> >>interface)
>> >> >> >and
>> >> >> >stick to it. As long as we don't break the plugin interface,
I don't
>> >> >>see
>> >> >> >any reason why plugins should support multiple versions of
Cordova.
>> >>If
>> >> >> >there are any, I'd love to hear them.
>> >> >> >
>> >> >> >On Mon, Jun 25, 2012 at 1:01 PM, Filip Maj <fil@adobe.com>
wrote:
>> >> >> >
>> >> >> >> Back onto the versioning question..
>> >> >> >>
>> >> >> >> 1. Do we want to support different version of the cordova
>> >>framework
>> >> >>in
>> >> >> >> plugins, within a single repo, across versions that changed
the
>> >> >> >> native/javascript plugin API?
>> >> >> >> 2. How?
>> >> >> >>
>> >> >> >> If the answer to (1) is yes, one idea for (2) might be
nesting
>> >> >>another
>> >> >> >> directory level in the all of the source directories that
contains
>> >> >>the
>> >> >> >> version number supported. For example:
>> >> >> >>
>> >> >> >> src/android/1.5.0/*.java
>> >> >> >> src/android/1.8.1/*.java
>> >> >> >> www/1.5.0/childbrowser.js
>> >> >> >> www/1.8.1/childbrowser.js
>> >> >> >>
>> >> >> >> Could get gnarly real quick though. Another, cleaner
>> >>implementation
>> >> >>in
>> >> >> >> terms of file system "noise" might be to employ a git
branches
>> >> >> >> convention.. But that would enforce a git dependency.
>> >> >> >>
>> >> >> >> Just brainstorming / thinking out loud. Both are probably
bad
>> >>ideas
>> >> >>:)
>> >> >> >>
>> >> >> >> On 6/25/12 11:41 AM, "Michael Brooks" <michael@michaelbrooks.ca>
>> >> >>wrote:
>> >> >> >>
>> >> >> >> >We may also want to describe testing from JavaScript
and Native.
>> >> >> >> >
>> >> >> >> >I would also like to see a repository called
>> >> >>"cordova-plugin-template"
>> >> >> >> >that
>> >> >> >> >is a boilerplate to start writing any plugin. The
idea is that
>> >>users
>> >> >> >>start
>> >> >> >> >with something that works, with tests, and documentation
>> >> >>boilerplate -
>> >> >> >> >perhaps it can be an echo plugin since that has a
minimal
>> >>footprint.
>> >> >> >> >
>> >> >> >> >On Mon, Jun 25, 2012 at 11:28 AM, Filip Maj <fil@adobe.com>
>> >>wrote:
>> >> >> >> >
>> >> >> >> >> Looks great. I'll add some detail to the list
you have here.
>> >>I'd
>> >> >> >> >>recommend
>> >> >> >> >> tweaking the order a little bit; introducing
the JS before the
>> >> >>native
>> >> >> >> >>APIs.
>> >> >> >> >>
>> >> >> >> >> # Plugin Author Guide
>> >> >> >> >>
>> >> >> >> >> - plugin package format -> points to Andrew's
plugin spec
>> >> >> >> >> - js api
>> >> >> >> >> --- basically documenting exec(). Service, action,
callbacks,
>> >> >> >>arguments.
>> >> >> >> >> What about how arguments are translated from
JS types (string,
>> >> >> >>number,
>> >> >> >> >> objects, etc) to native types for each platform?
>> >> >> >> >>
>> >> >> >> >> - native api
>> >> >> >> >> --- ios
>> >> >> >> >> --- android
>> >> >> >> >> --- blackberry
>> >> >> >> >> --- windowsphone
>> >> >> >> >> --- bada
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> On 6/25/12 11:16 AM, "Brian LeRoux" <b@brian.io>
wrote:
>> >> >> >> >>
>> >> >> >> >> >Biggest question is how to document. My thinking
is that we
>> >>want
>> >> >>to
>> >> >> >> >> >specify the PluginPackage so that PluginInstall
works. So the
>> >> >>docs
>> >> >> >> >> >would read like this:
>> >> >> >> >> >
>> >> >> >> >> ># Plugin Author Guide
>> >> >> >> >> >
>> >> >> >> >> >- plugin package format
>> >> >> >> >> >- native api
>> >> >> >> >> >--- ios
>> >> >> >> >> >--- android
>> >> >> >> >> >--- blackberry
>> >> >> >> >> >--- windowsphone
>> >> >> >> >> >--- bada
>> >> >> >> >> >- js api
>> >> >> >> >> >
>> >> >> >> >> >Thoughts? (If this looks good I will update
the issue.)
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> >On Mon, Jun 25, 2012 at 10:50 AM, Filip Maj
<fil@adobe.com>
>> >> >>wrote:
>> >> >> >> >> >> Hah Michael and I were just talking
about that..
>> >> >> >> >> >>
>> >> >> >> >> >> I will send a pull request to Andrew's
draft spec
>> >> >> >> >> >>
>> >> >> >> >> >> On 6/25/12 10:46 AM, "Brian LeRoux"
<b@brian.io> wrote:
>> >> >> >> >> >>
>> >> >> >> >> >>>npm does this w/ an 'engines' attribute
on package.json
>> >> >> >> >> >>>
>> >> >> >> >> >>>On Mon, Jun 25, 2012 at 10:26 AM,
Filip Maj <fil@adobe.com>
>> >> >> wrote:
>> >> >> >> >> >>>> One more thing that came to
mind is how to support
>> >>different
>> >> >> >> >>versions
>> >> >> >> >> >>>>of Cordova? Any ideas?
>> >> >> >> >> >>>>
>> >> >> >> >> >>>> From: Andrew Lunny
>> >> >><alunny@gmail.com<mailto:alunny@gmail.com>>
>> >> >> >> >> >>>> Reply-To: "alunny@gmail.com<mailto:alunny@gmail.com>"
>> >> >> >> >> >>>><alunny@gmail.com<mailto:alunny@gmail.com>>
>> >> >> >> >> >>>> To: Default User Nam <fil@adobe.com<mailto:fil@adobe.com
>> >>
>> >> >> >> >> >>>> Cc:
>> >> >> >> >> >>>>"callback-dev@incubator.apache.org<mailto:
>> >> >> >> >> callback-dev@incubator.apache
>> >> >> >> >> >>>>.o
>> >> >> >> >> >>>>rg>"
>> >> >> >> >> >>>><callback-dev@incubator.apache.org<mailto:
>> >> >> >> >> callback-dev@incubator.apache
>> >> >> >> >> >>>>.o
>> >> >> >> >> >>>>rg>>
>> >> >> >> >> >>>> Subject: Re: Plugin Format and
Spec
>> >> >> >> >> >>>>
>> >> >> >> >> >>>>
>> >> >> >> >> >>>>
>> >> >> >> >> >>>> On 11 June 2012 13:50, Filip
Maj
>> >> >> >> >><fil@adobe.com<mailto:fil@adobe.com
>> >> >> >> >> >>
>> >> >> >> >> >>>>wrote:
>> >> >> >> >> >>>> Nice work Andrew! I suggest
taking this and moving to a
>> >> >>cordova
>> >> >> >> >>wiki
>> >> >> >> >> >>>>page
>> >> >> >> >> >>>> (assuming all committers are
on board to adopting this as
>> >>the
>> >> >> >>basis
>> >> >> >> >> >>>>for
>> >> >> >> >> >>>>a
>> >> >> >> >> >>>> plugin spec)
>> >> >> >> >> >>>>
>> >> >> >> >> >>>> A link on the Cordova wiki is
probably the best place to
>> >> >>start
>> >> >> >>- we
>> >> >> >> >> >>>>can
>> >> >> >> >> >>>>get some more feedback from plugin
authors and app
>> >>developers
>> >> >> >>(i.e.
>> >> >> >> >> >>>>keep
>> >> >> >> >> >>>>this as "a way to write plugins"
rather than "the official
>> >> >>way to
>> >> >> >> >>write
>> >> >> >> >> >>>>plugins").
>> >> >> >> >> >>>>
>> >> >> >> >> >>>>
>> >> >> >> >> >>>> Is target-dir necessary for
the <source-file> element? For
>> >> >>Java
>> >> >> >> >>files,
>> >> >> >> >> >>>>the
>> >> >> >> >> >>>> tooling could take a peak inside
the .java file and
>> >>extract
>> >> >>out
>> >> >> >>the
>> >> >> >> >> >>>> package name from the file,
no? Phonegap build already
>> >>does
>> >> >>this
>> >> >> >> >> >>>>doesn't
>> >> >> >> >> >>>> it?
>> >> >> >> >> >>>>
>> >> >> >> >> >>>> PhoneGap Build did do this,
but no longer supports
>> >>uploading
>> >> >> >> >>arbitrary
>> >> >> >> >> >>>>Java files. Only plugins with
a manifest are supported.
>> >> >> >> >> >>>>
>> >> >> >> >> >>>> I'm torn - one of the goals
of this format is to make it
>> >>as
>> >> >> >>easy as
>> >> >> >> >> >>>>possible to write tools that
use it as possible. Right
>> >>now, a
>> >> >> >>tool
>> >> >> >> >> >>>>reads
>> >> >> >> >> >>>>one file (plugin.xml) and moves
source files (ignoring
>> >>config
>> >> >> >>files
>> >> >> >> >>for
>> >> >> >> >> >>>>the moment). I'd prefer it wasn't
"read one file, then read
>> >> >>each
>> >> >> >> >>.java
>> >> >> >> >> >>>>file to discover where to move
it".
>> >> >> >> >> >>>>
>> >> >> >> >> >>>> One option is to use the id
attribute on the top-level
>> >>plugin
>> >> >> >> >>element
>> >> >> >> >> >>>>to resolve the path, but that
doesn't handle the case where
>> >> >> >> >>different
>> >> >> >> >> >>>>Java files will have different
paths. I wonder if there are
>> >> >>more
>> >> >> >> >> >>>>complex
>> >> >> >> >> >>>>plugins around we can try to
convert to see where the pain
>> >> >>points
>> >> >> >> >>are.
>> >> >> >> >> >>>>
>> >> >> >> >> >>>>
>> >> >> >> >> >>>> Adding the ability to modify
existing parts of a native
>> >> >> >>platform's
>> >> >> >> >> >>>>config
>> >> >> >> >> >>>> document to the <config-file>
portion might be needed..
>> >> >>Although
>> >> >> >> >>Ive
>> >> >> >> >> >>>>yet
>> >> >> >> >> >>>> to dig up a use case. Will dig
around more.
>> >> >> >> >> >>>>
>> >> >> >> >> >>>> Agreed - also things like target
OS/SDK versions may be
>> >> >> >>required by
>> >> >> >> >> >>>>certain plugins (i.e. this plugin
uses an iOS 6 API, so we
>> >> >>need
>> >> >> >>to
>> >> >> >> >> >>>>update your project to iOS 6).
Probably the best approach
>> >> >>there
>> >> >> >>is
>> >> >> >> >>to
>> >> >> >> >> >>>>warn/prompt the user before proceeding.
>> >> >> >> >> >>>>
>> >> >> >> >> >>>> +1 agree that <resource-file>
and <header-file> is
>> >>redundant.
>> >> >> >> >>Tooling
>> >> >> >> >> >>>> should be able to distinguish
this so merging with
>> >> >><source-file>
>> >> >> >> >> >>>>makes a
>> >> >> >> >> >>>> lot of sense.
>> >> >> >> >> >>>>
>> >> >> >> >> >>>> Looking good!
>> >> >> >> >> >>>>
>> >> >> >> >> >>>> On 6/8/12 6:40 PM, "Andrew Lunny"
>> >> >> >> >> >>>><alunny@gmail.com<mailto:alunny@gmail.com>>
wrote:
>> >> >> >> >> >>>>
>> >> >> >> >> >>>>>Hi all,
>> >> >> >> >> >>>>>
>> >> >> >> >> >>>>>I've posted to this list
before about pluginstall[1], the
>> >> >>tool
>> >> >> >>I've
>> >> >> >> >> >>>>>developed as part of working
on PhoneGap Build and
>> >>requiring
>> >> >> >> >> >>>>>programmatic
>> >> >> >> >> >>>>>installation of Cordova plugins.
>> >> >> >> >> >>>>>
>> >> >> >> >> >>>>>I've now written up a spec
for the format that pluginstall
>> >> >>uses
>> >> >> >>- I
>> >> >> >> >> >>>>>think
>> >> >> >> >> >>>>>it's generally useful for
Cordova plugin installation and
>> >> >> >> >> >>>>>manipulation.
>> >> >> >> >> >>>>>The
>> >> >> >> >> >>>>>spec is available on GitHub:
>> >> >> >> >> >>>>>https://github.com/alunny/cordova-plugin-spec
>> >> >> >> >> >>>>>
>> >> >> >> >> >>>>>Issues and/or pull requests
and/or forks welcome.
>> >> >> >> >> >>>>>
>> >> >> >> >> >>>>>Cheers,
>> >> >> >> >> >>>>>Andrew
>> >> >> >> >> >>>>>
>> >> >> >> >> >>>>>[1] https://github.com/alunny/pluginstall
>> >> >> >> >> >>>>
>> >> >> >> >> >>>>
>> >> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>
>
>
> --
> @purplecabbage
> risingj.com

Mime
View raw message