incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Plugin Format and Spec
Date Mon, 25 Jun 2012 23:29:32 GMT
I wouldn┬╣t call that a blocker..

Pluginstall works fine with node 0.6.8 too.

I was using 0.6.6, some dependencies in pluginstall require at least node
0.6.7, so I upgraded to 0.6.8. Works fine.

On 6/25/12 3:59 PM, "Shazron" <shazron@gmail.com> wrote:

>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-shri
>>nkwrap/
>>
>>
>> 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