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 <[email protected]> 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 ([email protected]) 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 <[email protected]> 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 <[email protected]>
