HI Tobias having a .framework should work. If you are having problems please open an issue, it might be just a doc problem
How are you publishing your plugin to npm registry? Does the plugin installs correctly if if you install "cordova plugin add <folder>" from a folder ? And it doesn't work if you install by fetching from npm registry? "cordova plugin add <npm-pkg-name>"? I think the problem is the way you packaged your npm package to the registry you loosed your symlinks inside the .framework. I think the last advice in this mailing list was, to first created a tgz from the content of your plugin first, Then pass the tgz which should capture the symlinks inside, pass to npm with npm publish <tarball> Don't do npm publish <folder> On Sun, Sep 20, 2015 at 11:50 PM Tobias Bocanegra <tri...@apache.org> wrote: > Hi Carlos, > > thanks for the solutions, see my remarks inline. > > On Sun, Sep 20, 2015 at 11:07 AM, Carlos Santana <csantan...@gmail.com> > wrote: > > Hi Tobias > > You should be able to achieve what you want today. > > I have done it here in some our project's. > > > > Today you should be able to include and distribute a library inside a > > plugin. > > 1) Best choice is to compile and package your library as a .framework > > here is sample on how to specify: > > <framework src="src/ios/WorklightSDK/Frameworks/sqlcipher.framework" > > custom="true" /> > > > > Distributing a framework is better than a static lib, it allows better > > flexibility and better handle for different architectures > > That's what I have today - but I had problems with the symlinks (from > Versions/Current -> Versions/A) and with npm. I also had problems with > codesigning - although it works, the codesign -verify complains. > > > > > 2) Second choice will be compile and package your library as a static lib > > SomethingLib.a > > <source-file src="src/ios/WorklightSDK/libWorklightStaticLibProject.a" > > compiler-flags="-Obj-C" framework="true" /> > > that would have been my fallback. > > > > > This is is an old example, we moved away from static libs, and now using > > .framework for everything > > > > > 3) Third choice is to distribute your source code by itself .h and .m > > You can see any of the core cordova plugins (i.e. camera, contacts) > > > > No need to distribute you .xcodeproj if you can do it with one of these 3 > > options > > yes. but my lib has 40 files...this gives a rather big plugin.xml. > however, having the .xcodeproj also makes it easier for development. > > > > > If you are having trouble getting this done today, please open a JIRA > issue > > to see how can we fix it. > > > > Distributing a .xcodeproj it can be a bit complex, and we know we package > > CordovaLib as xcodeproj :-). > > > > Today cordova doesn't support workspaces, that's plan for cordova-ios@5 > [1] > > I think after cordova supports workspaces will be easier to manage > multiple > > xcodeprojects inside a single workspace, to able to compile a target > > resolving all dependencies within the workspace. > > that would be cool. > > > > At work we are looking closely at workspaces, after this is done then we > > can see how can distribute our native ios code (i.e. in source code) once > > to cococapods, and then have a cordova plugin depend on it [2]. > > > > Maybe all this doesn't cover your exact use case, so maybe you can open a > > enhancement lira item, and put some seudo code there on what exactly you > > want to achieve. > > > > I know Windows supported the attribute type="projectReference" [3] for > the > > <framework> element, the tricky part with ios is dealing with > dependencies > > conflicts of other puglins, and the user's own code. > > I don't think it is too complicated. If I compare the pbxproj before > and after I add my library manually, > it only has a few additions. adding the project to the frameworks is > already handled - the only thing missing is copying the sources and > adding the proxy target to the link section. I will look into it when > I get some spare time. > > > > > In terms of copying files that you can't do with <assets> or > > <resource-file> you can use a plugin hook, do it there at plugin install > > event. we have done this also at work. > > ok. I'll try this as well. > thanks alot. > > regards, toby > > > > > [1]: https://issues.apache.org/jira/browse/CB-5921 > > [2]: https://issues.apache.org/jira/browse/CB-7942 > > [3]: > > > http://cordova.apache.org/docs/en/edge/plugin_ref_spec.md.html#Plugin%20Specification_framework_element > > > > -- Carlos > > > > On Sat, Sep 19, 2015 at 4:38 PM Anis KADRI <anis.ka...@gmail.com> wrote: > > > >> The library that we use (node-xcode) supports: System Frameworks, Custom > >> Frameworks (ones you would drag&drop into your project) and static > >> libraries. It does not support XCode subprojects as far as I know. > >> If you want to add support for it, you're more than welcome. Repository > is > >> right here: https://github.com/alunny/node-xcode > >> > >> Anis > >> > >> On Fri, Sep 18, 2015 at 11:14 PM Tobias Bocanegra <tri...@apache.org> > >> wrote: > >> > >> > Hi, > >> > > >> > I want to add a plugin to a ios/osx project. the plugin contains a > >> > .xcodeproj of a static library, incuding the sources. I want to avoid > >> > distributing the binary .a in the plugin. > >> > > >> > I tried various ways of how to specify this library, with <framework> > >> > with <src framework=true> etc. but it never adds the lib.a to the > >> > linker section in build phases. > >> > > >> > looking at the pbxproj, it looks like it would have to specify a proxy > >> > reference to the library project. which is a bit more complex than > >> > just add the framwork reference. > >> > > >> > Is this something that would be desired by others? If so, I can try to > >> > improve the plugman script to deal property with the library. > >> > > >> > the 2nd problem is, that xcode usually has the sources beside the > >> > xcodeproj. so for example: > >> > > >> > mylib.xcodeprj/ > >> > mylib/ > >> > > >> > but there is no tag to copy an entire directory. using the <framework> > >> > tag also for the sources, would embed it to the frameworks section, > >> > which is also wrong. > >> > > >> > ideally we would be able to specify the source directory, like > >> > > >> > <framework src="frameworks/osx/mylib.xcodeproj" custom="true" > >> > sources="frameworks/osx/mylib" /> > >> > > >> > OR > >> > > >> > add a new sub-project tag, like: > >> > > >> > <sub-project src="frameworks/osx/mylib" > >> > project="frameworks/osx/mylib.xcodeproj" framework="true" > >> > link-targets="libMyLib.a" /> > >> > > >> > WDYT? > >> > > >> > Regards, Toby > >> > > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> > For additional commands, e-mail: dev-h...@cordova.apache.org > >> > > >> > > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
