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? > >>>>>> > > >>>>>>>>>> > >>>>>> > > >>>>>>>>> > >>>>>> > > >>>>>>> > >>>>>> > > >>>>>> > >>>>>> > > >>>>> > >>>>>> > > >>>> > >>>>>> > > >>> > >>>>>> > > >> > >>>>>> > > > >>>>>> > > > >>>>>> > > >>>>>> > >>>> > >> > >
