Would this require that we use the node_modules dependency structure? e.g. Our dependency system works differently from node's. We don't support A depends on B-v1 and C depends on B-v2.
Would we be able to enforce our <engine cordova-version=">3.0.0"> as well as our <platform name="ios" min-sdk-version="6.0" min-os-version="5.0"> constraints? Some things will be uglier to express as json I think. E.g.: trying to embed xml snippets (like for <config-file>), that contain many " characters and newline characters. Making things harder to search for has been pointed out as a disadvantage. What would be the advantages? On Mon, Jul 29, 2013 at 9:00 PM, Filip Maj <[email protected]> wrote: > Compatibility with npm sounds great and I fully support it. > > We still need to be conscious of old plugin.xml compatibility, though > > Interesting thing there is putting plugman or cordova-cli into plugins' > package.json as dependencies, which would give you all tools you need to > do cool things like auto-installation > > On 7/29/13 4:55 PM, "Brian LeRoux" <[email protected]> wrote: > > >Ya, the Node characters in this story that I'm talking w/ are dshaw, > >mikeal, izs, and joemccann. All pushing we go this route and YES its > >super easier than it sounds. =P > > > >Agree on discovery getting a little harder but this isn't an exclusive > >move but rather an additive operation. That is to say, they want us to > >have a compatibility but in no way are saying we use the npm registry > >for our core plugins. > > > >So: package.json, install, and uninstall are the tricks to this pony. > >I think we can easily get consensus for moving to package.json using > >our current technique. I'll talk to them further about the > >install/uninstall business. > > > >The next version of Node will be shipping w/ the npm registry included > >so this is actually rather cool for us as the install would become: > >install node. > > > > > >On Mon, Jul 29, 2013 at 7:41 PM, Anis KADRI <[email protected]> wrote: > >> I spoke with @dshaw about this and told him why it was (currently) not > >> an option for Cordova. > >> > >> Specifically (un)install actions and dependency management are > >> different. It seems like a a lot of overhead to get npm to do what > >> plugman (un)install does. > >> > >> Everything else is pretty much the same and moving from plugin.xml to > >> package.json won't hurt us I don't think. I guess we wouldn't be able > >> to do XSLTs to validate documents but...other than that it would be a > >> logical move. > >> > >> The other thing too is that npm is mainly for nodejs and/or javascript > >> packages and getting Cordova plugins in there can make search and > >> discovery harder. There are currently 36,472 NPMs as of this writing. > >> The counter-argument to this is that there are npm modules that use > >> native codes to execute. Some of them even require some third-party > >> interpreters (Ruby, Python, etc...). > >> > >> On Mon, Jul 29, 2013 at 4:28 PM, Brian LeRoux <[email protected]> wrote: > >>> I have a parallel conversation rolling w/ the node guys and they're > >>> hoping to convince us to move everything to the npm registry itself. > >>> (Or at least be compatible to do so.) > >>> > >>> I think this is a worthwhile goal but it does mean: > >>> > >>> - plugin.xml gets either deprecated for package.json or we continue > >>> tool that impedance mismatch > >>> - install on the npm side needs to learn about cordova (yes issac is > >>> open to this!) > >>> > >>> Did I miss anything Anis? > >>> > >>> Thoughts [larger group]? > >>> > >>> > >>> > >>> On Mon, Jul 29, 2013 at 6:06 PM, Anis KADRI <[email protected]> > >>>wrote: > >>>> Agree. > >>>> For the last point. There is a <keywords> tag added to the spec to > >>>> facilitate search. Has to be added by plugin author. > >>>> I am going to drop the current names for the registry and republish > >>>> them with the new convention. Unless anyone has any objections. We'll > >>>> implement that prefixing right after. > >>>> > >>>> On Mon, Jul 29, 2013 at 2:55 PM, Filip Maj <[email protected]> wrote: > >>>>> I think what would work is: > >>>>> > >>>>> - use ids to uniquely identify > >>>>> - prepending org.apache.cordova.core or w/e our core plugin > >>>>>namespace is > >>>>> as a fallback attempt to match makes sense > >>>>> - finally, for discovery/searching, we should do searches vs a > >>>>>plugin's > >>>>> <description> field and do our best to enforce good descriptions on > >>>>> plugins being submitted to the apache cordova registry > >>>>> > >>>>> On 7/29/13 1:13 PM, "Anis KADRI" <[email protected]> wrote: > >>>>> > >>>>>>Right but npm registry uses JSON not XML. I think prefixing core > >>>>>>plugins when no package name is provided is a good idea. > >>>>>> > >>>>>>On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard <[email protected]> > >>>>>>wrote: > >>>>>>> That could be accomplished with XSLT. And XPath has basic query > >>>>>>>capability. James Jong and I have skills in those. > >>>>>>> > >>>>>>> On Jul 26, 2013, at 2:19 PM, Filip Maj <[email protected]> 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" <[email protected]> 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. > >>>>>>> > >>>>> > >
