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‹KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB• È
>> [œÝ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
