cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: engines and plugins on config.xml
Date Wed, 09 Apr 2014 18:45:59 GMT
This would be a great contribution.

We should consider using the <dependency> tag for plugins, which I think
maps well to existing specifications for urls and versions.

For platforms, I'm fine with <engine>, though I don't like tieing to
specific versions by default.  I think we should support it, but my usual
reason for project re-creation is a trivial way to upgrade everything.

Thanks for signing up!

-Michal


On Wed, Apr 9, 2014 at 12:45 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> Gorkem - if you implement this you'll be my hero!
>
> <engine> vs <platform> is a bit weird, because <platform> is already
a
> thing that exists right now that is meant to mean tags within it apply only
> to the platform is lists. E..g
> <platform name="android">
>   <preference name="foo" value="3" />
> </platform>
>
>
> On one hand, you could throw a version in there, but given that you can
> have multiple <platform> tags, it's a bit weird. I can also see the
> use-case of wanting: <platform name="android|ios">.
>
> So... wanted to point this out for consideration, but think that <engine>
> might be better because if this reason.
>
>
> I think the argument is more compelling to have plugins use <cdv:plugin>
> rather than <feature>. I think we'd only want:
> <cdv:plugin name="" version="" />
> And not have end-users need to add in the <param name="package-name"/>,
> since that's up to the plugin.xml to add in.
>
>
>
>
> On Wed, Apr 9, 2014 at 8:09 AM, Gorkem Ercan <gorkem.ercan@gmail.com>
> wrote:
>
> > I guess it could be platform as well. I put engine because that is what
> > plugin.xml uses for its dependencies.
> > --
> > Gorkem
> >
> >
> > On Wed, Apr 9, 2014 at 10:01 AM, Sebastien Blanc <scm.blanc@gmail.com
> > >wrote:
> >
> > > I had the same idea and I really love it
> > > but why not "platform" instead of "engine" ?
> > >
> > >
> > >
> > > On Wed, Apr 9, 2014 at 5:58 PM, Gorkem Ercan <gorkem.ercan@gmail.com>
> > > wrote:
> > >
> > > > Hi,
> > > > I would like to propose a couple of enhancements to the top level
> > > > config.xml that would enable us to recreate a project easily.
> > > >
> > > > (Note: the examples below assumes a cdv namespace on config.xml)
> > > >
> > > > 1. engines tag :
> > > >
> > > > <cdv:engine id="org.apache.cordova.android" version="3.5.1" />
> > > > <cdv:engine id="org.apache.cordova.ios" version="3.7.0" />
> > > >
> > > > CLI could use this tag the reconstruct the platforms hence the
> > platforms
> > > > folder would really become a build artifact. I believe phonegap and
> the
> > > > JBoss IDE is already using a similiar thing on the
> .cordova/config.json
> > > >
> > > > 2. plugins
> > > >
> > > > <feature name="Console" cdv:id="org.apache.cordova.core.console"
> > > > cdv:version="0.2.8">
> > > >            <param name="ios-package" value="ConsolePlugin" />
> > > > </feature>
> > > >
> > > > Alternately
> > > >
> > > > <feature name="Console">
> > > >      <param name="id" value="org.apache.cordova.core.console" />
> > > >     <param name="version" value="0.2.8" />
> > > >      <param name="ios-package" value="ConsolePlugin" />
> > > > </feature>
> > > >
> > > > This is reutilizing the existing feature tag. ID is the only missing
> > > piece
> > > > of information for CLI to reinstall the plugins to a project is the
> > > plugin
> > > > id and version. This would also eliminate the need to share plugins
> > > folder
> > > > with the Cordova projects. The plugins folder can still be utilized
> for
> > > > plugins that were not available from plugin registry. Also if the id
> is
> > > > missing on a feature tag CLI would skip restoring that plugin for the
> > > > project.
> > > >
> > > > On top of this I am volunteering myself to do the work. I guess it
> will
> > > > require a good amount of changes to CLI prepare.
> > > >
> > > > ---
> > > > Gorkem
> > > >
> > >
> >
>

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