incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: Plugin Format and Spec
Date Mon, 25 Jun 2012 23:32:42 GMT
0.6.8 ? Is your toaster unplugged Fil?
I am in windows and running without issue :
$ node -v => v0.6.18


On Mon, Jun 25, 2012 at 4:29 PM, Filip Maj <fil@adobe.com> wrote:

> 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
>
>


-- 
@purplecabbage
risingj.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message