cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Plugin / Platform mismatch problems
Date Tue, 30 Jul 2013 02:05:59 GMT
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 <fil@adobe.com> 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" <b@brian.io> 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 <anis.kadri@gmail.com> 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 <b@brian.io> 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 <anis.kadri@gmail.com>
> >>>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 <fil@adobe.com> 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" <anis.kadri@gmail.com> 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 <cmarcelk@gmail.com>
> >>>>>>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 <fil@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.kadri@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.
> >>>>>>>
> >>>>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message