I would like to resolve this issue
On 8/1/13, Shazron wrote:
> Filed: https://issues.apache.org/jira/browse/CB-4477
>
>
> On Wed, Jul 31, 2013 at 10:48 AM, Anis KADRI wrote:
>
>> I feel like we shouldn't. More source of errors than anything I think.
>> Also human readable names are useless when
Filed: https://issues.apache.org/jira/browse/CB-4477
On Wed, Jul 31, 2013 at 10:48 AM, Anis KADRI wrote:
> I feel like we shouldn't. More source of errors than anything I think.
> Also human readable names are useless when presented in search results
> because one can't install using a human re
I feel like we shouldn't. More source of errors than anything I think.
Also human readable names are useless when presented in search results
because one can't install using a human readable name.
Shaz, I think we do need to add a doc issue.
On Wed, Jul 31, 2013 at 10:30 AM, Andrew Grieve wrote:
I don't feel strongly one way or the other about prefixing.
On Tue, Jul 30, 2013 at 6:49 PM, Shazron wrote:
> Do we need to add a doc issue for updating this in 3.1:
> 1.
>
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_plugman.md.html#Using%20Plugman%20to%20Manage%20Plugins
> 2.
>
> http
Do we need to add a doc issue for updating this in 3.1:
1.
http://cordova.apache.org/docs/en/3.0.0/plugin_ref_plugman.md.html#Using%20Plugman%20to%20Manage%20Plugins
2.
http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html#The%20Command-line%20Interface
(the docs will still work of cours
In the meantimeI renamed all plugins to package names in the
cordova registry. I've also updated plugman
So anyone should be able to `cordova plugin add
org.apache.cordova.core.device` or `plugman install --platform
platform --plugin org.apache.cordova.core.device --project
/path/to/project` a
Oh, yes, it could also be made to install from the npm registry. It
does neither of those things yet.
On Tue, Jul 30, 2013 at 9:43 AM, Andrew Grieve wrote:
> A federated system just means that anyone can host a directory of plugins,
> yes? Anis was saying that plugman could be easily made to poin
A federated system just means that anyone can host a directory of plugins,
yes? Anis was saying that plugman could be easily made to point at any
couchdb instance. Is that not federated?
On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux wrote:
> No, at least I don't think so. The install/uninstall
No, at least I don't think so. The install/uninstall are more clobbers
and plugin.xml is not a thing npm has any desire to become aware of.
On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve wrote:
> On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux wrote:
>
>> > Would this require that we use the nod
On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux wrote:
> > Would this require that we use the node_modules dependency structure?
>
> No. We would teach npm install about our structure.
>
>
> > Would we be able to enforce our as well
> > as our
> > constraints?
>
> Yes.
>
>
> > Some things will b
> Would this require that we use the node_modules dependency structure?
No. We would teach npm install about our structure.
> Would we be able to enforce our as well
> as our
> constraints?
Yes.
> Some things will be uglier to express as json I think. E.g.: trying to
> embed xml snippets (l
Would this require that we use the node_modules dependency structure?
e.g. Our dependency system works differently from node's. We don't support
A depends on B-v1 and C depends on B-v2.
Would we be able to enforce our as well
as our
constraints?
Some things will be uglier to express as json I t
Compatibility with npm sounds great and I fully support it.
We still need to be conscious of old plugin.xml compatibility, though
Interesting thing there is putting plugman or cordova-cli into plugins'
package.json as dependencies, which would give you all tools you need to
do cool things like au
Ya, the Node characters in this story that I'm talking w/ are dshaw,
mikeal, izs, and joemccann. All pushing we go this route and YES its
super easier than it sounds. =P
Agree on discovery getting a little harder but this isn't an exclusive
move but rather an additive operation. That is to say, th
I spoke with @dshaw about this and told him why it was (currently) not
an option for Cordova.
Specifically (un)install actions and dependency management are
different. It seems like a a lot of overhead to get npm to do what
plugman (un)install does.
Everything else is pretty much the same and mov
I have a parallel conversation rolling w/ the node guys and they're
hoping to convince us to move everything to the npm registry itself.
(Or at least be compatible to do so.)
I think this is a worthwhile goal but it does mean:
- plugin.xml gets either deprecated for package.json or we continue
to
Agree.
For the last point. There is a tag added to the spec to
facilitate search. Has to be added by plugin author.
I am going to drop the current names for the registry and republish
them with the new convention. Unless anyone has any objections. We'll
implement that prefixing right after.
On Mo
I think what would work is:
- use ids to uniquely identify
- prepending org.apache.cordova.core or w/e our core plugin namespace is
as a fallback attempt to match makes sense
- finally, for discovery/searching, we should do searches vs a plugin's
field and do our best to enforce good descriptions
Right but npm registry uses JSON not XML. I think prefixing core
plugins when no package name is provided is a good idea.
On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard wrote:
> That could be accomplished with XSLT. And XPath has basic query capability.
> James Jong and I have skills in those.
>
That could be accomplished with XSLT. And XPath has basic query capability.
James Jong and I have skills in those.
On Jul 26, 2013, at 2:19 PM, Filip Maj 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 KAD
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 wrote:
> Great summary Fil.
>
> Sounds to me l
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 wrote:
> I'll try to summarize
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
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 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,
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" 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 t
Yeah we can use id and keep name around for human readable purpose.
I am fine with it. I just think that typing giant package names is
just not user friendly from a developer's perspective. Maybe it's just
me.
On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill wrote:
> I am going to hold off on testin
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.
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" wrote:
>That all sounds good, but let's talk more about the git ref part:
>
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
+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
aut
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 wrote:
> name is human readable and should be retained for plugin discovery tools
> etc. (such as build.phonegap.com)
>
> in the wild,
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 tr
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 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 m
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 wrote
Should probably tie into plugman as well, to not refer to plugins via
their id?
Does this make the id useless? Or does it provide value in a
multi-plugin-registry reality?
On 7/25/13 11:35 AM, "Steven Gill" wrote:
>Thanks for the advice Shaz and Andrew.
>
>I will make sure to mention the issue
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.
Steve - If you mention the CB- 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
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 wrote:
> So I just added a dev branch for all of the plugins and finished the issues
> [1] [2] [3]. All
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
Like that
On Mon, Jul 22, 2013 at 3:33 PM, Andrew Grieve wrote:
> Oh! Oh! Perhaps have multiple definitions based on CDV version. e.g.:
>
>
> refs/head/2.8.x
>
>
> refs/tags/stable
>
>
>
> Then, when someone plugman installs the git URL, it can fetch it and
> checkout a version that best
Oh! Oh! Perhaps have multiple definitions based on CDV version. e.g.:
refs/head/2.8.x
refs/tags/stable
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 thr
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
specify
Yeah this entire bit needs a lot of love for sure.
I think Anis' registry work should solve the big current issues here.
In the mean time your proposal sounds fine to me. Only thing I would add
is to increment the version attribute in the plugin.xml every time a merge
back into master happens (so
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 defa
44 matches
Mail list logo
