cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Cordova Plugins with Symlinks
Date Thu, 07 May 2015 13:54:33 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message