cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Plugin / Platform mismatch problems
Date Fri, 26 Jul 2013 18:19:09 GMT
Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml
fields to json fields?

On 7/26/13 10:27 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:

>I think XML is not a query friendly language. I suggest we add an
>engine field initially and then add fields as we need them. I suspect
>we won't be needing the bulk of plugin.xml in the registry. I have to
>experiment with custom fields still but it seems possible. I will
>report back sometime today.
>
>On Fri, Jul 26, 2013 at 9:23 AM, Filip Maj <fil@adobe.com> wrote:
>> I think this was brought up before, but why not store the plugin xml in
>> its entirety? I can us needing more bits down the road, such as
>> dependencies and platform version requirements.
>>
>>
>> On 7/26/13 7:32 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:
>>
>>>That all sounds good, but let's talk more about the git ref part:
>>>
>>>It looks like our npm-based directory system is going to host the .tgz
>>>of
>>>the plugins, so it won't matter what git ref the .tgz maps back to
>>>unless
>>>we think that a lot of people are not going to use our directory
>>>service.
>>>
>>>One thing that would be useful though, is a way to list plugins
>>>compatible
>>>with your version of cordova (e.g. query for the latest version of
>>>cordova-plugin-file that is compatible with 3.0.0). I think all that's
>>>required here is to store the engine tag in the couchdb metadata
>>>alongside
>>>the tgz.
>>>
>>>
>>>On Thu, Jul 25, 2013 at 6:38 PM, Benn Mapes <benn.mapes@gmail.com>
>>>wrote:
>>>
>>>> +1 to brett's comments.
>>>> Name - Human Readable name of the plugin to be used in the context of
>>>>  plugin
>>>> discovery.
>>>> ID - unique id used by tools to reference the plugin
>>>> Description - sentence+ about the plugin (optional?)
>>>>
>>>> As for how plugins should be loaded I liked Braden's suggestion that
>>>>plugin
>>>> authors decide what the default ref is for their plugin. Default
>>>>should
>>>>be
>>>> master if no ref is provided.
>>>>
>>>>
>>>> On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill <stevengill97@gmail.com>
>>>> wrote:
>>>>
>>>> > I am going to hold off on testing + deploying+ merging this back in
>>>>until
>>>> > we get some sort of consensus on naming
>>>> >
>>>> >
>>>> > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett <brettrudd@gmail.com>
>>>> wrote:
>>>> >
>>>> > > name is human readable and should be retained for plugin discovery
>>>> tools
>>>> > > etc. (such as build.phonegap.com)
>>>> > >
>>>> > > in the wild, i find description is anything from a sentence to
a
>>>>small
>>>> > > paragraph, so a smaller human readable field as a name is
>>>>valuable.
>>>> > >
>>>> > > as for using id instead of name for plugman, i transfer my voting
>>>>power
>>>> > to
>>>> > > anis.
>>>> > >
>>>> > > -brett
>>>> > >
>>>> > > On 25 Jul 2013, at 11:59, Shazron <shazron@gmail.com> wrote:
>>>> > >
>>>> > > > Maybe "name" is the "human" readable name as opposed to id
which
>>>>is
>>>> for
>>>> > > > tools
>>>> > > >
>>>> > > >
>>>> > > > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve <
>>>> agrieve@chromium.org
>>>> > > >wrote:
>>>> > > >
>>>> > > >> Anis - can we make it use id instead? I think that's more
>>>>inline
>>>> with
>>>> > > the
>>>> > > >> purpose of the field.
>>>> > > >>
>>>> > > >> Maybe we should remove the name field? I can't think of
a
>>>>meaningful
>>>> > > >> distinction between name and id given that we already
have a
>>>> > description
>>>> > > >> field.
>>>> > > >>
>>>> > > >>
>>>> > > >> On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill <
>>>> stevengill97@gmail.com>
>>>> > > >> wrote:
>>>> > > >>
>>>> > > >>> Thanks for the advice Shaz and Andrew.
>>>> > > >>>
>>>> > > >>> I will make sure to mention the issue in the commit
so the bot
>>>> picks
>>>> > it
>>>> > > >> up.
>>>> > > >>>
>>>> > > >>> Just talked to Anis and he says it is the name tag
and not the
>>>>ID.
>>>> I
>>>> > > >> could
>>>> > > >>> go and rename all of the core plugins to start with
'core-' if
>>>>that
>>>> > > makes
>>>> > > >>> more sense to people. I like it. Distinguishes core
plugins
>>>>from
>>>> > > >> community
>>>> > > >>> ones.
>>>> > > >>>
>>>> > > >>> I will make sure to do a release bug once ready. Mobile-spec
>>>>tests
>>>> > for
>>>> > > >> sure
>>>> > > >>> and I will upload to registry (gotta do it eventually
:P)
>>>> > > >>>
>>>> > > >>> -Steve
>>>> > > >>>
>>>> > > >>>
>>>> > > >>>
>>>> > > >>>
>>>> > > >>> On Thu, Jul 25, 2013 at 6:21 AM, Andrew Grieve <
>>>> agrieve@chromium.org
>>>> > >
>>>> > > >>> wrote:
>>>> > > >>>
>>>> > > >>>> Steve - If you mention the CB-XXXX in the commit
description
>>>>then
>>>> a
>>>> > > bot
>>>> > > >>>> will automatically add a comment to the issue
with the commit
>>>> link.
>>>> > > The
>>>> > > >>>> issues aren't very useful if they don't point
to the commits
>>>>that
>>>> > fix
>>>> > > >>> them.
>>>> > > >>>>
>>>> > > >>>> For the names - just wanted to verify whether
it was the name
>>>> field
>>>> > or
>>>> > > >>> the
>>>> > > >>>> id field that can't have caps/spaces? If it's
the name, then
>>>>ID
>>>> > seems
>>>> > > a
>>>> > > >>> bit
>>>> > > >>>> redundant. Either way - I think it's important
to have some
>>>>sort
>>>> of
>>>> > > >>> common
>>>> > > >>>> prefix for cordova-core plugins. E.g. core-vibration,
or
>>>> > > >>>> org.apache.cordova.vibration.
>>>> > > >>>>
>>>> > > >>>> I think any merge into master is worthy of a release
bug.
>>>>That
>>>>way
>>>> > you
>>>> > > >>> can
>>>> > > >>>> link it with the commit that bumps the package.json
version.
>>>> > Probably
>>>> > > >> one
>>>> > > >>>> bug for all the plugins being released is fine
though. In the
>>>> > release
>>>> > > >>> bug,
>>>> > > >>>> I think you should state what you tested, mobile-spec
is the
>>>>goto,
>>>> > but
>>>> > > >> in
>>>> > > >>>> this case, you may want to say that you tested
uploading to
>>>>the
>>>> > > plugins
>>>> > > >>>> registry.
>>>> > > >>>>
>>>> > > >>>>
>>>> > > >>>> On Wed, Jul 24, 2013 at 6:26 PM, Shazron <shazron@gmail.com>
>>>> wrote:
>>>> > > >>>>
>>>> > > >>>>> plugin.xml changes only correct? IMO bump
the version and
>>>>run
>>>>the
>>>> > > >> steps
>>>> > > >>>>> here to test plugin add:
>>>> > > >>> http://wiki.apache.org/cordova/WorkingWithThree
>>>> > > >>>>>
>>>> > > >>>>>
>>>> > > >>>>>
>>>> > > >>>>>
>>>> > > >>>>> On Wed, Jul 24, 2013 at 3:03 PM, Steven Gill
<
>>>> > stevengill97@gmail.com
>>>> > > >>>
>>>> > > >>>>> wrote:
>>>> > > >>>>>
>>>> > > >>>>>> So I just added a dev branch for all of
the plugins and
>>>>finished
>>>> > > >> the
>>>> > > >>>>> issues
>>>> > > >>>>>> [1] [2] [3]. All three of these were minor
fixes and I
>>>>don't
>>>> > > >> believe
>>>> > > >>>>>> require retesting all of the plugins on
every platform.
>>>>What
>>>> > should
>>>> > > >>> my
>>>> > > >>>>> next
>>>> > > >>>>>> steps be? I know if I merge into master,
I should bump the
>>>> version
>>>> > > >>> for
>>>> > > >>>>> all
>>>> > > >>>>>> of them to 0.1.1. Is this something I
should create a
>>>>release
>>>> bug
>>>> > > >> for
>>>> > > >>>> and
>>>> > > >>>>>> get tested before merging into master?
>>>> > > >>>>>>
>>>> > > >>>>>>
>>>> > > >>>>>> [1] https://issues.apache.org/jira/browse/CB-4371
>>>> > > >>>>>> [2] https://issues.apache.org/jira/browse/CB-4370
>>>> > > >>>>>> [3] https://issues.apache.org/jira/browse/CB-4338
>>>> > > >>>>>>
>>>> > > >>>>>>
>>>> > > >>>>>> On Mon, Jul 22, 2013 at 12:41 PM, Brian
LeRoux <b@brian.io>
>>>> > wrote:
>>>> > > >>>>>>
>>>> > > >>>>>>> Like that
>>>> > > >>>>>>>
>>>> > > >>>>>>> On Mon, Jul 22, 2013 at 3:33 PM, Andrew
Grieve <
>>>> > > >>> agrieve@chromium.org
>>>> > > >>>>>
>>>> > > >>>>>>> wrote:
>>>> > > >>>>>>>> Oh! Oh! Perhaps have multiple
definitions based on CDV
>>>> version.
>>>> > > >>>> e.g.:
>>>> > > >>>>>>>>
>>>> > > >>>>>>>> <engine min-cdv-version="2.8"
max-cdv-version="2.8">
>>>> > > >>>>>>>>  <default-git-ref>refs/head/2.8.x</default-git-ref>
>>>> > > >>>>>>>> </engine>
>>>> > > >>>>>>>> <engine min-cdv-version="2.9">
>>>> > > >>>>>>>>  <default-git-ref>refs/tags/stable</default-git-ref>
>>>> > > >>>>>>>> </engine>
>>>> > > >>>>>>>>
>>>> > > >>>>>>>>
>>>> > > >>>>>>>> Then, when someone plugman installs
the git URL, it can
>>>>fetch
>>>> > > >> it
>>>> > > >>>> and
>>>> > > >>>>>>>> checkout a version that best matches
your cordova
>>>>version.
>>>> > > >>>>>>>> Then, when you update your cordova
version, it can go
>>>>through
>>>> > > >>> your
>>>> > > >>>>>>> plugins
>>>> > > >>>>>>>> and update them to different branches
(unless you glue
>>>>them to
>>>> > > >> a
>>>> > > >>>> ref
>>>> > > >>>>>> as a
>>>> > > >>>>>>>> part of your install URL)
>>>> > > >>>>>>>>
>>>> > > >>>>>>>>
>>>> > > >>>>>>>>
>>>> > > >>>>>>>> On Mon, Jul 22, 2013 at 2:44 PM,
Braden Shepherdson <
>>>> > > >>>>>> braden@chromium.org
>>>> > > >>>>>>>> wrote:
>>>> > > >>>>>>>>
>>>> > > >>>>>>>>> The model I had always imagined
was that we would do
>>>> something
>>>> > > >>>>> similar
>>>> > > >>>>>>> to
>>>> > > >>>>>>>>> npm: Plugin authors decide
what the default ref is for
>>>>their
>>>> > > >>>> plugin.
>>>> > > >>>>>>> Could
>>>> > > >>>>>>>>> be master, some other branch,
a tag, a hash. That's what
>>>>the
>>>> > > >>>>> discovery
>>>> > > >>>>>>> tool
>>>> > > >>>>>>>>> will return when a user asks
to add that plugin without
>>>> > > >>> explicitly
>>>> > > >>>>>>>>> specifying a version. I think
this is a good idea we
>>>>should
>>>> > > >>>>> implement
>>>> > > >>>>>>> too.
>>>> > > >>>>>>>>>
>>>> > > >>>>>>>>> Braden
>>>> > > >>>>>>>>>
>>>> > > >>>>>>>>>
>>>> > > >>>>>>>>> On Fri, Jul 19, 2013 at 10:16
AM, Andrew Grieve <
>>>> > > >>>>> agrieve@chromium.org
>>>> > > >>>>>>>>>> wrote:
>>>> > > >>>>>>>>>
>>>> > > >>>>>>>>>> I think it's true that:
>>>> > > >>>>>>>>>>
>>>> > > >>>>>>>>>> 1. CLI downloads tagged
versions of platforms
>>>> > > >>>>>>>>>> 2. Plugman downloads plugins
from "master" branch
>>>> > > >>>>>>>>>>
>>>> > > >>>>>>>>>> This means that we can't
check any code into plugin
>>>>master
>>>> > > >>>>> branches
>>>> > > >>>>>>>>> without
>>>> > > >>>>>>>>>> them going live immediately.
>>>> > > >>>>>>>>>>
>>>> > > >>>>>>>>>> Best solution would be
to change plugman to download
>>>>from a
>>>> > > >>> tag
>>>> > > >>>> by
>>>> > > >>>>>>>>> default,
>>>> > > >>>>>>>>>> but a bit late for that
now...
>>>> > > >>>>>>>>>>
>>>> > > >>>>>>>>>> Instead, I think we should
change all development on
>>>> > > >> plugins:
>>>> > > >>>>>>>>>> - Commit only to "dev"
branch.
>>>> > > >>>>>>>>>> - When we want to push
an update, we should file a
>>>>release
>>>> > > >> bug
>>>> > > >>>> for
>>>> > > >>>>>> the
>>>> > > >>>>>>>>>> plugin, test on all platforms
>>>> > > >>>>>>>>>> Case 1: The changes work
with 3.0 cordova: then merge
>>>>into
>>>> > > >>>> master
>>>> > > >>>>>>> (only
>>>> > > >>>>>>>>> if
>>>> > > >>>>>>>>>> it works of course)
>>>> > > >>>>>>>>>> Case 2: The changes require
a platform API that hasn't
>>>>been
>>>> > > >>>>> release
>>>> > > >>>>>>> yet:
>>>> > > >>>>>>>>>> Wait and release after
the next cordova core release.
>>>> > > >>>>>>>>>>
>>>> > > >>>>>>>>>>
>>>> > > >>>>>>>>>> Any other ideas?
>>>> > > >>>>>>>>>>
>>>> > > >>>>>>>>>
>>>> > > >>>>>>>
>>>> > > >>>>>>
>>>> > > >>>>>
>>>> > > >>>>
>>>> > > >>>
>>>> > > >>
>>>> > >
>>>> > >
>>>> >
>>>>
>>


Mime
View raw message