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/01/13 20:33:42 UTC
Engines and plugins
JBoss Tools have recently added the capability to switch between
Cordova engines. See [1] for details. While implementing checks for
plug-in compatibility I found the engine definitions on the plug-in specification to
be more complex than needed to be.
I think there are too many "default engines" defined.
for instance
<engine name="cordova-android" version=">=1.8.0" />
is essentially the same as
<engine name="cordova" version=">=1.8.0" platform="android" />
Could someone remind the reason for having platform specific default engine names? If
they exist for a historic reason can we remove it from the documentation
and guide people to use the platform attribute? I can provide a doc patch for this purpose.
I think this is making the implementation on plugman more complex also.
And specifying custom Apache Cordova-based frameworks is a different
beast altogether. It actually gives the responsibility to integrate a
custom engine with plugman to the plug-ins with the scriptSrc attribute.
I do not think this will scale considering that the engine and plug-in
ideally have a different life cycle. I think plugman should actually
provide a way for custom engines to provide this information.
I guess there is some merit to engines such as "apple-xcode" but I have
yet not been able to find a plug-in that uses those. I must also admit
the use of engine definitions is also very limited.
[1] http://www.gorkem-ercan.com/2014/01/multiple-cordova-engines-on-jboss.html
Re: Engines and plugins
Posted by Andrew Grieve <ag...@chromium.org>.
+Tim Kim
On Mon, Jan 13, 2014 at 9:36 PM, Andrew Grieve <ag...@chromium.org> wrote:
> On Mon, Jan 13, 2014 at 6:14 PM, Gorkem Ercan <go...@gmail.com> wrote:
>> On Mon, Jan 13, 2014 at 04:32:20PM -0500, Andrew Grieve wrote:
>>> FYI to others - the docs for this is found here (seems to have some
>>> incorrectly formatted markdown too :( ) :
>>> http://cordova.apache.org/docs/en/3.3.0/plugin_ref_spec.md.html#Plugin%20Specification
>>>
>>> My understanding was that:
>>> <engine name="cordova-android" version=">=1.8.0" />
>>> is the same as:
>>> <engine name="cordova-android" version=">=1.8.0" platform="android" />
>>> not:
>>> <engine name="cordova" version=">=1.8.0" platform="android" />
>>
>> What is actually different here? I know the implementation assumes all
>> platforms when it sees cordova but it does not have to, it could just
>> look take platform attribute into account. I am just
>> trying to understand the reasons for the cordova-${platform} engine
>> names.
>
> The difference is name="cordova-android" vs name="cordova".
>
> Not positive, but I think:
> cordova-android refers to the version of the cordova-android repo that
> you're using.
> cordova refers to the cadence version of cordova that you're using
> (version of CLI tools or version of cordova-js)
>
>
>>
>>>
>>>
>>> I think this is definitely open for discussion. As you say - usage of
>>> the tags are very limited right now.
>>>
>>> Other concerns with it I have:
>>> - scriptSrc allows plugins to run code on the host machine upon
>>> install... Seems like a security concern.
>>> I *think* the answer to your question is that we want to be able to specify:
>>> <engine name="cordova-android" version=">=1.8.0" />
>>> <engine name="cordova-ios" version=">=1.9.0" />
>>>
>>> And don't want cordova-ios checked when you don't have the android
>>> platform. And the syntax is more concise than:
>>
>> I think this is a bit strict and makes life harder if iOS is not really
>> targeted by the application. Perhaps missing one of those engines should
>> be a warning and missing all of them a fail.
>
> The engines are specified in plugin.xml, not in config.xml. If you
> don't meet the iOS requirement for the plugin because you don't have
> the iOS platform, then it for sure should be ignored.
>
>
>>
>>> <engine name="cordova-android" version=">=1.8.0" platform="android" />
>>>
>>>
>>> On Mon, Jan 13, 2014 at 2:33 PM, Gorkem Ercan <go...@gmail.com> wrote:
>>> > JBoss Tools have recently added the capability to switch between
>>> > Cordova engines. See [1] for details. While implementing checks for
>>> > plug-in compatibility I found the engine definitions on the plug-in specification to
>>> > be more complex than needed to be.
>>> >
>>> > I think there are too many "default engines" defined.
>>> > for instance
>>> > <engine name="cordova-android" version=">=1.8.0" />
>>> > is essentially the same as
>>> > <engine name="cordova" version=">=1.8.0" platform="android" />
>>> >
>>> > Could someone remind the reason for having platform specific default engine names? If
>>> > they exist for a historic reason can we remove it from the documentation
>>> > and guide people to use the platform attribute? I can provide a doc patch for this purpose.
>>> > I think this is making the implementation on plugman more complex also.
>>> >
>>> > And specifying custom Apache Cordova-based frameworks is a different
>>> > beast altogether. It actually gives the responsibility to integrate a
>>> > custom engine with plugman to the plug-ins with the scriptSrc attribute.
>>> > I do not think this will scale considering that the engine and plug-in
>>> > ideally have a different life cycle. I think plugman should actually
>>> > provide a way for custom engines to provide this information.
>>> >
>>> > I guess there is some merit to engines such as "apple-xcode" but I have
>>> > yet not been able to find a plug-in that uses those. I must also admit
>>> > the use of engine definitions is also very limited.
>>> >
>>> > [1] http://www.gorkem-ercan.com/2014/01/multiple-cordova-engines-on-jboss.html
Re: Engines and plugins
Posted by Tim Kim <ti...@gmail.com>.
Howdy,
I think there are too many "default engines" defined.
> for instance
> <engine name="cordova-android" version=">=1.8.0" />
> is essentially the same as
> <engine name="cordova" version=">=1.8.0" platform="android" />
> Could someone remind the reason for having platform specific default
> engine names? If
> they exist for a historic reason can we remove it from the documentation
> and guide people to use the platform attribute?
The main reasoning for the default engines (ie, cordova-android,
cordova-ios, etc) was the ability to have the plugin be able to install on
different versions of a particular platform. For example, say your project
is deployed on both iOS and android with your own custom plugin. However,
if the case should arise where your custom plugin only works on say 3.3.0
of android but up to 3.2.0 on iOS then you'll be able to define it with
something like:
<engine name="cordova-android" version="3.3.0" />
<engine name="cordova-ios" version="3.2.0" />
As for the regular Cordova engine, that one is basically a shortcut. It
basically says you don't really care about knowing which particular
platform you want to install on but that platform needs to be of some
version of Cordova that a user specifies.
And specifying custom Apache Cordova-based frameworks is a different
> beast altogether. It actually gives the responsibility to integrate a
> custom engine with plugman to the plug-ins with the scriptSrc attribute.
> I do not think this will scale considering that the engine and plug-in
> ideally have a different life cycle. I think plugman should actually
> provide a way for custom engines to provide this information.
I guess the scriptSrc wasn't the most ideal way of doing this, but I wasn't
too sure how custom engines were being used at that point. So I left it as
the responsibility of the to the custom engine.
I hope that helps!
On 14 January 2014 08:56, Marcel Kinard <cm...@gmail.com> wrote:
> Sounds like the ouput of this "how it works" should go in cordova-docs. If
> it's not clear to us, then it won't be clear to users. ;-)
>
> On Jan 13, 2014, at 9:36 PM, Andrew Grieve <ag...@chromium.org> wrote:
>
> > On Mon, Jan 13, 2014 at 6:14 PM, Gorkem Ercan <go...@gmail.com>
> wrote:
> >> On Mon, Jan 13, 2014 at 04:32:20PM -0500, Andrew Grieve wrote:
> >>> FYI to others - the docs for this is found here (seems to have some
> >>> incorrectly formatted markdown too :( ) :
> >>>
> http://cordova.apache.org/docs/en/3.3.0/plugin_ref_spec.md.html#Plugin%20Specification
> >>>
> >>> My understanding was that:
> >>> <engine name="cordova-android" version=">=1.8.0" />
> >>> is the same as:
> >>> <engine name="cordova-android" version=">=1.8.0" platform="android" />
> >>> not:
> >>> <engine name="cordova" version=">=1.8.0" platform="android" />
> >>
> >> What is actually different here? I know the implementation assumes all
> >> platforms when it sees cordova but it does not have to, it could just
> >> look take platform attribute into account. I am just
> >> trying to understand the reasons for the cordova-${platform} engine
> >> names.
> >
> > The difference is name="cordova-android" vs name="cordova".
> >
> > Not positive, but I think:
> > cordova-android refers to the version of the cordova-android repo that
> > you're using.
> > cordova refers to the cadence version of cordova that you're using
> > (version of CLI tools or version of cordova-js)
>
>
--
Timothy Kim
Re: Engines and plugins
Posted by Marcel Kinard <cm...@gmail.com>.
Sounds like the ouput of this "how it works" should go in cordova-docs. If it's not clear to us, then it won't be clear to users. ;-)
On Jan 13, 2014, at 9:36 PM, Andrew Grieve <ag...@chromium.org> wrote:
> On Mon, Jan 13, 2014 at 6:14 PM, Gorkem Ercan <go...@gmail.com> wrote:
>> On Mon, Jan 13, 2014 at 04:32:20PM -0500, Andrew Grieve wrote:
>>> FYI to others - the docs for this is found here (seems to have some
>>> incorrectly formatted markdown too :( ) :
>>> http://cordova.apache.org/docs/en/3.3.0/plugin_ref_spec.md.html#Plugin%20Specification
>>>
>>> My understanding was that:
>>> <engine name="cordova-android" version=">=1.8.0" />
>>> is the same as:
>>> <engine name="cordova-android" version=">=1.8.0" platform="android" />
>>> not:
>>> <engine name="cordova" version=">=1.8.0" platform="android" />
>>
>> What is actually different here? I know the implementation assumes all
>> platforms when it sees cordova but it does not have to, it could just
>> look take platform attribute into account. I am just
>> trying to understand the reasons for the cordova-${platform} engine
>> names.
>
> The difference is name="cordova-android" vs name="cordova".
>
> Not positive, but I think:
> cordova-android refers to the version of the cordova-android repo that
> you're using.
> cordova refers to the cadence version of cordova that you're using
> (version of CLI tools or version of cordova-js)
Re: Engines and plugins
Posted by Andrew Grieve <ag...@chromium.org>.
On Mon, Jan 13, 2014 at 6:14 PM, Gorkem Ercan <go...@gmail.com> wrote:
> On Mon, Jan 13, 2014 at 04:32:20PM -0500, Andrew Grieve wrote:
>> FYI to others - the docs for this is found here (seems to have some
>> incorrectly formatted markdown too :( ) :
>> http://cordova.apache.org/docs/en/3.3.0/plugin_ref_spec.md.html#Plugin%20Specification
>>
>> My understanding was that:
>> <engine name="cordova-android" version=">=1.8.0" />
>> is the same as:
>> <engine name="cordova-android" version=">=1.8.0" platform="android" />
>> not:
>> <engine name="cordova" version=">=1.8.0" platform="android" />
>
> What is actually different here? I know the implementation assumes all
> platforms when it sees cordova but it does not have to, it could just
> look take platform attribute into account. I am just
> trying to understand the reasons for the cordova-${platform} engine
> names.
The difference is name="cordova-android" vs name="cordova".
Not positive, but I think:
cordova-android refers to the version of the cordova-android repo that
you're using.
cordova refers to the cadence version of cordova that you're using
(version of CLI tools or version of cordova-js)
>
>>
>>
>> I think this is definitely open for discussion. As you say - usage of
>> the tags are very limited right now.
>>
>> Other concerns with it I have:
>> - scriptSrc allows plugins to run code on the host machine upon
>> install... Seems like a security concern.
>> I *think* the answer to your question is that we want to be able to specify:
>> <engine name="cordova-android" version=">=1.8.0" />
>> <engine name="cordova-ios" version=">=1.9.0" />
>>
>> And don't want cordova-ios checked when you don't have the android
>> platform. And the syntax is more concise than:
>
> I think this is a bit strict and makes life harder if iOS is not really
> targeted by the application. Perhaps missing one of those engines should
> be a warning and missing all of them a fail.
The engines are specified in plugin.xml, not in config.xml. If you
don't meet the iOS requirement for the plugin because you don't have
the iOS platform, then it for sure should be ignored.
>
>> <engine name="cordova-android" version=">=1.8.0" platform="android" />
>>
>>
>> On Mon, Jan 13, 2014 at 2:33 PM, Gorkem Ercan <go...@gmail.com> wrote:
>> > JBoss Tools have recently added the capability to switch between
>> > Cordova engines. See [1] for details. While implementing checks for
>> > plug-in compatibility I found the engine definitions on the plug-in specification to
>> > be more complex than needed to be.
>> >
>> > I think there are too many "default engines" defined.
>> > for instance
>> > <engine name="cordova-android" version=">=1.8.0" />
>> > is essentially the same as
>> > <engine name="cordova" version=">=1.8.0" platform="android" />
>> >
>> > Could someone remind the reason for having platform specific default engine names? If
>> > they exist for a historic reason can we remove it from the documentation
>> > and guide people to use the platform attribute? I can provide a doc patch for this purpose.
>> > I think this is making the implementation on plugman more complex also.
>> >
>> > And specifying custom Apache Cordova-based frameworks is a different
>> > beast altogether. It actually gives the responsibility to integrate a
>> > custom engine with plugman to the plug-ins with the scriptSrc attribute.
>> > I do not think this will scale considering that the engine and plug-in
>> > ideally have a different life cycle. I think plugman should actually
>> > provide a way for custom engines to provide this information.
>> >
>> > I guess there is some merit to engines such as "apple-xcode" but I have
>> > yet not been able to find a plug-in that uses those. I must also admit
>> > the use of engine definitions is also very limited.
>> >
>> > [1] http://www.gorkem-ercan.com/2014/01/multiple-cordova-engines-on-jboss.html
Re: Engines and plugins
Posted by Gorkem Ercan <go...@gmail.com>.
On Mon, Jan 13, 2014 at 04:32:20PM -0500, Andrew Grieve wrote:
> FYI to others - the docs for this is found here (seems to have some
> incorrectly formatted markdown too :( ) :
> http://cordova.apache.org/docs/en/3.3.0/plugin_ref_spec.md.html#Plugin%20Specification
>
> My understanding was that:
> <engine name="cordova-android" version=">=1.8.0" />
> is the same as:
> <engine name="cordova-android" version=">=1.8.0" platform="android" />
> not:
> <engine name="cordova" version=">=1.8.0" platform="android" />
What is actually different here? I know the implementation assumes all
platforms when it sees cordova but it does not have to, it could just
look take platform attribute into account. I am just
trying to understand the reasons for the cordova-${platform} engine
names.
>
>
> I think this is definitely open for discussion. As you say - usage of
> the tags are very limited right now.
>
> Other concerns with it I have:
> - scriptSrc allows plugins to run code on the host machine upon
> install... Seems like a security concern.
> I *think* the answer to your question is that we want to be able to specify:
> <engine name="cordova-android" version=">=1.8.0" />
> <engine name="cordova-ios" version=">=1.9.0" />
>
> And don't want cordova-ios checked when you don't have the android
> platform. And the syntax is more concise than:
I think this is a bit strict and makes life harder if iOS is not really
targeted by the application. Perhaps missing one of those engines should
be a warning and missing all of them a fail.
> <engine name="cordova-android" version=">=1.8.0" platform="android" />
>
>
> On Mon, Jan 13, 2014 at 2:33 PM, Gorkem Ercan <go...@gmail.com> wrote:
> > JBoss Tools have recently added the capability to switch between
> > Cordova engines. See [1] for details. While implementing checks for
> > plug-in compatibility I found the engine definitions on the plug-in specification to
> > be more complex than needed to be.
> >
> > I think there are too many "default engines" defined.
> > for instance
> > <engine name="cordova-android" version=">=1.8.0" />
> > is essentially the same as
> > <engine name="cordova" version=">=1.8.0" platform="android" />
> >
> > Could someone remind the reason for having platform specific default engine names? If
> > they exist for a historic reason can we remove it from the documentation
> > and guide people to use the platform attribute? I can provide a doc patch for this purpose.
> > I think this is making the implementation on plugman more complex also.
> >
> > And specifying custom Apache Cordova-based frameworks is a different
> > beast altogether. It actually gives the responsibility to integrate a
> > custom engine with plugman to the plug-ins with the scriptSrc attribute.
> > I do not think this will scale considering that the engine and plug-in
> > ideally have a different life cycle. I think plugman should actually
> > provide a way for custom engines to provide this information.
> >
> > I guess there is some merit to engines such as "apple-xcode" but I have
> > yet not been able to find a plug-in that uses those. I must also admit
> > the use of engine definitions is also very limited.
> >
> > [1] http://www.gorkem-ercan.com/2014/01/multiple-cordova-engines-on-jboss.html
Re: Engines and plugins
Posted by Andrew Grieve <ag...@chromium.org>.
FYI to others - the docs for this is found here (seems to have some
incorrectly formatted markdown too :( ) :
http://cordova.apache.org/docs/en/3.3.0/plugin_ref_spec.md.html#Plugin%20Specification
My understanding was that:
<engine name="cordova-android" version=">=1.8.0" />
is the same as:
<engine name="cordova-android" version=">=1.8.0" platform="android" />
not:
<engine name="cordova" version=">=1.8.0" platform="android" />
I think this is definitely open for discussion. As you say - usage of
the tags are very limited right now.
Other concerns with it I have:
- scriptSrc allows plugins to run code on the host machine upon
install... Seems like a security concern.
- I think failures should be warnings not errors
I *think* the answer to your question is that we want to be able to specify:
<engine name="cordova-android" version=">=1.8.0" />
<engine name="cordova-ios" version=">=1.9.0" />
And don't want cordova-ios checked when you don't have the android
platform. And the syntax is more concise than:
<engine name="cordova-android" version=">=1.8.0" platform="android" />
On Mon, Jan 13, 2014 at 2:33 PM, Gorkem Ercan <go...@gmail.com> wrote:
> JBoss Tools have recently added the capability to switch between
> Cordova engines. See [1] for details. While implementing checks for
> plug-in compatibility I found the engine definitions on the plug-in specification to
> be more complex than needed to be.
>
> I think there are too many "default engines" defined.
> for instance
> <engine name="cordova-android" version=">=1.8.0" />
> is essentially the same as
> <engine name="cordova" version=">=1.8.0" platform="android" />
>
> Could someone remind the reason for having platform specific default engine names? If
> they exist for a historic reason can we remove it from the documentation
> and guide people to use the platform attribute? I can provide a doc patch for this purpose.
> I think this is making the implementation on plugman more complex also.
>
> And specifying custom Apache Cordova-based frameworks is a different
> beast altogether. It actually gives the responsibility to integrate a
> custom engine with plugman to the plug-ins with the scriptSrc attribute.
> I do not think this will scale considering that the engine and plug-in
> ideally have a different life cycle. I think plugman should actually
> provide a way for custom engines to provide this information.
>
> I guess there is some merit to engines such as "apple-xcode" but I have
> yet not been able to find a plug-in that uses those. I must also admit
> the use of engine definitions is also very limited.
>
> [1] http://www.gorkem-ercan.com/2014/01/multiple-cordova-engines-on-jboss.html