cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Soref <jso...@blackberry.com>
Subject RE: Cordova Plugins with Symlinks
Date Wed, 06 May 2015 18:05:09 GMT
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


Mime
View raw message