cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyler Wilson <twil...@pulse-robotics.com>
Subject Re: Success with Cordova CLI and custom plugin
Date Fri, 05 Jul 2013 15:54:38 GMT
Not even a poor man would accept Windows shortcuts for symlinks. It is a whole different file
that just contains a reference back to the original. The closest thing on Windows are junction
points, which only work for directories, which doesn't help me/us.

Again, for me links are useful since I use the same plugin for multiple projects, and in each
one I may find issues I need to fix in the plugin, and I certainly do not want to have to
remove and install in all the other projects. And as was pointed out, this is only for development,
not end users - hopefully they have gotten a stable version they can code against.

Thanks,
Tyler
 
On Jul 4, 2013, at 2:10 PM, Filip Maj <fil@adobe.com> wrote:

> A poor man's symlink ;)
> 
> On 7/4/13 11:08 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
> 
>> Oh that kinda symlinks :-)
>> 
>> 
>> On Thu, Jul 4, 2013 at 2:00 PM, Filip Maj <fil@adobe.com> wrote:
>> 
>>> Windows has symlinks, the "Shortcut" stuff. See [1].
>>> 
>>> And no, --link throws if you try to use with a URL. See [2].
>>> 
>>> [1]
>>> 
>>> http://nodejs.org/docs/v0.10.0/api/fs.html#fs_fs_symlink_srcpath_dstpath_
>>> ty
>>> pe_callback
>>> [2] 
>>> https://github.com/apache/cordova-plugman/blob/master/src/fetch.js#L21
>>> 
>>> On 7/4/13 10:57 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>>> 
>>>> does --link work for URLs ?
>>>> 
>>>> Also bad idea because no symlinks on Windoz.
>>>> 
>>>> 
>>>> On Thu, Jul 4, 2013 at 1:40 PM, Michal Mocny <mmocny@chromium.org>
>>> wrote:
>>>> 
>>>>> Either way, I now think real symlinking is a bad idea.  We currently
>>>>> must
>>>>> keep a copy of the files as they existed at "fetch" time so that we
>>> can
>>>>> use
>>>>> them for upgrade/uninstall.  Symlinks break that.  Conceptually, we
>>>>> already
>>>>> have "links" in that we remember the original source locations, and
>>> we
>>>>> could improve the "prepare" step to add the ability to auto-upgrade
>>> all
>>>>> plugins.
>>>>> 
>>>>> Not sure if that is the best solution, but seems feasible.
>>>>> 
>>>>> 
>>>>> On Thu, Jul 4, 2013 at 1:27 PM, Filip Maj <fil@adobe.com> wrote:
>>>>> 
>>>>>> The --link options actually exists in plugman, but it is only an
>>>>> option
>>>>>> for the `fetch` command. All it does is copy the plugin code from
>>>>> <your
>>>>>> location or URL> to a plugins directory. With --link, instead
it
>>> will
>>>>>> symlink. It does not actually create symlinks for native or web
>>> plugin
>>>>>> code.
>>>>>> 
>>>>>> Would that even work, I wonder? For compiling, etc.
>>>>>> 
>>>>>> On 7/3/13 10:32 AM, "Michal Mocny" <mmocny@chromium.org> wrote:
>>>>>> 
>>>>>>> On Wed, Jul 3, 2013 at 1:13 PM, Tyler Wilson
>>>>>>> <twilson@pulse-robotics.com>wrote:
>>>>>>> 
>>>>>>>> Good day,
>>>>>>>> 
>>>>>>>> Just wanted to publicise that I have had success with the
cli, a
>>>>> custom
>>>>>>>> plugin and an iOS build. I must say once everything is set
up
>>> it is
>>>>>>>> pretty
>>>>>>>> nice being able to add/remove components and it appears to
>>> handle
>>>>> things
>>>>>>>> just fine. Just a couple notes:
>>>>>>>> 
>>>>>>> 
>>>>>>> Awesome!
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> - The default build created has two config.xml files in the
>>>>> project (I
>>>>>>>> am
>>>>>>>> using Xcode) - one at the root, and one within the www folder.
>>> Is
>>>>> this
>>>>>>>> expected?
>>>>>>>> 
>>>>>>> 
>>>>>>> This is expected, but not desired.  It is a result of us having
a
>>>>>>> config.xml inside your www/ folder and copying that whole folder
>>> on
>>>>>>> prepare.  For now, if you can add it to your workflow, I would
>>> remove
>>>>> the
>>>>>>> config.xml from "platforms/ios/www" after every "cordova prepare"
>>>>>>> (actually, not removing it causes a race condition that rarely
>>> but
>>>>>>> occasionally causes an app launch failure, so we will need to
>>> solve
>>>>> this
>>>>>>> issue upstream).
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> - I was having issue installing my plugin with plugman. Then
I
>>>>> realized
>>>>>>>> that the cordova cli command handles plugin installs and
>>> removal.
>>>>> It
>>>>> is
>>>>>>>> confusing with many references to plugman. Perhaps there
should
>>> be
>>>>> a
>>>>>>>> 'modern' Getting Started guide for the CLI version that also
>>>>> installs
>>>>> a
>>>>>>>> plugin as an example? I have read this one -
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>> 
>>> http://cordova.apache.org/docs/en/2.9.0/guide_cli_index.md.html#The%20Cor
>>>>>>>> dova%20Command-line%20Interface- but perhaps another matching
one
>>>>> for
>>>>>>>> plugin developers? (And put a NOTE
>>>>>>>> on this page about the issue with npm 1.3.x versionsÅ )
>>>>>>>> 
>>>>>>> 
>>>>>>> Thanks for pointing that out.
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> - I referenced this before, but I think an option to install
a
>>>>> plugin
>>>>>>>> via
>>>>>>>> symlinks would make development a lot easier, since in most
>>> cases
>>>>> you
>>>>>>>> will
>>>>>>>> be editing the copy that was created during the install,
not the
>>>>>>>> original.
>>>>>>>> I will do it manually for now of course.
>>>>>>>> 
>>>>>>> 
>>>>>>> We discussed adding a --link option to plugin add before, but
>>> since
>>>>> we
>>>>>>> need
>>>>>>> to have the original assets around in order to do proper install,
>>> I
>>>>> think
>>>>>>> the current plan was to support in-place upgrading (sorta like
>>>>> cordova
>>>>>>> prepare, but for plugins).  Fil/Braden, maybe you can add more
on
>>>>> this.
>>>>>>> 
>>>>>>> For now, (cordova plugin rm ... && cordova plugin add
...) as a
>>> form
>>>>> of
>>>>>>> in-place plugin upgrade works only for updating web assets at
the
>>>>> moment.
>>>>>>> 
>>>>>>> As far as modifying the copy -- yes, during plugin development
I
>>> do
>>>>> that
>>>>>>> too, its just a lot easier to get rapid iteration -- but after
I'm
>>>>> done
>>>>> I
>>>>>>> *do* copy those assets back out to the original location.  Also,
>>> for
>>>>>>> plugin
>>>>>>> consumers, not the original authors, they will not be making
>>> changes
>>>>> to
>>>>>>> the
>>>>>>> plugin copies.
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> Great job everybody.
>>>>>>>> 
>>>>>>>> Thank you,
>>>>>>>> Tyler
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 
> 


Mime
View raw message