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 Thu, 07 May 2015 15:21:31 GMT
Never mind - One of the things that requires a symlink is a file, so junctions won't work.
 They also don't seem to move the contents when transferred via Samba.

On untar, we'd basically need to duplicate the files to get it to work at that point I think.
 I did try that and it seems to work - Anyone know if there are potential unintended side-effects
of doing that?

-Chuck

-----Original Message-----
From: Chuck Lantz [mailto:clantz@microsoft.com] 
Sent: Thursday, May 7, 2015 8:05 AM
To: dev@cordova.apache.org
Subject: RE: Cordova Plugins with Symlinks

Possibly using junctions. 

Actual symlinks require administrator privileges and there's no "sudo" like command which
is why they're not used frequently.  You can create "folder junctions" (via mklink) without
admin privs which would technically meet the need here since these are folder symlinks. 

One issue with junctions, however, is junctions look like folders when zipped or committed
to a Git repo, so basically you just duplicate all the files. However, as long as frameworks
will work with the contents duplicated rather than symlink'd, it make be an acceptable workaround.
 Need to validate.

-Chuck

-----Original Message-----
From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of Andrew Grieve
Sent: Thursday, May 7, 2015 6:55 AM
To: dev
Subject: Re: Cordova Plugins with Symlinks

Could we fix our un-tarring logic to create symlinks on windows?

On Wed, May 6, 2015 at 2:39 PM, Chuck Lantz <clantz@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:jsoref@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:shazron@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 <clantz@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: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‹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-unsubscribe@cordova.apache.org
> > > For additional commands, e-mail: dev-help@cordova.apache.org
> > >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Mime
View raw message