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 <agri...@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 <f...@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.ka...@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 <f...@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.ka...@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 <f...@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" <agri...@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.ma...@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 >> >>>>>><stevengil...@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 >> >>>>>><brettr...@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 <shaz...@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 < >> >>>>>> agri...@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 < >> >>>>>> stevengil...@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 < >> >>>>>> agri...@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 >> >>>>>><shaz...@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 < >> >>>>>> > stevengil...@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 < >> >>>>>> > > >>> agri...@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 < >> >>>>>> > > >>>>>> bra...@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 < >> >>>>>> > > >>>>> agri...@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? >> >>>>>> > > >>>>>>>>>> >> >>>>>> > > >>>>>>>>> >> >>>>>> > > >>>>>>> >> >>>>>> > > >>>>>> >> >>>>>> > > >>>>> >> >>>>>> > > >>>> >> >>>>>> > > >>> >> >>>>>> > > >> >> >>>>>> > > >> >>>>>> > > >> >>>>>> > >> >>>>>> >> >>>> >> >> >> >>
