You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Gorkem Ercan <go...@gmail.com> on 2014/04/09 17:58:10 UTC

engines and plugins on config.xml

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

Re: engines and plugins on config.xml

Posted by Michal Mocny <mm...@chromium.org>.
(we should also support --searchpath for cordova create)


On Wed, Apr 9, 2014 at 2:45 PM, Michal Mocny <mm...@chromium.org> wrote:

> 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 <ag...@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 <go...@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 <go...@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
>> > > >
>> > >
>> >
>>
>
>

Re: engines and plugins on config.xml

Posted by Gorkem Ercan <go...@gmail.com>.
Just opened [1] for restoring the plugins. There is also a PR attached to
the Jira. I would appreciate if someone could take a look. I also have
minor changes to plugman that will follow.

If you would like a sneak preview of the feature
https://www.youtube.com/watch?v=bc60WAQdOjE

[1] https://issues.apache.org/jira/browse/CB-6469

--
Gorkem


On Wed, Apr 9, 2014 at 2:25 PM, Gorkem Ercan <go...@gmail.com> wrote:

>
> Agreed, I was thinking about making the version attribute optional which
> would basically signal CLI to create platforms with the latest&greatest
> platforms releases.
> --
> Gorkem
>
>
> On Wed, Apr 9, 2014 at 12:45 PM, Michal Mocny <mm...@chromium.org> wrote:
>
>> 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 <ag...@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 <go...@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
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: engines and plugins on config.xml

Posted by Gorkem Ercan <go...@gmail.com>.
Agreed, I was thinking about making the version attribute optional which
would basically signal CLI to create platforms with the latest&greatest
platforms releases.
--
Gorkem


On Wed, Apr 9, 2014 at 12:45 PM, Michal Mocny <mm...@chromium.org> wrote:

> 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 <ag...@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 <go...@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
> > > > >
> > > >
> > >
> >
>

Re: engines and plugins on config.xml

Posted by Michal Mocny <mm...@chromium.org>.
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 <ag...@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 <go...@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 <go...@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
> > > >
> > >
> >
>

Re: engines and plugins on config.xml

Posted by Andrew Grieve <ag...@chromium.org>.
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 <go...@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 <go...@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
> > >
> >
>

Re: engines and plugins on config.xml

Posted by Gorkem Ercan <go...@gmail.com>.
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 <sc...@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 <go...@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
> >
>

Re: engines and plugins on config.xml

Posted by Sebastien Blanc <sc...@gmail.com>.
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 <go...@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
>