cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Lantz <cla...@microsoft.com>
Subject RE: Cordova Plugins with Symlinks
Date Wed, 06 May 2015 16:54:58 GMT
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:purplecabbage@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 <clantz@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:aogilvie@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 <csantana23@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 <aogilvie@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 <aogilvie@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 <shazron@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 
>>>>> <agrieve@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 <
>> iclelland@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 <
>>>>> iclelland@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 
>>>>>>>>> <kamrik@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 <
>>>>>>> iclelland@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
<
>>>>> aogilvie@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
>> <csantana23@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-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org

Mime
View raw message