Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: error (athena.apache.org: local policy)
Content-Type: text/plain; charset=iso-8859-2
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: Success with Cordova CLI and custom plugin
From: Tyler Wilson <twilson@pulse-robotics.com>
In-Reply-To: <CDFB0886.21B82%fil@adobe.com>
Date: Fri, 5 Jul 2013 11:54:38 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <70BB8200-D090-490B-B5E5-78BEA654EDC9@pulse-robotics.com>
References: <CDFB0886.21B82%fil@adobe.com>
To: dev@cordova.apache.org

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
=20
On Jul 4, 2013, at 2:10 PM, Filip Maj <fil@adobe.com> wrote:

> A poor man's symlink ;)
>=20
> On 7/4/13 11:08 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>=20
>> Oh that kinda symlinks :-)
>>=20
>>=20
>> On Thu, Jul 4, 2013 at 2:00 PM, Filip Maj <fil@adobe.com> wrote:
>>=20
>>> Windows has symlinks, the "Shortcut" stuff. See [1].
>>>=20
>>> And no, --link throws if you try to use with a URL. See [2].
>>>=20
>>> [1]
>>>=20
>>> =
http://nodejs.org/docs/v0.10.0/api/fs.html#fs_fs_symlink_srcpath_dstpath_
>>> ty
>>> pe_callback
>>> [2]=20
>>> =
https://github.com/apache/cordova-plugman/blob/master/src/fetch.js#L21
>>>=20
>>> On 7/4/13 10:57 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>>>=20
>>>> does --link work for URLs ?
>>>>=20
>>>> Also bad idea because no symlinks on Windoz.
>>>>=20
>>>>=20
>>>> On Thu, Jul 4, 2013 at 1:40 PM, Michal Mocny <mmocny@chromium.org>
>>> wrote:
>>>>=20
>>>>> 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.
>>>>>=20
>>>>> Not sure if that is the best solution, but seems feasible.
>>>>>=20
>>>>>=20
>>>>> On Thu, Jul 4, 2013 at 1:27 PM, Filip Maj <fil@adobe.com> wrote:
>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Would that even work, I wonder? For compiling, etc.
>>>>>>=20
>>>>>> On 7/3/13 10:32 AM, "Michal Mocny" <mmocny@chromium.org> wrote:
>>>>>>=20
>>>>>>> On Wed, Jul 3, 2013 at 1:13 PM, Tyler Wilson
>>>>>>> <twilson@pulse-robotics.com>wrote:
>>>>>>>=20
>>>>>>>> Good day,
>>>>>>>>=20
>>>>>>>> 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:
>>>>>>>>=20
>>>>>>>=20
>>>>>>> Awesome!
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> - 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?
>>>>>>>>=20
>>>>>>>=20
>>>>>>> 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).
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> - 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 -
>>>>>>>>=20
>>>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>>=20
>>>=20
>>> =
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=A9)
>>>>>>>>=20
>>>>>>>=20
>>>>>>> Thanks for pointing that out.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> - 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.
>>>>>>>>=20
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> Great job everybody.
>>>>>>>>=20
>>>>>>>> Thank you,
>>>>>>>> Tyler
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>=20
>>>=20
>=20