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