You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Chuck Lantz <cl...@microsoft.com> on 2015/05/06 16:53:11 UTC
Cordova Plugins with Symlinks
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-fix
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 <cs...@gmail.com> wrote:
> Source code is here:
>
> https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/plug
> 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 <ao...@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 <ao...@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 <sh...@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
> <cs...@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>
RE: Cordova Plugins with Symlinks
Posted by Chuck Lantz <cl...@microsoft.com>.
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 <cl...@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 <cl...@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 <cl...@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
> > >>>> <ao...@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 <sh...@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
> > >>> <cs...@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
RE: Cordova Plugins with Symlinks
Posted by Chuck Lantz <cl...@microsoft.com>.
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 <cl...@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 <cl...@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 <cl...@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
> > >>>> <ao...@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 <sh...@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
> > >>> <cs...@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
Re: Cordova Plugins with Symlinks
Posted by Andrew Grieve <ag...@chromium.org>.
Could we fix our un-tarring logic to create symlinks on windows?
On Wed, May 6, 2015 at 2:39 PM, Chuck Lantz <cl...@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 <cl...@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 <cl...@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 <ao...@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 <sh...@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
> > >>> <cs...@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
>
>
RE: Cordova Plugins with Symlinks
Posted by Chuck Lantz <cl...@microsoft.com>.
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 <cl...@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 <cl...@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 <cs...@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 <ao...@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 <ao...@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 <sh...@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
> >>> <cs...@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
RE: Cordova Plugins with Symlinks
Posted by Josh Soref <js...@blackberry.com>.
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 <cl...@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 <cl...@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 <cs...@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 <ao...@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 <ao...@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 <sh...@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
> >>> <cs...@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
Re: Cordova Plugins with Symlinks
Posted by Shazron <sh...@gmail.com>.
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 <cl...@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 <cl...@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 <cs...@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 <ao...@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 <ao...@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 <sh...@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
>>> <cs...@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-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
RE: Cordova Plugins with Symlinks
Posted by Chuck Lantz <cl...@microsoft.com>.
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 <cl...@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 <cs...@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 <ao...@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 <ao...@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 <sh...@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
>> <cs...@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
Re: Cordova Plugins with Symlinks
Posted by Jesse <pu...@gmail.com>.
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 <cl...@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-fix
>
> 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 <cs...@gmail.com> wrote:
>>
>> Source code is here:
>>
>> https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/plug
>> 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 <ao...@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 <ao...@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 <sh...@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
>> <cs...@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