I think in this case we should be not be using symlinks. All of our output project types support adding a reference to a file or folder, we should leverage this directly. Of course, this could possibly lead to forward vs back slash issues, but should be easier than running hook hacks. At least I think we should explore this way.
> On May 6, 2015, at 7:53 AM, Chuck Lantz <cla...@microsoft.com> wrote: > > Hey folks, > > So I’ve started to see some issues come up with certain Cordova plugins > when devs are mixing a Windows and OSX environment together when developing > an app. Digging into it a bit, it looks like root cause is that there are > some situations where iOS plugin implementations with custom frameworks that > require symlinks - as described in the thread below. > > In addition to the situation mentioned in the thread, there's a second one > worth calling out: installing a plugin with symlinks on Windows on the NTFS > file system results in the symlinks becoming files. > > The workaround described in this thread (zipping as a tarball) helps when > plugin installs happen on OSX, but it doesn't resolve the problem with NTFS. > If a development team is split between OSX and Windows machines, the plugin > will appear broken on iOS if it was committed/checked in/copied from Windows. > If, on the other hand, the plugin is added from OSX, it will work - the end > result is the behavior seems "glitchy" and it is not at all obvious what > happened when things go wrong. > > I came up with a hook that fixes these symlinks since the files that are > generated do contain the relative path to the underlying folder – but it is > admittedly a bit of a hack since it attempts to handle any arbitrary plugin: > https://github.com/Chuxel/taco-tricks/tree/master/ios-plugin-symlink-fix > > I think at a minimum, we should call this out in the plugin docs as a > potential issue with a workaround. > > However, It got me thinking, would the right thing here be to just provide > guidance to plugin authors to work around this problem Cordova plugin hook > to create the symlinks or should we develop a way for this to happen > automatically? Ex: A npm pre-publish hook persists symlinks in a file that > are then used before_compile on an OS that supports them. Or frameworks can > be referenced as tar balls in plugin.xml that are then untar'd as a > before_compile step. > > Thoughts? > > -Chuck > > -----Original Message----- > From: Ally Ogilvie [mailto:aogil...@wizcorp.jp] > Sent: Friday, September 5, 2014 3:31 AM > To: dev@cordova.apache.org > Subject: Re: Cordova Plugin Registry iOS frameworks > > Thanks Carlos. I'll take a look Monday. Have a good weekend. > > >> On Fri, Sep 5, 2014 at 4:06 AM, Carlos Santana <csantan...@gmail.com> wrote: >> >> Source code is here: >> >> https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/plug >> man/registry/registry.js#L97 >> >> I think the fix will be to create a tarball in some tmp after >> generating pacakgeJson, then calling npm .commands, 'publish', args >> with the tarball instead of a folder containing the package.json >> >> Have fun !, remember to add unit tests :-) >> >> >> >>> On Wed, Sep 3, 2014 at 10:37 PM, Ally Ogilvie <aogil...@wizcorp.jp> wrote: >>> >>> I tried to find plugman source code responsible for npm publish but >> failed. >>> >>> I'm gonna bump this for someone to assign too.. any takers? <3 >>> >>> >>> >>> On Wed, Aug 20, 2014 at 12:12 PM, Ally Ogilvie <aogil...@wizcorp.jp> >>> wrote: >>> >>>>> Ally, do you know if the symlinks are required for the >>>>> FacebookConnect >>>> framework? >>>> >>>> @Ian Absolutely required. Not just for Facebook, but all >>>> .framework >>> files. >>>> >>>> MyFramework.framework // (directory) >>>> info.plist >>>> MyFramework // (symbolic link to >>>> Versions/Current/MyFramework) >>>> Resources // (symbolic link to >>> Versions/Current/Resources) >>>> Headers // (symbolic link to >> Versions/Current/Headers) >>>> Versions // (directory) >>>> Current // (symbolic link to directory "A" below) >>>> A // (directory) >>>> Headers // (directory containing framework headers) >>>> Resources // (directory holding framework resources) >>>> MyFramework // (actual compiled library, really a .a >> file) >>>> >>>> As you can see there are 4 symbolic links in .frameworks. >>>> >>>> >>>> >>>> >>>>> On Tue, Aug 19, 2014 at 5:59 AM, Shazron <shaz...@gmail.com> wrote: >>>>> >>>>> I think the right approach is what Andrew suggested. So the >>>>> current workaround is to tarball it first then publish? >>>>> >>>>> On Mon, Aug 18, 2014 at 12:04 PM, Andrew Grieve >>>>> <agri...@chromium.org >>> >>>>> wrote: >>>>>> Tarballs support symlinks. >>>>>> npm uses tarballs. >>>>>> "npm publish" lets you give a path to a tarball rather than >>>>>> having >> it >>>>> pack >>>>>> it for you. >>>>>> >>>>>> So, I think we probably could fix this in plugman by having it >> create >>>>> the >>>>>> tgz more intelligently. >>>>>> >>>>>> >>>>>> On Mon, Aug 18, 2014 at 2:24 PM, Ian Clelland < >> iclell...@chromium.org >>>> >>>>>> wrote: >>>>>> >>>>>>>> On Mon, Aug 18, 2014 at 12:40 PM, Brian LeRoux <b...@brian.io> wrote: >>>>>>>> >>>>>>>> I like the idea of not supporting them until I hear a really >> great >>>>> reason >>>>>>>> to support them. =) >>>>>>> >>>>>>> Certainly; YAGNI and all that. >>>>>>> >>>>>>> Ally, do you know if the symlinks are required for the >>> FacebookConnect >>>>>>> framework? Is it possible to just git mv the files to the >>>>>>> location >>> that >>>>>>> Xcode expects to find them, and not have to worry about this >>>>>>> issue >> in >>>>>>> plugman? >>>>>>> >>>>>>> Ian >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Aug 18, 2014 at 9:31 AM, Ian Clelland < >>>>> iclell...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> We could have some sort of preprocessing step on the >>>>>>>>> current >>>>> directory, >>>>>>>>> that would prepare it for publishing. >>>>>>>>> >>>>>>>>> Maybe we can either annotate the directory with where the >>> symlinks >>>>>>> should >>>>>>>>> go, or else copy the files, if it's okay to do that. >>>>>>>>> >>>>>>>>> On Monday, August 18, 2014, Mark Koudritsky >>>>>>>>> <kam...@google.com >>> >>>>> wrote: >>>>>>>>> >>>>>>>>>> Plugins are published using "npm publish". As far as I >>>>> understood, >>>>>>> npm >>>>>>>>> does >>>>>>>>>> not include symlinks by design [1] when packing a >>>>>>>>>> package. So >>>>> I'm not >>>>>>>>> sure >>>>>>>>>> about how we could start including symlinks while still >>>>>>>>>> using >>> npm >>>>>>>>> packages >>>>>>>>>> as distribution method. >>>>>>>>>> [1] https://github.com/npm/npm/issues/3310 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Aug 18, 2014 at 9:02 AM, Ian Clelland < >>>>>>> iclell...@chromium.org >>>>>>>>>> <javascript:;>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I saw this come up on Friday on IRC -- I didn't see >>>>>>>>>>> you in >>> the >>>>>>>> channel, >>>>>>>>>>> Ally, or I would have pinged you. >>>>>>>>>>> >>>>>>>>>>> It's definitely an issue with plugman, either with the >>>>> packaging or >>>>>>>> the >>>>>>>>>>> extraction, when there are symlinks present in the repo. >>>>>>>>>>> >>>>>>>>>>> I upgraded the severity of the CB-6092 to critical; we >>>>>>>>>>> need >>> to >>>>>>> find a >>>>>>>>>>> solution for this. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Mon, Aug 18, 2014 at 3:06 AM, Ally Ogilvie < >>>>> aogil...@wizcorp.jp >>>>>>>>>> <javascript:;>> wrote: >>>>>>>>>>> >>>>>>>>>>>> https://issues.apache.org/jira/browse/CB-6092 >>>>>>>>>>>> >>>>>>>>>>>> Symlinks are broken when doing *cordova plugin add* >>> <cordova >>>>>>> plugin >>>>>>>>>>>> registry ID>. For example if a plugin makes use of >>>>>>>>>>>> the >>> custom >>>>>>>>> framework >>>>>>>>>>>> tag: >>>>>>>>>>>> >>>>>>>>>>>> *<framework** src="platforms/ios/FacebookSDK.framework" >>>>>>>> custom="true" >>>>>>>>>> />* >>>>>>>>>>>> >>>>>>>>>>>> I think this is because of the way the registry >>>>>>>>>>>> plugins >> are >>>>> being >>>>>>>>>> served >>>>>>>>>>> to >>>>>>>>>>>> plugman. >>>>>>>>>>>> I wanted a discussion here as this is *critical* for >>> plugins >>>>>>> using >>>>>>>>>> custom >>>>>>>>>>>> framework tags. >>>>>>>>>>>> >>>>>>>>>>>> *Desperately* need someone from Plugman / Registry >>>>>>>>>>>> team >> to >>>>> give >>>>>>>> some >>>>>>>>>> info >>>>>>>>>>>> on what's going on for the community to patch it. >>>>>>>>>>>> >>>>>>>>>>>> Here's what the symlinks for .frameworks look like >>>>>>>>>>>> after >>>>> plugin >>>>>>> add >>>>>>>>>> from >>>>>>>>>>>> CPR >>>>>>>>>>>> http://stackoverflow.com/a/25327341 >>>>>>>>>>>> >>>>>>>>>>>> Windows boxes / Git clone and symlinks info: >>>>>>>>>>>> http://stackoverflow.com/a/11664406 >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> <http://www.wizcorp.jp/>Ally Ogilvie Lead Developer >>>>>>>>>>>> - MobDev. | Wizcorp Inc. < >>>>> http://www.wizcorp.jp/> >>>>>>>>>>>> ------------------------------ TECH . GAMING . >>>>>>>>>>>> OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 | >>>>> Website >>>>>>>>>>>> <http://www.wizcorp.jp/> | Twitter < >>>>> https://twitter.com/Wizcorp> >>>>>>> | >>>>>>>>>>>> Facebook >>>>>>>>>>>> <http://www.facebook.com/Wizcorp> | LinkedIn >>>>>>>>>>>> <http://www.linkedin.com/company/wizcorp> >> >> >> >> -- >> Carlos Santana >> <csantan...@gmail.com> > > > > -- > <http://www.wizcorp.jp/>Ally Ogilvie > Lead Developer - MobDev. | Wizcorp Inc. <http://www.wizcorp.jp/> > ------------------------------ > TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448 | Website > <http://www.wizcorp.jp/> | Twitter <https://twitter.com/Wizcorp> | Facebook > <http://www.facebook.com/Wizcorp> | LinkedIn > <http://www.linkedin.com/company/wizcorp> > B‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB•È [œÝXœØÜšX™KK[XZ[ˆ]‹][œÝXœØÜšX™PÛܙݘK˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ˆ]‹Z[ ÛܙݘK˜\XÚK›Ü™ÃB --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
