Could we fix our un-tarring logic to create symlinks on windows? On Wed, May 6, 2015 at 2:39 PM, Chuck Lantz <cla...@microsoft.com> wrote:
> Yeah that was one of the alternatives I was thinking about as a part of > that pre-publish step I mentioned. Really, you'd need to either: > > 1. Provide a general mechanism for all symlinks using a metadata file > a. Prep-publish: Run through and find paths to symlinks (which is > easy to do with node), store in a json file with the plugin > b. After Platform Add / Plugin Add, or just Before Compile: Use > the metadata file to generate the symlinks if OS = OSX or Linux > > 2. Provide a specific mechanism to deal with frameworks > a. Pre-publish: Find custom frameworks. (Which you can actually do > using plugin.xml), tgz them > b. After Platform Add / Plugin Add, or just Before Compile: Expand > framework tgz if found > > (a) could be done via npm but (b) really has to be done via a Cordova hook > or be inherent to the iOS platform. > > Maybe the thing to do is to develop these hooks and add them to the > default template for plugins and in addition to the docs. #1 is likely a > bit more robust. > > -Chuck > > -----Original Message----- > From: Josh Soref [mailto:jso...@blackberry.com] > Sent: Wednesday, May 6, 2015 11:05 AM > To: dev@cordova.apache.org > Subject: RE: Cordova Plugins with Symlinks > > It should be possible for our build system to convert some metadata into > symlinks which are fed to whatever build thing actually requires them, but > allows us to not have genuine symlinks in the working directory. > > The BlackBerry 10 project copies all the files it wants to package over > into another directory, other platforms should be able to do similar. > > > -----Original Message----- > > From: Shazron [mailto:shaz...@gmail.com] > > Sent: Wednesday, May 06, 2015 1:23 PM > > To: dev@cordova.apache.org > > Subject: Re: Cordova Plugins with Symlinks > > > > Ordinarily I agree with Jesse's sentiment about not using symlinks but > > that is just the reality for .frameworks. > > > > That being said, I don't think we should do anything extra for authors > > _but_ instead provide a middle ground that you mentioned "provide > > guidance to plugin authors to work around this problem" and even as a > > pre-publish (or analysis) step that checks whether this might be a > > problem, and warns them. > > > > On Wed, May 6, 2015 at 9:54 AM, Chuck Lantz <cla...@microsoft.com> > > wrote: > > > Yeah, I agree symlinks should be avoided, but what Ally highlighted > below > > is that it is required in this case. ("@Ian Absolutely required. Not > just for > > Facebook, but all .framework files.") Given that statement, it seems > that in > > this case we need to have some sort of solution to remediate the problem > > does it not? > > > > > > -Chuck > > > > > > -----Original Message----- > > > From: Jesse [mailto:purplecabb...@gmail.com] > > > Sent: Wednesday, May 6, 2015 9:16 AM > > > To: dev@cordova.apache.org > > > Subject: Re: Cordova Plugins with Symlinks > > > > > > 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-f > > >> ix > > >> > > >> 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/plu > > >>> g > > >>> 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‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK > > KKKKKKKKKKKCB• È [œÝXœØÜšX™K K[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 > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > For additional commands, e-mail: dev-h...@cordova.apache.org > >
