cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ally Ogilvie <aogil...@wizcorp.jp>
Subject Re: Cordova Plugin Registry iOS frameworks
Date Thu, 04 Sep 2014 02:37:24 GMT
I tried to find plugman source code responsible for npm publish but failed.

I'm gonna bump this for someone to assign too.. any takers? <3



On Wed, Aug 20, 2014 at 12:12 PM, Ally Ogilvie <aogilvie@wizcorp.jp> wrote:

> >Ally, do you know if the symlinks are required for the FacebookConnect
> framework?
>
> @Ian Absolutely required. Not just for Facebook, but all .framework files.
>
> MyFramework.framework     // (directory)
>   info.plist
>   MyFramework             // (symbolic link to
> Versions/Current/MyFramework)
>   Resources               // (symbolic link to Versions/Current/Resources)
>   Headers                 // (symbolic link to Versions/Current/Headers)
>   Versions                // (directory)
>     Current               // (symbolic link to directory "A" below)
>     A                     // (directory)
>       Headers             // (directory containing framework headers)
>       Resources           // (directory holding framework resources)
>       MyFramework         // (actual compiled library, really a .a file)
>
> As you can see there are 4 symbolic links in .frameworks.
>
>
>
>
> On Tue, Aug 19, 2014 at 5:59 AM, Shazron <shazron@gmail.com> wrote:
>
>> I think the right approach is what Andrew suggested. So the current
>> workaround is to tarball it first then publish?
>>
>> On Mon, Aug 18, 2014 at 12:04 PM, Andrew Grieve <agrieve@chromium.org>
>> wrote:
>> > Tarballs support symlinks.
>> > npm uses tarballs.
>> > "npm publish" lets you give a path to a tarball rather than having it
>> pack
>> > it for you.
>> >
>> > So, I think we probably could fix this in plugman by having it create
>> the
>> > tgz more intelligently.
>> >
>> >
>> > On Mon, Aug 18, 2014 at 2:24 PM, Ian Clelland <iclelland@chromium.org>
>> > wrote:
>> >
>> >> On Mon, Aug 18, 2014 at 12:40 PM, Brian LeRoux <b@brian.io> wrote:
>> >>
>> >> > I like the idea of not supporting them until I hear a really great
>> reason
>> >> > to support them. =)
>> >> >
>> >>
>> >> Certainly; YAGNI and all that.
>> >>
>> >> Ally, do you know if the symlinks are required for the FacebookConnect
>> >> framework? Is it possible to just git mv the files to the location that
>> >> Xcode expects to find them, and not have to worry about this issue in
>> >> plugman?
>> >>
>> >> Ian
>> >>
>> >>
>> >>
>> >> >
>> >> >
>> >> > On Mon, Aug 18, 2014 at 9:31 AM, Ian Clelland <
>> iclelland@chromium.org>
>> >> > wrote:
>> >> >
>> >> > > We could have some sort of preprocessing step on the current
>> directory,
>> >> > > that would prepare it for publishing.
>> >> > >
>> >> > > Maybe we can either annotate the directory with where the symlinks
>> >> should
>> >> > > go, or else copy the files, if it's okay to do that.
>> >> > >
>> >> > > On Monday, August 18, 2014, Mark Koudritsky <kamrik@google.com>
>> wrote:
>> >> > >
>> >> > > > Plugins are published using "npm publish". As far as I
>> understood,
>> >> npm
>> >> > > does
>> >> > > > not include symlinks by design [1] when packing a package.
So
>> I'm not
>> >> > > sure
>> >> > > > about how we could start including symlinks while still using
npm
>> >> > > packages
>> >> > > > as distribution method.
>> >> > > > [1] https://github.com/npm/npm/issues/3310
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > On Mon, Aug 18, 2014 at 9:02 AM, Ian Clelland <
>> >> iclelland@chromium.org
>> >> > > > <javascript:;>>
>> >> > > > wrote:
>> >> > > >
>> >> > > > > I saw this come up on Friday on IRC -- I didn't see
you in the
>> >> > channel,
>> >> > > > > Ally, or I would have pinged you.
>> >> > > > >
>> >> > > > > It's definitely an issue with plugman, either with the
>> packaging or
>> >> > the
>> >> > > > > extraction, when there are symlinks present in the repo.
>> >> > > > >
>> >> > > > > I upgraded the severity of the CB-6092 to critical;
we need to
>> >> find a
>> >> > > > > solution for this.
>> >> > > > >
>> >> > > > >
>> >> > > > > On Mon, Aug 18, 2014 at 3:06 AM, Ally Ogilvie <
>> aogilvie@wizcorp.jp
>> >> > > > <javascript:;>> wrote:
>> >> > > > >
>> >> > > > > > https://issues.apache.org/jira/browse/CB-6092
>> >> > > > > >
>> >> > > > > > Symlinks are broken when doing *cordova plugin
add* <cordova
>> >> plugin
>> >> > > > > > registry ID>. For example if a plugin makes
use of the custom
>> >> > > framework
>> >> > > > > > tag:
>> >> > > > > >
>> >> > > > > > *<framework** src="platforms/ios/FacebookSDK.framework"
>> >> > custom="true"
>> >> > > > />*
>> >> > > > > >
>> >> > > > > > I think this is because of the way the registry
plugins are
>> being
>> >> > > > served
>> >> > > > > to
>> >> > > > > > plugman.
>> >> > > > > > I wanted a discussion here as this is *critical*
for plugins
>> >> using
>> >> > > > custom
>> >> > > > > > framework tags.
>> >> > > > > >
>> >> > > > > > *Desperately* need someone from Plugman / Registry
team to
>> give
>> >> > some
>> >> > > > info
>> >> > > > > > on what's going on for the community to patch it.
>> >> > > > > >
>> >> > > > > > Here's what the symlinks for .frameworks look like
after
>> plugin
>> >> add
>> >> > > > from
>> >> > > > > > CPR
>> >> > > > > > http://stackoverflow.com/a/25327341
>> >> > > > > >
>> >> > > > > > Windows boxes / Git clone and symlinks info:
>> >> > > > > > http://stackoverflow.com/a/11664406
>> >> > > > > >
>> >> > > > > > --
>> >> > > > > > <http://www.wizcorp.jp/>Ally Ogilvie
>> >> > > > > > Lead Developer - MobDev. | Wizcorp Inc. <
>> http://www.wizcorp.jp/>
>> >> > > > > > ------------------------------
>> >> > > > > > TECH . GAMING . OPEN-SOURCE WIZARDS+ 81 (0)3-4550-1448
|
>> Website
>> >> > > > > > <http://www.wizcorp.jp/> | Twitter <
>> https://twitter.com/Wizcorp>
>> >> |
>> >> > > > > > Facebook
>> >> > > > > > <http://www.facebook.com/Wizcorp> | LinkedIn
>> >> > > > > > <http://www.linkedin.com/company/wizcorp>
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
>

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