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