cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: plugins, npm, and package.json …other art
Date Fri, 03 Apr 2015 15:35:04 GMT
Brian now that I see this, your twitter stream on the topic makes sense now
(uff bundler)

I was not aware they were already this far hitting plugin wall, it didn't
took too much time :-)

I'm guessing that the nativescript looks more similar to cordova (i.e.
talking about "platforms" to refer to ios and android), maybe the some guys
from telerik that work on cordova are also helping out with nativescript.

At least here is my thoughts and even before looking at they were doing,
here at IBM we we hitting the problem about sharing native ios libraries
between plugins, and these libraries we are releasing as cocoapods [1]

where we are going to have a couple of cordova plugins, but these plugins
depend on some common cocoapods libraries.
So we don't want to ship the same cocoapod multiple times for each cordova
plugin.
The same goes with Android to not ship same libraries in multiple
libraries, and instead add the dependencies in gradle.build to fetch them

 - Move plugins.xml to package.json (keeping some backwards compatibility
for a while)
 - Leverage npm to host, find, download, cache, install*
 - Plugins like they also realize, can only have one level of nesting
 - Package.json (i.e. plugin.xml) to support declared dependencies for
gradle, pods, etc... similar to the proposed by nativescript package.json
 - Leverage/delegate as much as possible on pod (as tool, or library) to
deal with ios libraries/frameworks including when two plugins depend on the
same pod with conflicting versions, maybe also create podspec on the fly
when plugin includes native code in source code format, or like Shaz
proposed create a framework on the fly, regardless a podspec can be created
for a local set of source code and/or frameworks. I'm not 100% in favor or
frameworks as I like the openess of having the power to debug and put
brakepoints on others code. Most of the cocoapods I have dealt are release
as source where the source is also in github. easy to debug a open source
library.
 - I like the idea from nativescript to have Info.plist and
AndroidManifest.xml as portions to merge for the given plugin

Sorry for all the noise :-( on this emai

[1]: http://cocoapods.org/?q=IMF



On Fri, Apr 3, 2015 at 5:05 AM, tommy-carlos williams <tommy@devgeeks.org>
wrote:

> I guess that’s because Android hasn’t been released. Maybe they feel they
> can’t reveal much about it yet :(
>
> --
> tommy-carlos williams
>
> On 3 April 2015 at 17:41:51, Jesse (purplecabbage@gmail.com) wrote:
>
> Yeah, the more I look at these, the more overlap I see.
> I am surprised how narrowly scoped the react discussion is. iOS only? Is
> Android not even on their radar?
>
> @purplecabbage
> risingj.com
>
> On Thu, Apr 2, 2015 at 5:51 PM, Brian LeRoux <b@brian.io> wrote:
>
> > both reactnative [1] and nativescript [2] treading into the territory
> >
> > fleeting hope we could share work/code but probably good everyone does a
> > bit of homework on the topic
> >
> > [1] https://github.com/facebook/react-native/issues/235
> > [2] https://github.com/NativeScript/NativeScript/issues/25
> >
>



-- 
Carlos Santana
<csantana23@gmail.com>

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