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