cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Plugin / Platform mismatch problems
Date Mon, 29 Jul 2013 19:29:17 GMT
That is not a bad idea. We would just need to update the uninstall
action to support that "prefix" as well. I like the use of id for its
uniqueness, it's just not as user-friendly as just typing a name.

On Mon, Jul 29, 2013 at 12:10 PM, Andrew Grieve <agrieve@chromium.org> wrote:
> Great summary Fil.
>
> Sounds to me like what we should do is use the id for the npm "name".
> For the lazy, we could special-case core plugins, so that if you leave off
> the fqn, plugman will prepend "org.apache.cordova.core".
>
>
> On Mon, Jul 29, 2013 at 3:02 PM, Filip Maj <fil@adobe.com> wrote:
>
>> I'll try to summarize where we were before and where we are at currently.
>>
>> In The Beginning:
>> - we spec'ed an `id` attribute to the plugin manifest under the pretense
>> of having a unique identifier (generally a good idea), and a preemptive
>> approach at easing a situation where we have a multi-registry universe
>> (For example: BlackBerry, Apache, Google all hosting plugin registries)
>> - the <name> element was to be a human-readable, "pretty" label. It can
>> have spaces, apostrophes, etc. just like the <name> element in config.xml
>>
>> In The Present:
>> - we are at the point where we are using an existing system (npm) that has
>> different constraints on uniquely identifying a project. Npm uses a name,
>> with no spaces, no underscores, and some other char constraints.
>> - which leads us to our current conundrum: which field do we use to
>> uniquely identify a plugin, and which solution should we employ to map
>> between our plugin specification for naming / id'ing packages vs. Npm's.
>>
>> There are many different ways to solve this problem, each with varying
>> degrees of difficulty to implement and each having a different answer to
>> the question of "how much will we need to diverge from npm to support it":
>>
>> - using a plugin id as the npm "name"
>> - using a plugin's "cleaned up" <name> contents (no spaces or funny
>> characters) as the npm name
>>
>> Finally, discovery is the last use case that needs to be addressed here.
>> What is npm's current strategy and what do we want to support?
>>
>> On 7/26/13 11:21 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>>
>> >Exactly! Only the ones we need too! We're already doing this for
>> >name/version/description so it would just be a few more.
>> >
>> >On Fri, Jul 26, 2013 at 11:19 AM, Filip Maj <fil@adobe.com> wrote:
>> >> 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