Re: new meta data for plugin.xml
Thanks Brian. It's interesting to hear the history.
Sent from my iPhone
> On Oct 21, 2013, at 7:45 PM, Brian LeRoux wrote:
>
> Not so much an accident as very deliberate!
>
> When we started this is how you worked with JSON:
>
> var data = eval('"' + my_json_string + '"')
>
> We then had some fun w/ Crockford's JSON lib licensing. [1] Specifically
> IBM did not like the enforceability of "The Software shall be used for
> Good, not Evil." clause. Doug offered to rewrite it: "The Software shall be
> used for Good, not Evil, unless you are IBM." But surprisingly this was not
> enough. So, we wrote our own JSON lib. Yup. JavaScript was pretty awesome 5
> years ago.
>
>
> /me grumbles about lawn or something
>
>
> [1] http://www.json.org/license.html
>
>
>
> On Mon, Oct 21, 2013 at 7:41 AM, Braden Shepherdson
> wrote:
>
>> I'd be happier if it were JSON, but it's not, and the XML doesn't cause
>> enough pain to be worth making the switch.
>>
>> Ian explained it accurately; it's mostly a historical accident that we're
>> using XML.
>>
>> Braden
>>
>>
>> On Mon, Oct 21, 2013 at 10:09 AM, Lucas Holmquist >> wrote:
>>
>>> yea, this is understandable. wasn't really sure the reasoning, but it
>>> looks like diminishing returns here
On Oct 21, 2013, at 10:06 AM, Michal Mocny wrote:
XML is also buying us a couple of small but nice features, such as
optionally wrapping tags with a tag or (potentially) a
>>
tag, etc. That functionality would not be expressed as cleanly with
>>> JSON,
so its not a pure win to move away from XML.
Add to that the fact that we are already perceived to change stuff way
>>> too
often for no due cause, I just really don't see the value.
> On Mon, Oct 21, 2013 at 9:28 AM, Ian Clelland
wrote:
> I suspect that it is because plugin.xml was derived (intellectually,
>> if
>>> not
> literally) from config.xml, which was an XML file because of the W3C
> Widgets spec, which we tried to adhere to.
>
> Whether that spec is still relevant (there doesn't seem to be a lot of
> vendor interest in it (speaking as an Apache member, *not* as a vendor
> representative)) is definitely up for debate. There probably are some
>>> gains
> to be made in switching to a JSON config format, given how much of the
> project is JavaScript these days, but it might not be worth all of the
>>> work
> it would take to do it.
>
> Ian
>
>
> On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist > wrote:
>
>> Perhaps this has been brought up before, but why are we using an xml
>> file? why not make it a json file.
>>
>> Plugman is written in node( js ) so why not have the plugin "config"
>>> file
>> in it's native format. This will probably save a bit of code since
>> the
> xml
>> is converted to an object to manipulate anyway.
>>
>>
>> i know this is a little off topic.
>>
>> thoughts?
>>
>> On Oct 18, 2013, at 5:31 PM, Steven Gill
>>> wrote:
>>
>>> I have created an issue to keep track of the registry refactor.
>>> https://issues.apache.org/jira/browse/CB-5130
>>>
>>>
On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI
>>> wrote:
>>>
I added some validation for plugin names (to follow
reverse-domain-name convention) a couple of weeks ago but there
>> needs
to be more of it for sure.
On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill <
>>> stevengil...@gmail.com
>>
wrote:
> I have created an issue to track the meta tag addition.
> https://issues.apache.org/jira/browse/CB-5128
>
> I agree with doing validation with plugman during publish time. We
>> should
> decide soon which ones are going to be mandatory and which ones
>> will
> be
> optional. Probably update the plugin spec + our docs around
>> creating
> plugins as well.
>
>
>
> On Fri, Oct 18, 2013 at 11:54 AM, Shazron
>>> wrote:
>
>> Perhaps either plugman or the registry should do some validation,
> and
have
>> some "required" fields? I know that PhoneGap Build when you try
>> to
submit a
>> plugin they error out if you are missing some fields that they
>> require.
>>
>>
>> On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan <
>> gorkem.er...@gmail.com
>>> wrote:
>>
>>> +1 for adding metadata but should more of the metadata be
> compulsory?
>>>
>>> JBoss tools plugin discovery uses the cordova.io registry and
>>> some
of
>> the
>>> plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a
screenshot
>>> that shows how the case. http://snag.gy/J8rl6.jpg is a
>> screenshot
> of
>>>
Re: new meta data for plugin.xml
Not so much an accident as very deliberate!
When we started this is how you worked with JSON:
var data = eval('"' + my_json_string + '"')
We then had some fun w/ Crockford's JSON lib licensing. [1] Specifically
IBM did not like the enforceability of "The Software shall be used for
Good, not Evil." clause. Doug offered to rewrite it: "The Software shall be
used for Good, not Evil, unless you are IBM." But surprisingly this was not
enough. So, we wrote our own JSON lib. Yup. JavaScript was pretty awesome 5
years ago.
/me grumbles about lawn or something
[1] http://www.json.org/license.html
On Mon, Oct 21, 2013 at 7:41 AM, Braden Shepherdson wrote:
> I'd be happier if it were JSON, but it's not, and the XML doesn't cause
> enough pain to be worth making the switch.
>
> Ian explained it accurately; it's mostly a historical accident that we're
> using XML.
>
> Braden
>
>
> On Mon, Oct 21, 2013 at 10:09 AM, Lucas Holmquist >wrote:
>
> > yea, this is understandable. wasn't really sure the reasoning, but it
> > looks like diminishing returns here
> > On Oct 21, 2013, at 10:06 AM, Michal Mocny wrote:
> >
> > > XML is also buying us a couple of small but nice features, such as
> > > optionally wrapping tags with a tag or (potentially) a
>
> > > tag, etc. That functionality would not be expressed as cleanly with
> > JSON,
> > > so its not a pure win to move away from XML.
> > >
> > > Add to that the fact that we are already perceived to change stuff way
> > too
> > > often for no due cause, I just really don't see the value.
> > >
> > >
> > > On Mon, Oct 21, 2013 at 9:28 AM, Ian Clelland
> > wrote:
> > >
> > >> I suspect that it is because plugin.xml was derived (intellectually,
> if
> > not
> > >> literally) from config.xml, which was an XML file because of the W3C
> > >> Widgets spec, which we tried to adhere to.
> > >>
> > >> Whether that spec is still relevant (there doesn't seem to be a lot of
> > >> vendor interest in it (speaking as an Apache member, *not* as a vendor
> > >> representative)) is definitely up for debate. There probably are some
> > gains
> > >> to be made in switching to a JSON config format, given how much of the
> > >> project is JavaScript these days, but it might not be worth all of the
> > work
> > >> it would take to do it.
> > >>
> > >> Ian
> > >>
> > >>
> > >> On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist > >>> wrote:
> > >>
> > >>> Perhaps this has been brought up before, but why are we using an xml
> > >>> file? why not make it a json file.
> > >>>
> > >>> Plugman is written in node( js ) so why not have the plugin "config"
> > file
> > >>> in it's native format. This will probably save a bit of code since
> the
> > >> xml
> > >>> is converted to an object to manipulate anyway.
> > >>>
> > >>>
> > >>> i know this is a little off topic.
> > >>>
> > >>> thoughts?
> > >>>
> > >>> On Oct 18, 2013, at 5:31 PM, Steven Gill
> > wrote:
> > >>>
> > I have created an issue to keep track of the registry refactor.
> > https://issues.apache.org/jira/browse/CB-5130
> >
> >
> > On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI
> > >>> wrote:
> >
> > > I added some validation for plugin names (to follow
> > > reverse-domain-name convention) a couple of weeks ago but there
> needs
> > > to be more of it for sure.
> > >
> > > On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill <
> > stevengil...@gmail.com
> > >>>
> > > wrote:
> > >> I have created an issue to track the meta tag addition.
> > >> https://issues.apache.org/jira/browse/CB-5128
> > >>
> > >> I agree with doing validation with plugman during publish time. We
> > >>> should
> > >> decide soon which ones are going to be mandatory and which ones
> will
> > >> be
> > >> optional. Probably update the plugin spec + our docs around
> creating
> > >> plugins as well.
> > >>
> > >>
> > >>
> > >> On Fri, Oct 18, 2013 at 11:54 AM, Shazron
> > wrote:
> > >>
> > >>> Perhaps either plugman or the registry should do some validation,
> > >> and
> > > have
> > >>> some "required" fields? I know that PhoneGap Build when you try
> to
> > > submit a
> > >>> plugin they error out if you are missing some fields that they
> > >>> require.
> > >>>
> > >>>
> > >>> On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan <
> > >>> gorkem.er...@gmail.com
> > wrote:
> > >>>
> > +1 for adding metadata but should more of the metadata be
> > >> compulsory?
> >
> > JBoss tools plugin discovery uses the cordova.io registry and
> > some
> > > of
> > >>> the
> > plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a
> > > screenshot
> > that shows how the case. http://snag.gy/J8rl6.jpg is a
> screenshot
> > >> of
> > > a
> > >>> few
> > plugins that has most of its data. As you can see with the
> missing
> > descriptions etc. it is not
Re: new meta data for plugin.xml
I'd be happier if it were JSON, but it's not, and the XML doesn't cause enough pain to be worth making the switch. Ian explained it accurately; it's mostly a historical accident that we're using XML. Braden On Mon, Oct 21, 2013 at 10:09 AM, Lucas Holmquist wrote: > yea, this is understandable. wasn't really sure the reasoning, but it > looks like diminishing returns here > On Oct 21, 2013, at 10:06 AM, Michal Mocny wrote: > > > XML is also buying us a couple of small but nice features, such as > > optionally wrapping tags with a tag or (potentially) a > > tag, etc. That functionality would not be expressed as cleanly with > JSON, > > so its not a pure win to move away from XML. > > > > Add to that the fact that we are already perceived to change stuff way > too > > often for no due cause, I just really don't see the value. > > > > > > On Mon, Oct 21, 2013 at 9:28 AM, Ian Clelland > wrote: > > > >> I suspect that it is because plugin.xml was derived (intellectually, if > not > >> literally) from config.xml, which was an XML file because of the W3C > >> Widgets spec, which we tried to adhere to. > >> > >> Whether that spec is still relevant (there doesn't seem to be a lot of > >> vendor interest in it (speaking as an Apache member, *not* as a vendor > >> representative)) is definitely up for debate. There probably are some > gains > >> to be made in switching to a JSON config format, given how much of the > >> project is JavaScript these days, but it might not be worth all of the > work > >> it would take to do it. > >> > >> Ian > >> > >> > >> On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist >>> wrote: > >> > >>> Perhaps this has been brought up before, but why are we using an xml > >>> file? why not make it a json file. > >>> > >>> Plugman is written in node( js ) so why not have the plugin "config" > file > >>> in it's native format. This will probably save a bit of code since the > >> xml > >>> is converted to an object to manipulate anyway. > >>> > >>> > >>> i know this is a little off topic. > >>> > >>> thoughts? > >>> > >>> On Oct 18, 2013, at 5:31 PM, Steven Gill > wrote: > >>> > I have created an issue to keep track of the registry refactor. > https://issues.apache.org/jira/browse/CB-5130 > > > On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI > >>> wrote: > > > I added some validation for plugin names (to follow > > reverse-domain-name convention) a couple of weeks ago but there needs > > to be more of it for sure. > > > > On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill < > stevengil...@gmail.com > >>> > > wrote: > >> I have created an issue to track the meta tag addition. > >> https://issues.apache.org/jira/browse/CB-5128 > >> > >> I agree with doing validation with plugman during publish time. We > >>> should > >> decide soon which ones are going to be mandatory and which ones will > >> be > >> optional. Probably update the plugin spec + our docs around creating > >> plugins as well. > >> > >> > >> > >> On Fri, Oct 18, 2013 at 11:54 AM, Shazron > wrote: > >> > >>> Perhaps either plugman or the registry should do some validation, > >> and > > have > >>> some "required" fields? I know that PhoneGap Build when you try to > > submit a > >>> plugin they error out if you are missing some fields that they > >>> require. > >>> > >>> > >>> On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan < > >>> gorkem.er...@gmail.com > wrote: > >>> > +1 for adding metadata but should more of the metadata be > >> compulsory? > > JBoss tools plugin discovery uses the cordova.io registry and > some > > of > >>> the > plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a > > screenshot > that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot > >> of > > a > >>> few > plugins that has most of its data. As you can see with the missing > descriptions etc. it is not possible to do an informed decision on > >>> whether > to use a plugin or not. Although information such as keywords does > >>> not > >>> seem > like important it becomes quite useful when you are trying to find > >> a > certain plugin. > -- > Gorkem > > > On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny < > mmo...@chromium.org > >>> > >>> wrote: > > > +1 to repo / issue / website / docs etc metadata > > > > -1 *for now* to dependencies at specific versions, and testing > > related > > changes like , just because its not clear what the right > > solution > to > > these problems is. We do need to address it, but those topics > >> will > likely > > move to separate discussions. > > > > > > On Fri, Oct 18, 2013 at 12:24 PM, Lucas H
Re: new meta data for plugin.xml
yea, this is understandable. wasn't really sure the reasoning, but it looks like diminishing returns here On Oct 21, 2013, at 10:06 AM, Michal Mocny wrote: > XML is also buying us a couple of small but nice features, such as > optionally wrapping tags with a tag or (potentially) a > tag, etc. That functionality would not be expressed as cleanly with JSON, > so its not a pure win to move away from XML. > > Add to that the fact that we are already perceived to change stuff way too > often for no due cause, I just really don't see the value. > > > On Mon, Oct 21, 2013 at 9:28 AM, Ian Clelland wrote: > >> I suspect that it is because plugin.xml was derived (intellectually, if not >> literally) from config.xml, which was an XML file because of the W3C >> Widgets spec, which we tried to adhere to. >> >> Whether that spec is still relevant (there doesn't seem to be a lot of >> vendor interest in it (speaking as an Apache member, *not* as a vendor >> representative)) is definitely up for debate. There probably are some gains >> to be made in switching to a JSON config format, given how much of the >> project is JavaScript these days, but it might not be worth all of the work >> it would take to do it. >> >> Ian >> >> >> On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist >> wrote: >> >>> Perhaps this has been brought up before, but why are we using an xml >>> file? why not make it a json file. >>> >>> Plugman is written in node( js ) so why not have the plugin "config" file >>> in it's native format. This will probably save a bit of code since the >> xml >>> is converted to an object to manipulate anyway. >>> >>> >>> i know this is a little off topic. >>> >>> thoughts? >>> >>> On Oct 18, 2013, at 5:31 PM, Steven Gill wrote: >>> I have created an issue to keep track of the registry refactor. https://issues.apache.org/jira/browse/CB-5130 On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI >>> wrote: > I added some validation for plugin names (to follow > reverse-domain-name convention) a couple of weeks ago but there needs > to be more of it for sure. > > On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill >> > wrote: >> I have created an issue to track the meta tag addition. >> https://issues.apache.org/jira/browse/CB-5128 >> >> I agree with doing validation with plugman during publish time. We >>> should >> decide soon which ones are going to be mandatory and which ones will >> be >> optional. Probably update the plugin spec + our docs around creating >> plugins as well. >> >> >> >> On Fri, Oct 18, 2013 at 11:54 AM, Shazron wrote: >> >>> Perhaps either plugman or the registry should do some validation, >> and > have >>> some "required" fields? I know that PhoneGap Build when you try to > submit a >>> plugin they error out if you are missing some fields that they >>> require. >>> >>> >>> On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan < >>> gorkem.er...@gmail.com wrote: >>> +1 for adding metadata but should more of the metadata be >> compulsory? JBoss tools plugin discovery uses the cordova.io registry and some > of >>> the plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a > screenshot that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot >> of > a >>> few plugins that has most of its data. As you can see with the missing descriptions etc. it is not possible to do an informed decision on >>> whether to use a plugin or not. Although information such as keywords does >>> not >>> seem like important it becomes quite useful when you are trying to find >> a certain plugin. -- Gorkem On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny >> >>> wrote: > +1 to repo / issue / website / docs etc metadata > > -1 *for now* to dependencies at specific versions, and testing > related > changes like , just because its not clear what the right > solution to > these problems is. We do need to address it, but those topics >> will likely > move to separate discussions. > > > On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist < > lholm...@redhat.com >> wrote: > >> i was just thinking the same thing :) >> On Oct 18, 2013, at 12:06 PM, Carlos Santana < > csantan...@gmail.com> > wrote: >> >>> plugin.xml metadata is looking more and more like a package.json (i.e. >> npm) >>> ;-p >>> >>> >>> >>> >>> >>> On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill < >>> stevengil...@gmail.com > >> wrote: >>> Y
Re: new meta data for plugin.xml
XML is also buying us a couple of small but nice features, such as optionally wrapping tags with a tag or (potentially) a tag, etc. That functionality would not be expressed as cleanly with JSON, so its not a pure win to move away from XML. Add to that the fact that we are already perceived to change stuff way too often for no due cause, I just really don't see the value. On Mon, Oct 21, 2013 at 9:28 AM, Ian Clelland wrote: > I suspect that it is because plugin.xml was derived (intellectually, if not > literally) from config.xml, which was an XML file because of the W3C > Widgets spec, which we tried to adhere to. > > Whether that spec is still relevant (there doesn't seem to be a lot of > vendor interest in it (speaking as an Apache member, *not* as a vendor > representative)) is definitely up for debate. There probably are some gains > to be made in switching to a JSON config format, given how much of the > project is JavaScript these days, but it might not be worth all of the work > it would take to do it. > > Ian > > > On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist >wrote: > > > Perhaps this has been brought up before, but why are we using an xml > > file? why not make it a json file. > > > > Plugman is written in node( js ) so why not have the plugin "config" file > > in it's native format. This will probably save a bit of code since the > xml > > is converted to an object to manipulate anyway. > > > > > > i know this is a little off topic. > > > > thoughts? > > > > On Oct 18, 2013, at 5:31 PM, Steven Gill wrote: > > > > > I have created an issue to keep track of the registry refactor. > > > https://issues.apache.org/jira/browse/CB-5130 > > > > > > > > > On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI > > wrote: > > > > > >> I added some validation for plugin names (to follow > > >> reverse-domain-name convention) a couple of weeks ago but there needs > > >> to be more of it for sure. > > >> > > >> On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill > > > >> wrote: > > >>> I have created an issue to track the meta tag addition. > > >>> https://issues.apache.org/jira/browse/CB-5128 > > >>> > > >>> I agree with doing validation with plugman during publish time. We > > should > > >>> decide soon which ones are going to be mandatory and which ones will > be > > >>> optional. Probably update the plugin spec + our docs around creating > > >>> plugins as well. > > >>> > > >>> > > >>> > > >>> On Fri, Oct 18, 2013 at 11:54 AM, Shazron wrote: > > >>> > > Perhaps either plugman or the registry should do some validation, > and > > >> have > > some "required" fields? I know that PhoneGap Build when you try to > > >> submit a > > plugin they error out if you are missing some fields that they > > require. > > > > > > On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan < > > gorkem.er...@gmail.com > > > wrote: > > > > > +1 for adding metadata but should more of the metadata be > compulsory? > > > > > > JBoss tools plugin discovery uses the cordova.io registry and some > > >> of > > the > > > plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a > > >> screenshot > > > that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot > of > > >> a > > few > > > plugins that has most of its data. As you can see with the missing > > > descriptions etc. it is not possible to do an informed decision on > > whether > > > to use a plugin or not. Although information such as keywords does > > not > > seem > > > like important it becomes quite useful when you are trying to find > a > > > certain plugin. > > > -- > > > Gorkem > > > > > > > > > On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny > > > wrote: > > > > > >> +1 to repo / issue / website / docs etc metadata > > >> > > >> -1 *for now* to dependencies at specific versions, and testing > > >> related > > >> changes like , just because its not clear what the right > > >> solution > > > to > > >> these problems is. We do need to address it, but those topics > will > > > likely > > >> move to separate discussions. > > >> > > >> > > >> On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist < > > >> lholm...@redhat.com > > >>> wrote: > > >> > > >>> i was just thinking the same thing :) > > >>> On Oct 18, 2013, at 12:06 PM, Carlos Santana < > > >> csantan...@gmail.com> > > >> wrote: > > >>> > > plugin.xml metadata is looking more and more like a package.json > > > (i.e. > > >>> npm) > > ;-p > > > > > > > > > > > > On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill < > > stevengil...@gmail.com > > >> > > >>> wrote: > > > > > Yes I meant plugins.xml > > > > > > > > > > > >> On Oct 18, 2013, at 5:43 AM, Lucas Holmquist < > > lholm...@redhat.com>
Re: new meta data for plugin.xml
I suspect that it is because plugin.xml was derived (intellectually, if not literally) from config.xml, which was an XML file because of the W3C Widgets spec, which we tried to adhere to. Whether that spec is still relevant (there doesn't seem to be a lot of vendor interest in it (speaking as an Apache member, *not* as a vendor representative)) is definitely up for debate. There probably are some gains to be made in switching to a JSON config format, given how much of the project is JavaScript these days, but it might not be worth all of the work it would take to do it. Ian On Mon, Oct 21, 2013 at 8:35 AM, Lucas Holmquist wrote: > Perhaps this has been brought up before, but why are we using an xml > file? why not make it a json file. > > Plugman is written in node( js ) so why not have the plugin "config" file > in it's native format. This will probably save a bit of code since the xml > is converted to an object to manipulate anyway. > > > i know this is a little off topic. > > thoughts? > > On Oct 18, 2013, at 5:31 PM, Steven Gill wrote: > > > I have created an issue to keep track of the registry refactor. > > https://issues.apache.org/jira/browse/CB-5130 > > > > > > On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI > wrote: > > > >> I added some validation for plugin names (to follow > >> reverse-domain-name convention) a couple of weeks ago but there needs > >> to be more of it for sure. > >> > >> On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill > >> wrote: > >>> I have created an issue to track the meta tag addition. > >>> https://issues.apache.org/jira/browse/CB-5128 > >>> > >>> I agree with doing validation with plugman during publish time. We > should > >>> decide soon which ones are going to be mandatory and which ones will be > >>> optional. Probably update the plugin spec + our docs around creating > >>> plugins as well. > >>> > >>> > >>> > >>> On Fri, Oct 18, 2013 at 11:54 AM, Shazron wrote: > >>> > Perhaps either plugman or the registry should do some validation, and > >> have > some "required" fields? I know that PhoneGap Build when you try to > >> submit a > plugin they error out if you are missing some fields that they > require. > > > On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan < > gorkem.er...@gmail.com > > wrote: > > > +1 for adding metadata but should more of the metadata be compulsory? > > > > JBoss tools plugin discovery uses the cordova.io registry and some > >> of > the > > plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a > >> screenshot > > that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot of > >> a > few > > plugins that has most of its data. As you can see with the missing > > descriptions etc. it is not possible to do an informed decision on > whether > > to use a plugin or not. Although information such as keywords does > not > seem > > like important it becomes quite useful when you are trying to find a > > certain plugin. > > -- > > Gorkem > > > > > > On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny > wrote: > > > >> +1 to repo / issue / website / docs etc metadata > >> > >> -1 *for now* to dependencies at specific versions, and testing > >> related > >> changes like , just because its not clear what the right > >> solution > > to > >> these problems is. We do need to address it, but those topics will > > likely > >> move to separate discussions. > >> > >> > >> On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist < > >> lholm...@redhat.com > >>> wrote: > >> > >>> i was just thinking the same thing :) > >>> On Oct 18, 2013, at 12:06 PM, Carlos Santana < > >> csantan...@gmail.com> > >> wrote: > >>> > plugin.xml metadata is looking more and more like a package.json > > (i.e. > >>> npm) > ;-p > > > > > > On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill < > stevengil...@gmail.com > >> > >>> wrote: > > > Yes I meant plugins.xml > > > > > > > >> On Oct 18, 2013, at 5:43 AM, Lucas Holmquist < > lholm...@redhat.com> > > wrote: > >> > >> > >>> On Oct 17, 2013, at 7:54 PM, Steven Gill < > stevengil...@gmail.com> > > wrote: > >>> > >>> So looks like want to to start including more data on > >>> http://plugins.cordova.io. > >>> > >>> Repo tag -> points to repo where plugin lives > >>> Issue tag -> points to issue tracker (with component for > >> jira) > >>> > >>> Testing related (can get discussed more in testing thread > >>> Mode tag -> to differentiate between testing mode and normal > mode > >>> JS module tag for test module > >>> > >>> Dependency related > >>> adding ve
Re: new meta data for plugin.xml
I believe the consensus at the time was to use XML since it is the format used in other cordova config files, making it easier for plugin developers to upgrade. Changing to json now would not be possible without breaking existing plugins or supporting both formats for a while. Not worth the effort in my opinion for a small improvement to maintainability. > >
Re: new meta data for plugin.xml
Perhaps this has been brought up before, but why are we using an xml file? why not make it a json file. Plugman is written in node( js ) so why not have the plugin "config" file in it's native format. This will probably save a bit of code since the xml is converted to an object to manipulate anyway. i know this is a little off topic. thoughts? On Oct 18, 2013, at 5:31 PM, Steven Gill wrote: > I have created an issue to keep track of the registry refactor. > https://issues.apache.org/jira/browse/CB-5130 > > > On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI wrote: > >> I added some validation for plugin names (to follow >> reverse-domain-name convention) a couple of weeks ago but there needs >> to be more of it for sure. >> >> On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill >> wrote: >>> I have created an issue to track the meta tag addition. >>> https://issues.apache.org/jira/browse/CB-5128 >>> >>> I agree with doing validation with plugman during publish time. We should >>> decide soon which ones are going to be mandatory and which ones will be >>> optional. Probably update the plugin spec + our docs around creating >>> plugins as well. >>> >>> >>> >>> On Fri, Oct 18, 2013 at 11:54 AM, Shazron wrote: >>> Perhaps either plugman or the registry should do some validation, and >> have some "required" fields? I know that PhoneGap Build when you try to >> submit a plugin they error out if you are missing some fields that they require. On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan wrote: > +1 for adding metadata but should more of the metadata be compulsory? > > JBoss tools plugin discovery uses the cordova.io registry and some >> of the > plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a >> screenshot > that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot of >> a few > plugins that has most of its data. As you can see with the missing > descriptions etc. it is not possible to do an informed decision on whether > to use a plugin or not. Although information such as keywords does not seem > like important it becomes quite useful when you are trying to find a > certain plugin. > -- > Gorkem > > > On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny wrote: > >> +1 to repo / issue / website / docs etc metadata >> >> -1 *for now* to dependencies at specific versions, and testing >> related >> changes like , just because its not clear what the right >> solution > to >> these problems is. We do need to address it, but those topics will > likely >> move to separate discussions. >> >> >> On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist < >> lholm...@redhat.com >>> wrote: >> >>> i was just thinking the same thing :) >>> On Oct 18, 2013, at 12:06 PM, Carlos Santana < >> csantan...@gmail.com> >> wrote: >>> plugin.xml metadata is looking more and more like a package.json > (i.e. >>> npm) ;-p On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill < stevengil...@gmail.com >> >>> wrote: > Yes I meant plugins.xml > > > >> On Oct 18, 2013, at 5:43 AM, Lucas Holmquist < lholm...@redhat.com> > wrote: >> >> >>> On Oct 17, 2013, at 7:54 PM, Steven Gill < stevengil...@gmail.com> > wrote: >>> >>> So looks like want to to start including more data on >>> http://plugins.cordova.io. >>> >>> Repo tag -> points to repo where plugin lives >>> Issue tag -> points to issue tracker (with component for >> jira) >>> >>> Testing related (can get discussed more in testing thread >>> Mode tag -> to differentiate between testing mode and normal mode >>> JS module tag for test module >>> >>> Dependency related >>> adding version number to dependency tags so they don't just >> grab >>> latest >>> always. Multiple approaches were discussed and this >> discussion >> should >>> probably happen in a new thread. >>> >>> Thoughts on above? Suggestions for other meta data we should look >> into >>> adding to config.xml? >> did you mean plugin.xml? >> > -- Carlos Santana >>> >>> >> > >>
Re: new meta data for plugin.xml
I have created an issue to keep track of the registry refactor. https://issues.apache.org/jira/browse/CB-5130 On Fri, Oct 18, 2013 at 2:04 PM, Anis KADRI wrote: > I added some validation for plugin names (to follow > reverse-domain-name convention) a couple of weeks ago but there needs > to be more of it for sure. > > On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill > wrote: > > I have created an issue to track the meta tag addition. > > https://issues.apache.org/jira/browse/CB-5128 > > > > I agree with doing validation with plugman during publish time. We should > > decide soon which ones are going to be mandatory and which ones will be > > optional. Probably update the plugin spec + our docs around creating > > plugins as well. > > > > > > > > On Fri, Oct 18, 2013 at 11:54 AM, Shazron wrote: > > > >> Perhaps either plugman or the registry should do some validation, and > have > >> some "required" fields? I know that PhoneGap Build when you try to > submit a > >> plugin they error out if you are missing some fields that they require. > >> > >> > >> On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan >> >wrote: > >> > >> > +1 for adding metadata but should more of the metadata be compulsory? > >> > > >> > JBoss tools plugin discovery uses the cordova.io registry and some > of > >> the > >> > plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a > screenshot > >> > that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot of > a > >> few > >> > plugins that has most of its data. As you can see with the missing > >> > descriptions etc. it is not possible to do an informed decision on > >> whether > >> > to use a plugin or not. Although information such as keywords does not > >> seem > >> > like important it becomes quite useful when you are trying to find a > >> > certain plugin. > >> > -- > >> > Gorkem > >> > > >> > > >> > On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny > >> wrote: > >> > > >> > > +1 to repo / issue / website / docs etc metadata > >> > > > >> > > -1 *for now* to dependencies at specific versions, and testing > related > >> > > changes like , just because its not clear what the right > solution > >> > to > >> > > these problems is. We do need to address it, but those topics will > >> > likely > >> > > move to separate discussions. > >> > > > >> > > > >> > > On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist < > lholm...@redhat.com > >> > > >wrote: > >> > > > >> > > > i was just thinking the same thing :) > >> > > > On Oct 18, 2013, at 12:06 PM, Carlos Santana < > csantan...@gmail.com> > >> > > wrote: > >> > > > > >> > > > > plugin.xml metadata is looking more and more like a package.json > >> > (i.e. > >> > > > npm) > >> > > > > ;-p > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill < > >> stevengil...@gmail.com > >> > > > >> > > > wrote: > >> > > > > > >> > > > >> Yes I meant plugins.xml > >> > > > >> > >> > > > >> > >> > > > >> > >> > > > >>> On Oct 18, 2013, at 5:43 AM, Lucas Holmquist < > >> lholm...@redhat.com> > >> > > > >> wrote: > >> > > > >>> > >> > > > >>> > >> > > > On Oct 17, 2013, at 7:54 PM, Steven Gill < > >> stevengil...@gmail.com> > >> > > > >> wrote: > >> > > > > >> > > > So looks like want to to start including more data on > >> > > > http://plugins.cordova.io. > >> > > > > >> > > > Repo tag -> points to repo where plugin lives > >> > > > Issue tag -> points to issue tracker (with component for > jira) > >> > > > > >> > > > Testing related (can get discussed more in testing thread > >> > > > Mode tag -> to differentiate between testing mode and normal > >> mode > >> > > > JS module tag for test module > >> > > > > >> > > > Dependency related > >> > > > adding version number to dependency tags so they don't just > grab > >> > > > latest > >> > > > always. Multiple approaches were discussed and this > discussion > >> > > should > >> > > > probably happen in a new thread. > >> > > > > >> > > > Thoughts on above? Suggestions for other meta data we should > >> look > >> > > into > >> > > > adding to config.xml? > >> > > > >>> did you mean plugin.xml? > >> > > > >>> > >> > > > >> > >> > > > > > >> > > > > > >> > > > > > >> > > > > -- > >> > > > > Carlos Santana > >> > > > > > >> > > > > >> > > > > >> > > > >> > > >> >
Re: new meta data for plugin.xml
I added some validation for plugin names (to follow reverse-domain-name convention) a couple of weeks ago but there needs to be more of it for sure. On Fri, Oct 18, 2013 at 11:59 AM, Steven Gill wrote: > I have created an issue to track the meta tag addition. > https://issues.apache.org/jira/browse/CB-5128 > > I agree with doing validation with plugman during publish time. We should > decide soon which ones are going to be mandatory and which ones will be > optional. Probably update the plugin spec + our docs around creating > plugins as well. > > > > On Fri, Oct 18, 2013 at 11:54 AM, Shazron wrote: > >> Perhaps either plugman or the registry should do some validation, and have >> some "required" fields? I know that PhoneGap Build when you try to submit a >> plugin they error out if you are missing some fields that they require. >> >> >> On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan > >wrote: >> >> > +1 for adding metadata but should more of the metadata be compulsory? >> > >> > JBoss tools plugin discovery uses the cordova.io registry and some of >> the >> > plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a screenshot >> > that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot of a >> few >> > plugins that has most of its data. As you can see with the missing >> > descriptions etc. it is not possible to do an informed decision on >> whether >> > to use a plugin or not. Although information such as keywords does not >> seem >> > like important it becomes quite useful when you are trying to find a >> > certain plugin. >> > -- >> > Gorkem >> > >> > >> > On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny >> wrote: >> > >> > > +1 to repo / issue / website / docs etc metadata >> > > >> > > -1 *for now* to dependencies at specific versions, and testing related >> > > changes like , just because its not clear what the right solution >> > to >> > > these problems is. We do need to address it, but those topics will >> > likely >> > > move to separate discussions. >> > > >> > > >> > > On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist > > > >wrote: >> > > >> > > > i was just thinking the same thing :) >> > > > On Oct 18, 2013, at 12:06 PM, Carlos Santana >> > > wrote: >> > > > >> > > > > plugin.xml metadata is looking more and more like a package.json >> > (i.e. >> > > > npm) >> > > > > ;-p >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill < >> stevengil...@gmail.com >> > > >> > > > wrote: >> > > > > >> > > > >> Yes I meant plugins.xml >> > > > >> >> > > > >> >> > > > >> >> > > > >>> On Oct 18, 2013, at 5:43 AM, Lucas Holmquist < >> lholm...@redhat.com> >> > > > >> wrote: >> > > > >>> >> > > > >>> >> > > > On Oct 17, 2013, at 7:54 PM, Steven Gill < >> stevengil...@gmail.com> >> > > > >> wrote: >> > > > >> > > > So looks like want to to start including more data on >> > > > http://plugins.cordova.io. >> > > > >> > > > Repo tag -> points to repo where plugin lives >> > > > Issue tag -> points to issue tracker (with component for jira) >> > > > >> > > > Testing related (can get discussed more in testing thread >> > > > Mode tag -> to differentiate between testing mode and normal >> mode >> > > > JS module tag for test module >> > > > >> > > > Dependency related >> > > > adding version number to dependency tags so they don't just grab >> > > > latest >> > > > always. Multiple approaches were discussed and this discussion >> > > should >> > > > probably happen in a new thread. >> > > > >> > > > Thoughts on above? Suggestions for other meta data we should >> look >> > > into >> > > > adding to config.xml? >> > > > >>> did you mean plugin.xml? >> > > > >>> >> > > > >> >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > Carlos Santana >> > > > > >> > > > >> > > > >> > > >> > >>
Re: new meta data for plugin.xml
I have created an issue to track the meta tag addition. https://issues.apache.org/jira/browse/CB-5128 I agree with doing validation with plugman during publish time. We should decide soon which ones are going to be mandatory and which ones will be optional. Probably update the plugin spec + our docs around creating plugins as well. On Fri, Oct 18, 2013 at 11:54 AM, Shazron wrote: > Perhaps either plugman or the registry should do some validation, and have > some "required" fields? I know that PhoneGap Build when you try to submit a > plugin they error out if you are missing some fields that they require. > > > On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan >wrote: > > > +1 for adding metadata but should more of the metadata be compulsory? > > > > JBoss tools plugin discovery uses the cordova.io registry and some of > the > > plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a screenshot > > that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot of a > few > > plugins that has most of its data. As you can see with the missing > > descriptions etc. it is not possible to do an informed decision on > whether > > to use a plugin or not. Although information such as keywords does not > seem > > like important it becomes quite useful when you are trying to find a > > certain plugin. > > -- > > Gorkem > > > > > > On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny > wrote: > > > > > +1 to repo / issue / website / docs etc metadata > > > > > > -1 *for now* to dependencies at specific versions, and testing related > > > changes like , just because its not clear what the right solution > > to > > > these problems is. We do need to address it, but those topics will > > likely > > > move to separate discussions. > > > > > > > > > On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist > > >wrote: > > > > > > > i was just thinking the same thing :) > > > > On Oct 18, 2013, at 12:06 PM, Carlos Santana > > > wrote: > > > > > > > > > plugin.xml metadata is looking more and more like a package.json > > (i.e. > > > > npm) > > > > > ;-p > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill < > stevengil...@gmail.com > > > > > > > wrote: > > > > > > > > > >> Yes I meant plugins.xml > > > > >> > > > > >> > > > > >> > > > > >>> On Oct 18, 2013, at 5:43 AM, Lucas Holmquist < > lholm...@redhat.com> > > > > >> wrote: > > > > >>> > > > > >>> > > > > On Oct 17, 2013, at 7:54 PM, Steven Gill < > stevengil...@gmail.com> > > > > >> wrote: > > > > > > > > So looks like want to to start including more data on > > > > http://plugins.cordova.io. > > > > > > > > Repo tag -> points to repo where plugin lives > > > > Issue tag -> points to issue tracker (with component for jira) > > > > > > > > Testing related (can get discussed more in testing thread > > > > Mode tag -> to differentiate between testing mode and normal > mode > > > > JS module tag for test module > > > > > > > > Dependency related > > > > adding version number to dependency tags so they don't just grab > > > > latest > > > > always. Multiple approaches were discussed and this discussion > > > should > > > > probably happen in a new thread. > > > > > > > > Thoughts on above? Suggestions for other meta data we should > look > > > into > > > > adding to config.xml? > > > > >>> did you mean plugin.xml? > > > > >>> > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > > Carlos Santana > > > > > > > > > > > > > > > > > > >
Re: new meta data for plugin.xml
Perhaps either plugman or the registry should do some validation, and have some "required" fields? I know that PhoneGap Build when you try to submit a plugin they error out if you are missing some fields that they require. On Fri, Oct 18, 2013 at 11:50 AM, Gorkem Ercan wrote: > +1 for adding metadata but should more of the metadata be compulsory? > > JBoss tools plugin discovery uses the cordova.io registry and some of the > plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a screenshot > that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot of a few > plugins that has most of its data. As you can see with the missing > descriptions etc. it is not possible to do an informed decision on whether > to use a plugin or not. Although information such as keywords does not seem > like important it becomes quite useful when you are trying to find a > certain plugin. > -- > Gorkem > > > On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny wrote: > > > +1 to repo / issue / website / docs etc metadata > > > > -1 *for now* to dependencies at specific versions, and testing related > > changes like , just because its not clear what the right solution > to > > these problems is. We do need to address it, but those topics will > likely > > move to separate discussions. > > > > > > On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist > >wrote: > > > > > i was just thinking the same thing :) > > > On Oct 18, 2013, at 12:06 PM, Carlos Santana > > wrote: > > > > > > > plugin.xml metadata is looking more and more like a package.json > (i.e. > > > npm) > > > > ;-p > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill > > > > wrote: > > > > > > > >> Yes I meant plugins.xml > > > >> > > > >> > > > >> > > > >>> On Oct 18, 2013, at 5:43 AM, Lucas Holmquist > > > >> wrote: > > > >>> > > > >>> > > > On Oct 17, 2013, at 7:54 PM, Steven Gill > > > >> wrote: > > > > > > So looks like want to to start including more data on > > > http://plugins.cordova.io. > > > > > > Repo tag -> points to repo where plugin lives > > > Issue tag -> points to issue tracker (with component for jira) > > > > > > Testing related (can get discussed more in testing thread > > > Mode tag -> to differentiate between testing mode and normal mode > > > JS module tag for test module > > > > > > Dependency related > > > adding version number to dependency tags so they don't just grab > > > latest > > > always. Multiple approaches were discussed and this discussion > > should > > > probably happen in a new thread. > > > > > > Thoughts on above? Suggestions for other meta data we should look > > into > > > adding to config.xml? > > > >>> did you mean plugin.xml? > > > >>> > > > >> > > > > > > > > > > > > > > > > -- > > > > Carlos Santana > > > > > > > > > > > > >
Re: new meta data for plugin.xml
+1 for adding metadata but should more of the metadata be compulsory? JBoss tools plugin discovery uses the cordova.io registry and some of the plugins are missing a lot to. http://snag.gy/aAxjL.jpg is a screenshot that shows how the case. http://snag.gy/J8rl6.jpg is a screenshot of a few plugins that has most of its data. As you can see with the missing descriptions etc. it is not possible to do an informed decision on whether to use a plugin or not. Although information such as keywords does not seem like important it becomes quite useful when you are trying to find a certain plugin. -- Gorkem On Fri, Oct 18, 2013 at 1:12 PM, Michal Mocny wrote: > +1 to repo / issue / website / docs etc metadata > > -1 *for now* to dependencies at specific versions, and testing related > changes like , just because its not clear what the right solution to > these problems is. We do need to address it, but those topics will likely > move to separate discussions. > > > On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist >wrote: > > > i was just thinking the same thing :) > > On Oct 18, 2013, at 12:06 PM, Carlos Santana > wrote: > > > > > plugin.xml metadata is looking more and more like a package.json (i.e. > > npm) > > > ;-p > > > > > > > > > > > > > > > > > > On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill > > wrote: > > > > > >> Yes I meant plugins.xml > > >> > > >> > > >> > > >>> On Oct 18, 2013, at 5:43 AM, Lucas Holmquist > > >> wrote: > > >>> > > >>> > > On Oct 17, 2013, at 7:54 PM, Steven Gill > > >> wrote: > > > > So looks like want to to start including more data on > > http://plugins.cordova.io. > > > > Repo tag -> points to repo where plugin lives > > Issue tag -> points to issue tracker (with component for jira) > > > > Testing related (can get discussed more in testing thread > > Mode tag -> to differentiate between testing mode and normal mode > > JS module tag for test module > > > > Dependency related > > adding version number to dependency tags so they don't just grab > > latest > > always. Multiple approaches were discussed and this discussion > should > > probably happen in a new thread. > > > > Thoughts on above? Suggestions for other meta data we should look > into > > adding to config.xml? > > >>> did you mean plugin.xml? > > >>> > > >> > > > > > > > > > > > > -- > > > Carlos Santana > > > > > > > >
Re: new meta data for plugin.xml
+1 to repo / issue / website / docs etc metadata -1 *for now* to dependencies at specific versions, and testing related changes like , just because its not clear what the right solution to these problems is. We do need to address it, but those topics will likely move to separate discussions. On Fri, Oct 18, 2013 at 12:24 PM, Lucas Holmquist wrote: > i was just thinking the same thing :) > On Oct 18, 2013, at 12:06 PM, Carlos Santana wrote: > > > plugin.xml metadata is looking more and more like a package.json (i.e. > npm) > > ;-p > > > > > > > > > > > > On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill > wrote: > > > >> Yes I meant plugins.xml > >> > >> > >> > >>> On Oct 18, 2013, at 5:43 AM, Lucas Holmquist > >> wrote: > >>> > >>> > On Oct 17, 2013, at 7:54 PM, Steven Gill > >> wrote: > > So looks like want to to start including more data on > http://plugins.cordova.io. > > Repo tag -> points to repo where plugin lives > Issue tag -> points to issue tracker (with component for jira) > > Testing related (can get discussed more in testing thread > Mode tag -> to differentiate between testing mode and normal mode > JS module tag for test module > > Dependency related > adding version number to dependency tags so they don't just grab > latest > always. Multiple approaches were discussed and this discussion should > probably happen in a new thread. > > Thoughts on above? Suggestions for other meta data we should look into > adding to config.xml? > >>> did you mean plugin.xml? > >>> > >> > > > > > > > > -- > > Carlos Santana > > > >
Re: new meta data for plugin.xml
i was just thinking the same thing :) On Oct 18, 2013, at 12:06 PM, Carlos Santana wrote: > plugin.xml metadata is looking more and more like a package.json (i.e. npm) > ;-p > > > > > > On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill wrote: > >> Yes I meant plugins.xml >> >> >> >>> On Oct 18, 2013, at 5:43 AM, Lucas Holmquist >> wrote: >>> >>> On Oct 17, 2013, at 7:54 PM, Steven Gill >> wrote: So looks like want to to start including more data on http://plugins.cordova.io. Repo tag -> points to repo where plugin lives Issue tag -> points to issue tracker (with component for jira) Testing related (can get discussed more in testing thread Mode tag -> to differentiate between testing mode and normal mode JS module tag for test module Dependency related adding version number to dependency tags so they don't just grab latest always. Multiple approaches were discussed and this discussion should probably happen in a new thread. Thoughts on above? Suggestions for other meta data we should look into adding to config.xml? >>> did you mean plugin.xml? >>> >> > > > > -- > Carlos Santana >
Re: new meta data for plugin.xml
plugin.xml metadata is looking more and more like a package.json (i.e. npm) ;-p On Fri, Oct 18, 2013 at 11:40 AM, Steve Gill wrote: > Yes I meant plugins.xml > > > > > On Oct 18, 2013, at 5:43 AM, Lucas Holmquist > wrote: > > > > > >> On Oct 17, 2013, at 7:54 PM, Steven Gill > wrote: > >> > >> So looks like want to to start including more data on > >> http://plugins.cordova.io. > >> > >> Repo tag -> points to repo where plugin lives > >> Issue tag -> points to issue tracker (with component for jira) > >> > >> Testing related (can get discussed more in testing thread > >> Mode tag -> to differentiate between testing mode and normal mode > >> JS module tag for test module > >> > >> Dependency related > >> adding version number to dependency tags so they don't just grab latest > >> always. Multiple approaches were discussed and this discussion should > >> probably happen in a new thread. > >> > >> Thoughts on above? Suggestions for other meta data we should look into > >> adding to config.xml? > > did you mean plugin.xml? > > > -- Carlos Santana
Re: new meta data for plugin.xml
Yes I meant plugins.xml > On Oct 18, 2013, at 5:43 AM, Lucas Holmquist wrote: > > >> On Oct 17, 2013, at 7:54 PM, Steven Gill wrote: >> >> So looks like want to to start including more data on >> http://plugins.cordova.io. >> >> Repo tag -> points to repo where plugin lives >> Issue tag -> points to issue tracker (with component for jira) >> >> Testing related (can get discussed more in testing thread >> Mode tag -> to differentiate between testing mode and normal mode >> JS module tag for test module >> >> Dependency related >> adding version number to dependency tags so they don't just grab latest >> always. Multiple approaches were discussed and this discussion should >> probably happen in a new thread. >> >> Thoughts on above? Suggestions for other meta data we should look into >> adding to config.xml? > did you mean plugin.xml? >
Re: new meta data for plugin.xml
Website should show the README.md that is a sibling of the plugin.xml file. On Fri, Oct 18, 2013 at 10:56 AM, Lucas Holmquist wrote: > > On Oct 17, 2013, at 7:54 PM, Steven Gill wrote: > > > So looks like want to to start including more data on > > http://plugins.cordova.io. > > > > Repo tag -> points to repo where plugin lives > > Issue tag -> points to issue tracker (with component for jura) > +1 for these, > > > > > > Testing related (can get discussed more in testing thread > > Mode tag -> to differentiate between testing mode and normal mode > > JS module tag for test module > > > > Dependency related > > adding version number to dependency tags so they don't just grab latest > > always. Multiple approaches were discussed and this discussion should > > probably happen in a new thread. > > > > Thoughts on above? Suggestions for other meta data we should look into > > adding to config.xml? > >
Re: new meta data for plugin.xml
+1 for canonical repo location and Issue tracker (where available) Other metadata that could be useful on the repo interface: Description (1 line summary; possibly also a short 1 or 2 paragraph description as well) Docs link (if applicable) Home page link (if applicable) Author (I know it's supposed to be there, but I can't find it anywhere) Some kind of verified author field, I think, is going to be important for ensuring that malicious plugins don't get uploaded in the org.apache.cordova namespace, masquerading as official plugins. On Fri, Oct 18, 2013 at 10:56 AM, Lucas Holmquist wrote: > > On Oct 17, 2013, at 7:54 PM, Steven Gill wrote: > > > So looks like want to to start including more data on > > http://plugins.cordova.io. > > > > Repo tag -> points to repo where plugin lives > > Issue tag -> points to issue tracker (with component for jura) > +1 for these, > > > > > > Testing related (can get discussed more in testing thread > > Mode tag -> to differentiate between testing mode and normal mode > > JS module tag for test module > > > > Dependency related > > adding version number to dependency tags so they don't just grab latest > > always. Multiple approaches were discussed and this discussion should > > probably happen in a new thread. > > > > Thoughts on above? Suggestions for other meta data we should look into > > adding to config.xml? > >
Re: new meta data for plugin.xml
On Oct 17, 2013, at 7:54 PM, Steven Gill wrote: > So looks like want to to start including more data on > http://plugins.cordova.io. > > Repo tag -> points to repo where plugin lives > Issue tag -> points to issue tracker (with component for jura) +1 for these, > > Testing related (can get discussed more in testing thread > Mode tag -> to differentiate between testing mode and normal mode > JS module tag for test module > > Dependency related > adding version number to dependency tags so they don't just grab latest > always. Multiple approaches were discussed and this discussion should > probably happen in a new thread. > > Thoughts on above? Suggestions for other meta data we should look into > adding to config.xml?
Re: new meta data for plugin.xml
This thread is about what info is displayed on plugins.cordova.io Sent from my iPhone > On Oct 18, 2013, at 5:43 AM, Lucas Holmquist wrote: > > >> On Oct 17, 2013, at 7:54 PM, Steven Gill wrote: >> >> So looks like want to to start including more data on >> http://plugins.cordova.io. >> >> Repo tag -> points to repo where plugin lives >> Issue tag -> points to issue tracker (with component for jira) >> >> Testing related (can get discussed more in testing thread >> Mode tag -> to differentiate between testing mode and normal mode >> JS module tag for test module >> >> Dependency related >> adding version number to dependency tags so they don't just grab latest >> always. Multiple approaches were discussed and this discussion should >> probably happen in a new thread. >> >> Thoughts on above? Suggestions for other meta data we should look into >> adding to config.xml? > did you mean plugin.xml? >
Re: new meta data for plugin.xml
On Oct 17, 2013, at 7:54 PM, Steven Gill wrote: > So looks like want to to start including more data on > http://plugins.cordova.io. > > Repo tag -> points to repo where plugin lives > Issue tag -> points to issue tracker (with component for jira) > > Testing related (can get discussed more in testing thread > Mode tag -> to differentiate between testing mode and normal mode > JS module tag for test module > > Dependency related > adding version number to dependency tags so they don't just grab latest > always. Multiple approaches were discussed and this discussion should > probably happen in a new thread. > > Thoughts on above? Suggestions for other meta data we should look into > adding to config.xml? did you mean plugin.xml?
Re: new meta data for plugin.xml
Those two sound more like things the info command should be printing. Or do you mean those should be part of plugins.Cordova.io? On Oct 17, 2013 8:38 PM, "purplecabbage" wrote: > + list platforms supported for each plugin > + list all plugins available for a platform > > Sent from my iPhone > > > On Oct 17, 2013, at 4:54 PM, Steven Gill wrote: > > > > So looks like want to to start including more data on > > http://plugins.cordova.io. > > > > Repo tag -> points to repo where plugin lives > > Issue tag -> points to issue tracker (with component for jira) > > > > Testing related (can get discussed more in testing thread > > Mode tag -> to differentiate between testing mode and normal mode > > JS module tag for test module > > > > Dependency related > > adding version number to dependency tags so they don't just grab latest > > always. Multiple approaches were discussed and this discussion should > > probably happen in a new thread. > > > > Thoughts on above? Suggestions for other meta data we should look into > > adding to config.xml? >
Re: new meta data for plugin.xml
+ list platforms supported for each plugin + list all plugins available for a platform Sent from my iPhone > On Oct 17, 2013, at 4:54 PM, Steven Gill wrote: > > So looks like want to to start including more data on > http://plugins.cordova.io. > > Repo tag -> points to repo where plugin lives > Issue tag -> points to issue tracker (with component for jira) > > Testing related (can get discussed more in testing thread > Mode tag -> to differentiate between testing mode and normal mode > JS module tag for test module > > Dependency related > adding version number to dependency tags so they don't just grab latest > always. Multiple approaches were discussed and this discussion should > probably happen in a new thread. > > Thoughts on above? Suggestions for other meta data we should look into > adding to config.xml?
new meta data for plugin.xml
So looks like want to to start including more data on http://plugins.cordova.io. Repo tag -> points to repo where plugin lives Issue tag -> points to issue tracker (with component for jira) Testing related (can get discussed more in testing thread Mode tag -> to differentiate between testing mode and normal mode JS module tag for test module Dependency related adding version number to dependency tags so they don't just grab latest always. Multiple approaches were discussed and this discussion should probably happen in a new thread. Thoughts on above? Suggestions for other meta data we should look into adding to config.xml?
