You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Filip Maj <fi...@adobe.com> on 2013/08/14 21:41:32 UTC
plugin.xml specification
Hey all,
There's an issue filed for plugman [1], wherein a user had an issue
authoring a plugin.xml file for a plugin and got tripped up with
<framework> [2] and <lib-file> [3] support on different platforms.
Currently: <framework> only applies to iOS. <lib-file> only for BB10. To
confuse matters further, we also support <source-file> elements with a
framework=true attribute (that is iOS-only).
:)
Any ideas on how to consolidate all this stuff? How to make this
specification clearer/more readable/more intuitive?
[1] https://issues.apache.org/jira/browse/CB-4430
[2]
http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
ecification_framework
[3]
http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
ecification_lib_file
[4]
http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
ecification_source_file
Re: plugin.xml specification
Posted by Shazron <sh...@gmail.com>.
Only used the framework attribute name because of the clear link with the
<framework> tag behaviour. Not opposed to changing it for clarity, for sure
On Thu, Aug 29, 2013 at 10:58 PM, Andrew Grieve <ag...@chromium.org>wrote:
> I suppose this is fine. I think a logical alternative would be to use <src>
> and have plugman know that .a means add it to your linker flags. It's not a
> framework (since it doesn't have a .framework extension), so the name is a
> bit confusing.
>
>
>
> On Mon, Aug 26, 2013 at 3:57 AM, Shazron <sh...@gmail.com> wrote:
>
> > I'm the culprit behind the request for source-file framework=true :)
> >
> > This was started in the pre-3.0.0 days, and is still a concern in 3.0.0.
> > For example look at this plugin:
> > https://github.com/shazron/TestFlightPlugin/blob/master/plugin.xml
> >
> > The libTestFlight.a file is a file that needs to be copied over
> > (<source-file>), and also installed in the "Link Binary with Libraries"
> > section (<framework>. It cannot be added as just a <framework> because
> that
> > just adds it to "Link Binary with Libraries" (this is mainly for System
> > frameworks, e.g CoreMedia.framework).
> >
> >
> >
> >
> >
> >
> > On Thu, Aug 15, 2013 at 4:37 AM, Andrew Grieve <ag...@chromium.org>
> > wrote:
> >
> > > #1 <lib-file> == dynamically linked libs that exist in your plugin ==
> > .so,
> > > .dll, .dylib, .jar
> > > #2 <framework> == dynamically linked libs provided by the OS == .so,
> > .dll,
> > > .dylib, .framework
> > > #3 <src> == precompiled object file / lib that exists in you plugins ==
> > .a,
> > > .o
> > > #4 <src framework="true"> == ???... Might refer to the fake .framework
> > > files that some iOS projects distribute (that have .a in them instead
> of
> > > .dylib). Example might just be wrong (should say .framework not .a)
> > >
> > > so... I think all four do different things, but maybe we can coalesce
> > them
> > > better?
> > >
> > > e.g. we could have have framework=true be unnecessary by just looking
> at
> > > the file extension.
> > > Not sure about a sane way to combine the others... Maybe add a section
> to
> > > the docs that highlights the differences?
> > >
> > >
> > > On Wed, Aug 14, 2013 at 3:53 PM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >
> > > > I would think it will be more confusing to use the same tag name that
> > > does
> > > > something different depending on which platform its used on, so I'de
> > vote
> > > > to leave them specific and not try to unify.
> > > >
> > > > I do think thats its hard to tell which tag applies to which
> platform,
> > so
> > > > perhaps a platform prefix or platform attribute that is verified by a
> > > > schema (ie, <framework platform=ios ...>, <lib-file platform=bb10
> ...>)
> > > >
> > > > Not sure about the sourrce-file framework=true issue, but that sounds
> > > > confusing :)
> > > >
> > > >
> > > > On Wed, Aug 14, 2013 at 3:41 PM, Filip Maj <fi...@adobe.com> wrote:
> > > >
> > > > > Hey all,
> > > > >
> > > > > There's an issue filed for plugman [1], wherein a user had an issue
> > > > > authoring a plugin.xml file for a plugin and got tripped up with
> > > > > <framework> [2] and <lib-file> [3] support on different platforms.
> > > > >
> > > > > Currently: <framework> only applies to iOS. <lib-file> only for
> BB10.
> > > To
> > > > > confuse matters further, we also support <source-file> elements
> with
> > a
> > > > > framework=true attribute (that is iOS-only).
> > > > >
> > > > > :)
> > > > >
> > > > > Any ideas on how to consolidate all this stuff? How to make this
> > > > > specification clearer/more readable/more intuitive?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/CB-4430
> > > > > [2]
> > > > >
> > > >
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > > > > ecification_framework
> > > > > [3]
> > > > >
> > > >
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > > > > ecification_lib_file
> > > > > [4]
> > > > >
> > > >
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > > > > ecification_source_file
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: plugin.xml specification
Posted by Andrew Grieve <ag...@chromium.org>.
I suppose this is fine. I think a logical alternative would be to use <src>
and have plugman know that .a means add it to your linker flags. It's not a
framework (since it doesn't have a .framework extension), so the name is a
bit confusing.
On Mon, Aug 26, 2013 at 3:57 AM, Shazron <sh...@gmail.com> wrote:
> I'm the culprit behind the request for source-file framework=true :)
>
> This was started in the pre-3.0.0 days, and is still a concern in 3.0.0.
> For example look at this plugin:
> https://github.com/shazron/TestFlightPlugin/blob/master/plugin.xml
>
> The libTestFlight.a file is a file that needs to be copied over
> (<source-file>), and also installed in the "Link Binary with Libraries"
> section (<framework>. It cannot be added as just a <framework> because that
> just adds it to "Link Binary with Libraries" (this is mainly for System
> frameworks, e.g CoreMedia.framework).
>
>
>
>
>
>
> On Thu, Aug 15, 2013 at 4:37 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > #1 <lib-file> == dynamically linked libs that exist in your plugin ==
> .so,
> > .dll, .dylib, .jar
> > #2 <framework> == dynamically linked libs provided by the OS == .so,
> .dll,
> > .dylib, .framework
> > #3 <src> == precompiled object file / lib that exists in you plugins ==
> .a,
> > .o
> > #4 <src framework="true"> == ???... Might refer to the fake .framework
> > files that some iOS projects distribute (that have .a in them instead of
> > .dylib). Example might just be wrong (should say .framework not .a)
> >
> > so... I think all four do different things, but maybe we can coalesce
> them
> > better?
> >
> > e.g. we could have have framework=true be unnecessary by just looking at
> > the file extension.
> > Not sure about a sane way to combine the others... Maybe add a section to
> > the docs that highlights the differences?
> >
> >
> > On Wed, Aug 14, 2013 at 3:53 PM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> > > I would think it will be more confusing to use the same tag name that
> > does
> > > something different depending on which platform its used on, so I'de
> vote
> > > to leave them specific and not try to unify.
> > >
> > > I do think thats its hard to tell which tag applies to which platform,
> so
> > > perhaps a platform prefix or platform attribute that is verified by a
> > > schema (ie, <framework platform=ios ...>, <lib-file platform=bb10 ...>)
> > >
> > > Not sure about the sourrce-file framework=true issue, but that sounds
> > > confusing :)
> > >
> > >
> > > On Wed, Aug 14, 2013 at 3:41 PM, Filip Maj <fi...@adobe.com> wrote:
> > >
> > > > Hey all,
> > > >
> > > > There's an issue filed for plugman [1], wherein a user had an issue
> > > > authoring a plugin.xml file for a plugin and got tripped up with
> > > > <framework> [2] and <lib-file> [3] support on different platforms.
> > > >
> > > > Currently: <framework> only applies to iOS. <lib-file> only for BB10.
> > To
> > > > confuse matters further, we also support <source-file> elements with
> a
> > > > framework=true attribute (that is iOS-only).
> > > >
> > > > :)
> > > >
> > > > Any ideas on how to consolidate all this stuff? How to make this
> > > > specification clearer/more readable/more intuitive?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/CB-4430
> > > > [2]
> > > >
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > > > ecification_framework
> > > > [3]
> > > >
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > > > ecification_lib_file
> > > > [4]
> > > >
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > > > ecification_source_file
> > > >
> > > >
> > >
> >
>
Re: plugin.xml specification
Posted by Shazron <sh...@gmail.com>.
I'm the culprit behind the request for source-file framework=true :)
This was started in the pre-3.0.0 days, and is still a concern in 3.0.0.
For example look at this plugin:
https://github.com/shazron/TestFlightPlugin/blob/master/plugin.xml
The libTestFlight.a file is a file that needs to be copied over
(<source-file>), and also installed in the "Link Binary with Libraries"
section (<framework>. It cannot be added as just a <framework> because that
just adds it to "Link Binary with Libraries" (this is mainly for System
frameworks, e.g CoreMedia.framework).
On Thu, Aug 15, 2013 at 4:37 AM, Andrew Grieve <ag...@chromium.org> wrote:
> #1 <lib-file> == dynamically linked libs that exist in your plugin == .so,
> .dll, .dylib, .jar
> #2 <framework> == dynamically linked libs provided by the OS == .so, .dll,
> .dylib, .framework
> #3 <src> == precompiled object file / lib that exists in you plugins == .a,
> .o
> #4 <src framework="true"> == ???... Might refer to the fake .framework
> files that some iOS projects distribute (that have .a in them instead of
> .dylib). Example might just be wrong (should say .framework not .a)
>
> so... I think all four do different things, but maybe we can coalesce them
> better?
>
> e.g. we could have have framework=true be unnecessary by just looking at
> the file extension.
> Not sure about a sane way to combine the others... Maybe add a section to
> the docs that highlights the differences?
>
>
> On Wed, Aug 14, 2013 at 3:53 PM, Michal Mocny <mm...@chromium.org> wrote:
>
> > I would think it will be more confusing to use the same tag name that
> does
> > something different depending on which platform its used on, so I'de vote
> > to leave them specific and not try to unify.
> >
> > I do think thats its hard to tell which tag applies to which platform, so
> > perhaps a platform prefix or platform attribute that is verified by a
> > schema (ie, <framework platform=ios ...>, <lib-file platform=bb10 ...>)
> >
> > Not sure about the sourrce-file framework=true issue, but that sounds
> > confusing :)
> >
> >
> > On Wed, Aug 14, 2013 at 3:41 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> > > Hey all,
> > >
> > > There's an issue filed for plugman [1], wherein a user had an issue
> > > authoring a plugin.xml file for a plugin and got tripped up with
> > > <framework> [2] and <lib-file> [3] support on different platforms.
> > >
> > > Currently: <framework> only applies to iOS. <lib-file> only for BB10.
> To
> > > confuse matters further, we also support <source-file> elements with a
> > > framework=true attribute (that is iOS-only).
> > >
> > > :)
> > >
> > > Any ideas on how to consolidate all this stuff? How to make this
> > > specification clearer/more readable/more intuitive?
> > >
> > > [1] https://issues.apache.org/jira/browse/CB-4430
> > > [2]
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > > ecification_framework
> > > [3]
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > > ecification_lib_file
> > > [4]
> > >
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > > ecification_source_file
> > >
> > >
> >
>
Re: plugin.xml specification
Posted by Andrew Grieve <ag...@chromium.org>.
#1 <lib-file> == dynamically linked libs that exist in your plugin == .so,
.dll, .dylib, .jar
#2 <framework> == dynamically linked libs provided by the OS == .so, .dll,
.dylib, .framework
#3 <src> == precompiled object file / lib that exists in you plugins == .a,
.o
#4 <src framework="true"> == ???... Might refer to the fake .framework
files that some iOS projects distribute (that have .a in them instead of
.dylib). Example might just be wrong (should say .framework not .a)
so... I think all four do different things, but maybe we can coalesce them
better?
e.g. we could have have framework=true be unnecessary by just looking at
the file extension.
Not sure about a sane way to combine the others... Maybe add a section to
the docs that highlights the differences?
On Wed, Aug 14, 2013 at 3:53 PM, Michal Mocny <mm...@chromium.org> wrote:
> I would think it will be more confusing to use the same tag name that does
> something different depending on which platform its used on, so I'de vote
> to leave them specific and not try to unify.
>
> I do think thats its hard to tell which tag applies to which platform, so
> perhaps a platform prefix or platform attribute that is verified by a
> schema (ie, <framework platform=ios ...>, <lib-file platform=bb10 ...>)
>
> Not sure about the sourrce-file framework=true issue, but that sounds
> confusing :)
>
>
> On Wed, Aug 14, 2013 at 3:41 PM, Filip Maj <fi...@adobe.com> wrote:
>
> > Hey all,
> >
> > There's an issue filed for plugman [1], wherein a user had an issue
> > authoring a plugin.xml file for a plugin and got tripped up with
> > <framework> [2] and <lib-file> [3] support on different platforms.
> >
> > Currently: <framework> only applies to iOS. <lib-file> only for BB10. To
> > confuse matters further, we also support <source-file> elements with a
> > framework=true attribute (that is iOS-only).
> >
> > :)
> >
> > Any ideas on how to consolidate all this stuff? How to make this
> > specification clearer/more readable/more intuitive?
> >
> > [1] https://issues.apache.org/jira/browse/CB-4430
> > [2]
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > ecification_framework
> > [3]
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > ecification_lib_file
> > [4]
> >
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> > ecification_source_file
> >
> >
>
Re: plugin.xml specification
Posted by Michal Mocny <mm...@chromium.org>.
I would think it will be more confusing to use the same tag name that does
something different depending on which platform its used on, so I'de vote
to leave them specific and not try to unify.
I do think thats its hard to tell which tag applies to which platform, so
perhaps a platform prefix or platform attribute that is verified by a
schema (ie, <framework platform=ios ...>, <lib-file platform=bb10 ...>)
Not sure about the sourrce-file framework=true issue, but that sounds
confusing :)
On Wed, Aug 14, 2013 at 3:41 PM, Filip Maj <fi...@adobe.com> wrote:
> Hey all,
>
> There's an issue filed for plugman [1], wherein a user had an issue
> authoring a plugin.xml file for a plugin and got tripped up with
> <framework> [2] and <lib-file> [3] support on different platforms.
>
> Currently: <framework> only applies to iOS. <lib-file> only for BB10. To
> confuse matters further, we also support <source-file> elements with a
> framework=true attribute (that is iOS-only).
>
> :)
>
> Any ideas on how to consolidate all this stuff? How to make this
> specification clearer/more readable/more intuitive?
>
> [1] https://issues.apache.org/jira/browse/CB-4430
> [2]
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> ecification_framework
> [3]
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> ecification_lib_file
> [4]
> http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Sp
> ecification_source_file
>
>