Jesse, while the config.xml's share the same name, I think that input/output argument is invalid. All of: defaults.xml, plugin.xml, and application level config (sadly named config.xml) are all inputs with slightly different specs that produce several platform level configs (named config.xml) also with a slightly different spec.
The fact that the project level config.xml uses <feature/> tag is a valid argument to consider (I hadn't considered it), I just wanted to correct the specific reasoning since I think this naming situation bites us repeatedly into making mistakes. -Michal On Wed, Apr 23, 2014 at 12:35 AM, purplecabbage <purplecabb...@gmail.com>wrote: > I think consistency with input and output config.xml files makes more > sense than consistency with plugin.xml. So +1 <feature/> > > Sent from my iPhone > > > On Apr 22, 2014, at 8:06 PM, Gorkem Ercan <gorkem.er...@gmail.com> > wrote: > > > >> On Tue, Apr 22, 2014 at 8:44 PM, Andrew Grieve <agri...@chromium.org> > wrote: > >> > >> Anis - Gorkem wants <feature> since it works with his IDE. *Why* do > >> you prefer <feature>? > > Just to be clear I am not trying to push for <feature> because it works > on > > the JBoss/Eclipse IDE now. I do not mind ripping it apart and > implementing > > a new editor if there is a good benefit. However I favor <feature> > because > > it allows validation and content assist due to its XSD (I think we have > > discussed about this earlier) which is probably the only benefit of the > xml > > markup on a configuration file these days. > > > > If we use dependency for defining the plugins to be restored it does not > > mean that <feature> magically disappears. It is still used by the > platform > > runtimes and therefore the CLI generated config.xml files. I guess that > > would mean we still need to keep the documentation etc for it around. > > > > Also one thing that I have noticed when implementing the restore for > > plugins because all the information is given as <param>s under feature it > > is very easily extendible. For instance if someday we want to support > > enterprise plugin registries, we could just add <param name="registry" > > value="http://registry.acme.corp"; /> and use the value on the > > implementation. Same could be done to dependency by adding another > > attribute which would break the validations etc. > > > > > > > >>> On Tue, Apr 22, 2014 at 6:56 PM, Anis KADRI <anis.ka...@gmail.com> > wrote: > >>> I prefer <feature>. > >>> > >>> > >>>> On Tue, Apr 22, 2014 at 11:41 AM, Mark Koudritsky <kam...@google.com> > >>> wrote: > >>> > >>>> I prefer the <dependency> syntax. It's shorter, more intuitive and > >>>> consistent with plugin.xml. I don't see much value in _partial_ > >> compliance > >>>> with the w3c spec. > >>>> > >>>> > >>>> On Tue, Apr 22, 2014 at 1:31 PM, Michal Mocny <mmo...@google.com> > >> wrote: > >>>> > >>>>> Gorkem is adding awesome feature to restore plugins/platforms your > app > >>>>> depends on. There is some debate on the correct syntax to use in the > >>>>> config.xml file: do we use (a) plugin.xml style <dependency> tags, or > >> (b) > >>>>> w3c widget spec <feature> tags? > >>>>> > >>>>> Gorkem votes (b), arguing that using widget spec helps his tools with > >>>>> editing config.xml (existing gui editor, I assume?), and has > >> implemented > >>>> a > >>>>> PR for it (https://github.com/apache/cordova-cli/pull/165). > >>>>> > >>>>> I vote (a), arguing that we already don't match widget spec, and > >> already > >>>>> have established syntax for for specifying plugin urls & versions in > >>>>> plugin.xml (with docs and examples), and its better for our CLI > >>>>> implementation to use existing plugin deps handlers. > >>>>> > >>>>> What do you think? > >>>>> > >>>>> Background: read full thread titled "[GitHub] cordova-cli pull > >> request: > >>>>> CB-6469" > >> >
