You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Andrew Grieve <ag...@chromium.org> on 2013/09/19 19:38:43 UTC
Change plugin IDs from "org.cordova.core.FOO" -> "org.cordova.FOO"
Anis and I discussed a bit on https://issues.apache.org/jira/browse/CB-4493
So I filed https://issues.apache.org/jira/browse/CB-4874
Wanted to see if anyone could think of what adverse effects this might have
before going through with it.
Only thing I can think of is that I'd need to update the <dependency> tags
of all plugins (mobile spec and our own). The result of not updating them
isn't horrible since the dependencies still install via URL.
On a related note - we need remove the url= parameter from the <dependency>
so that it looks to the registry.
Once we discuss / take one of these paths, I'd like to do a plugins release
so that we can test this flow with RC1.
RE: Change plugin IDs from "org.cordova.core.FOO" ->
"org.cordova.FOO"
Posted by "jbondc@openmv.com" <jb...@openmv.com>.
On Fri Sep 20 10:11 AM, Michal Mocny wrote:
> Yeah, but not sure how best to do so.
>
> Do we have a way to mark plugins as deprecated? Crazy idea: upload a
> nearly
> empty version under the old plugin name that <depends> on the
> new one, and
> add a <deprecated> type tag to plugin.xml spec?
>
It sort of brings us back to "required" vs. "non-required" dependency:
https://issues.apache.org/jira/browse/CB-4735
I think you'd end up with:
> plugin list
org.cordova.core.FOO
org.cordova.FOO
My pref would be to 'break stuff' then have a placeholder for deprecated plugin ids.
All we really want here is way to resolve "org.cordova.core.FOO" --> "org.cordova.FOO" for backwards compatibility.
Harmony proposal calls this step resolve(),lots of similarity :
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders
Having a way to register aliases or alternative ids/names could be useful in some sort of 'resolve' step.
Re: Change plugin IDs from "org.cordova.core.FOO" -> "org.cordova.FOO"
Posted by Andrew Grieve <ag...@chromium.org>.
On Fri, Sep 20, 2013 at 2:28 PM, Michal Mocny <mm...@chromium.org> wrote:
> When updating platforms, I think we re-install already-installed-plugins,
> right? Should make sure that that doesn't lead to annoying warning chain
> and/or broken workspace.
>
Braden just added the "platform update" command two days ago, and all it
does is call the platform's "update" script. It doesn't touch your plugins.
Probably we should do some checks to ensure your plugins are compatible,
and maybe suggest updating plugins, but we don't have any of that right now.
>
> Also, solution seems hacky. What don't you like my crazy idea to change
> old plugin to <depend> on new version? ;)
>
Might be a bit confusing to "plugin ls" and see two copies of each plugin,
where one of them you can't uninstall because it's depended on.
>
> -Michal
>
>
> On Fri, Sep 20, 2013 at 2:16 PM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > The current way to upgrade your plugin is:
> > cordova plugin rm old.plugin.id
> > cordova plugin add new.plugin.id
> >
> > Maybe we could just add a check in plugman that when it sees "plugin add
> > org.cordova.core", we print a message telling them to omit ".core"
> >
> >
> > On Fri, Sep 20, 2013 at 10:11 AM, Michal Mocny <mm...@chromium.org>
> > wrote:
> >
> > > Yeah, but not sure how best to do so.
> > >
> > > Do we have a way to mark plugins as deprecated? Crazy idea: upload a
> > > nearly empty version under the old plugin name that <depends> on the
> new
> > > one, and add a <deprecated> type tag to plugin.xml spec?
> > >
> > > -Michal
> > >
> > >
> > > On Fri, Sep 20, 2013 at 6:53 AM, Michael Brooks <
> > michael@michaelbrooks.ca
> > > >wrote:
> > >
> > > > >
> > > > > We don't upgrade plugins as part of platform upgrade anyway, do we?
> > > > Still,
> > > > > its a good point that we may want to map these to newer versions.
> > > >
> > > >
> > > > Good point.
> > > >
> > > > Regardless, we want to ease the upgrade path of these core plugins.
> > It'll
> > > > just annoy users if we change the plugin IDs are hide these changes
> > away
> > > in
> > > > our documentation.
> > > >
> > > > Michael
> > > >
> > > >
> > > > On Fri, Sep 20, 2013 at 6:18 AM, Michal Mocny <mm...@chromium.org>
> > > wrote:
> > > >
> > > > > We don't upgrade plugins as part of platform upgrade anyway, do we?
> > > > Still,
> > > > > its a good point that we may want to map these to newer versions.
> > > > >
> > > > > One option could be to leave the old names registered in the plugin
> > > > > registry for a while, and mark deprecated somehow (and perhaps not
> > make
> > > > > them visible from website?), but I think Andrew mentioned that
> > > > installing a
> > > > > plugin from registry using one canonical name and having its
> > plugin.xml
> > > > > specify a different canonical name meant our tools broke (fail to
> > > > > uninstall?). Perhaps we should just fix that.
> > > > >
> > > > > -Michal
> > > > >
> > > > >
> > > > > On Fri, Sep 20, 2013 at 1:18 AM, Michael Brooks <
> > > > michael@michaelbrooks.ca
> > > > > >wrote:
> > > > >
> > > > > > I prefer the shortened plugin IDs as well.
> > > > > >
> > > > > > Will we want each platform's upgrade script aware of these names
> in
> > > > order
> > > > > > to ease the upgrade path from 3.0.0-3.1.0?
> > > > > >
> > > > > >
> > > > > > On Thu, Sep 19, 2013 at 10:38 AM, Andrew Grieve <
> > > agrieve@chromium.org
> > > > > > >wrote:
> > > > > >
> > > > > > > Anis and I discussed a bit on
> > > > > > > https://issues.apache.org/jira/browse/CB-4493
> > > > > > >
> > > > > > > So I filed https://issues.apache.org/jira/browse/CB-4874
> > > > > > >
> > > > > > > Wanted to see if anyone could think of what adverse effects
> this
> > > > might
> > > > > > have
> > > > > > > before going through with it.
> > > > > > >
> > > > > > > Only thing I can think of is that I'd need to update the
> > > <dependency>
> > > > > > tags
> > > > > > > of all plugins (mobile spec and our own). The result of not
> > > updating
> > > > > them
> > > > > > > isn't horrible since the dependencies still install via URL.
> > > > > > >
> > > > > > > On a related note - we need remove the url= parameter from the
> > > > > > <dependency>
> > > > > > > so that it looks to the registry.
> > > > > > >
> > > > > > > Once we discuss / take one of these paths, I'd like to do a
> > plugins
> > > > > > release
> > > > > > > so that we can test this flow with RC1.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Change plugin IDs from "org.cordova.core.FOO" -> "org.cordova.FOO"
Posted by Michal Mocny <mm...@chromium.org>.
When updating platforms, I think we re-install already-installed-plugins,
right? Should make sure that that doesn't lead to annoying warning chain
and/or broken workspace.
Also, solution seems hacky. What don't you like my crazy idea to change
old plugin to <depend> on new version? ;)
-Michal
On Fri, Sep 20, 2013 at 2:16 PM, Andrew Grieve <ag...@chromium.org> wrote:
> The current way to upgrade your plugin is:
> cordova plugin rm old.plugin.id
> cordova plugin add new.plugin.id
>
> Maybe we could just add a check in plugman that when it sees "plugin add
> org.cordova.core", we print a message telling them to omit ".core"
>
>
> On Fri, Sep 20, 2013 at 10:11 AM, Michal Mocny <mm...@chromium.org>
> wrote:
>
> > Yeah, but not sure how best to do so.
> >
> > Do we have a way to mark plugins as deprecated? Crazy idea: upload a
> > nearly empty version under the old plugin name that <depends> on the new
> > one, and add a <deprecated> type tag to plugin.xml spec?
> >
> > -Michal
> >
> >
> > On Fri, Sep 20, 2013 at 6:53 AM, Michael Brooks <
> michael@michaelbrooks.ca
> > >wrote:
> >
> > > >
> > > > We don't upgrade plugins as part of platform upgrade anyway, do we?
> > > Still,
> > > > its a good point that we may want to map these to newer versions.
> > >
> > >
> > > Good point.
> > >
> > > Regardless, we want to ease the upgrade path of these core plugins.
> It'll
> > > just annoy users if we change the plugin IDs are hide these changes
> away
> > in
> > > our documentation.
> > >
> > > Michael
> > >
> > >
> > > On Fri, Sep 20, 2013 at 6:18 AM, Michal Mocny <mm...@chromium.org>
> > wrote:
> > >
> > > > We don't upgrade plugins as part of platform upgrade anyway, do we?
> > > Still,
> > > > its a good point that we may want to map these to newer versions.
> > > >
> > > > One option could be to leave the old names registered in the plugin
> > > > registry for a while, and mark deprecated somehow (and perhaps not
> make
> > > > them visible from website?), but I think Andrew mentioned that
> > > installing a
> > > > plugin from registry using one canonical name and having its
> plugin.xml
> > > > specify a different canonical name meant our tools broke (fail to
> > > > uninstall?). Perhaps we should just fix that.
> > > >
> > > > -Michal
> > > >
> > > >
> > > > On Fri, Sep 20, 2013 at 1:18 AM, Michael Brooks <
> > > michael@michaelbrooks.ca
> > > > >wrote:
> > > >
> > > > > I prefer the shortened plugin IDs as well.
> > > > >
> > > > > Will we want each platform's upgrade script aware of these names in
> > > order
> > > > > to ease the upgrade path from 3.0.0-3.1.0?
> > > > >
> > > > >
> > > > > On Thu, Sep 19, 2013 at 10:38 AM, Andrew Grieve <
> > agrieve@chromium.org
> > > > > >wrote:
> > > > >
> > > > > > Anis and I discussed a bit on
> > > > > > https://issues.apache.org/jira/browse/CB-4493
> > > > > >
> > > > > > So I filed https://issues.apache.org/jira/browse/CB-4874
> > > > > >
> > > > > > Wanted to see if anyone could think of what adverse effects this
> > > might
> > > > > have
> > > > > > before going through with it.
> > > > > >
> > > > > > Only thing I can think of is that I'd need to update the
> > <dependency>
> > > > > tags
> > > > > > of all plugins (mobile spec and our own). The result of not
> > updating
> > > > them
> > > > > > isn't horrible since the dependencies still install via URL.
> > > > > >
> > > > > > On a related note - we need remove the url= parameter from the
> > > > > <dependency>
> > > > > > so that it looks to the registry.
> > > > > >
> > > > > > Once we discuss / take one of these paths, I'd like to do a
> plugins
> > > > > release
> > > > > > so that we can test this flow with RC1.
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Change plugin IDs from "org.cordova.core.FOO" -> "org.cordova.FOO"
Posted by Andrew Grieve <ag...@chromium.org>.
The current way to upgrade your plugin is:
cordova plugin rm old.plugin.id
cordova plugin add new.plugin.id
Maybe we could just add a check in plugman that when it sees "plugin add
org.cordova.core", we print a message telling them to omit ".core"
On Fri, Sep 20, 2013 at 10:11 AM, Michal Mocny <mm...@chromium.org> wrote:
> Yeah, but not sure how best to do so.
>
> Do we have a way to mark plugins as deprecated? Crazy idea: upload a
> nearly empty version under the old plugin name that <depends> on the new
> one, and add a <deprecated> type tag to plugin.xml spec?
>
> -Michal
>
>
> On Fri, Sep 20, 2013 at 6:53 AM, Michael Brooks <michael@michaelbrooks.ca
> >wrote:
>
> > >
> > > We don't upgrade plugins as part of platform upgrade anyway, do we?
> > Still,
> > > its a good point that we may want to map these to newer versions.
> >
> >
> > Good point.
> >
> > Regardless, we want to ease the upgrade path of these core plugins. It'll
> > just annoy users if we change the plugin IDs are hide these changes away
> in
> > our documentation.
> >
> > Michael
> >
> >
> > On Fri, Sep 20, 2013 at 6:18 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> > > We don't upgrade plugins as part of platform upgrade anyway, do we?
> > Still,
> > > its a good point that we may want to map these to newer versions.
> > >
> > > One option could be to leave the old names registered in the plugin
> > > registry for a while, and mark deprecated somehow (and perhaps not make
> > > them visible from website?), but I think Andrew mentioned that
> > installing a
> > > plugin from registry using one canonical name and having its plugin.xml
> > > specify a different canonical name meant our tools broke (fail to
> > > uninstall?). Perhaps we should just fix that.
> > >
> > > -Michal
> > >
> > >
> > > On Fri, Sep 20, 2013 at 1:18 AM, Michael Brooks <
> > michael@michaelbrooks.ca
> > > >wrote:
> > >
> > > > I prefer the shortened plugin IDs as well.
> > > >
> > > > Will we want each platform's upgrade script aware of these names in
> > order
> > > > to ease the upgrade path from 3.0.0-3.1.0?
> > > >
> > > >
> > > > On Thu, Sep 19, 2013 at 10:38 AM, Andrew Grieve <
> agrieve@chromium.org
> > > > >wrote:
> > > >
> > > > > Anis and I discussed a bit on
> > > > > https://issues.apache.org/jira/browse/CB-4493
> > > > >
> > > > > So I filed https://issues.apache.org/jira/browse/CB-4874
> > > > >
> > > > > Wanted to see if anyone could think of what adverse effects this
> > might
> > > > have
> > > > > before going through with it.
> > > > >
> > > > > Only thing I can think of is that I'd need to update the
> <dependency>
> > > > tags
> > > > > of all plugins (mobile spec and our own). The result of not
> updating
> > > them
> > > > > isn't horrible since the dependencies still install via URL.
> > > > >
> > > > > On a related note - we need remove the url= parameter from the
> > > > <dependency>
> > > > > so that it looks to the registry.
> > > > >
> > > > > Once we discuss / take one of these paths, I'd like to do a plugins
> > > > release
> > > > > so that we can test this flow with RC1.
> > > > >
> > > >
> > >
> >
>
Re: Change plugin IDs from "org.cordova.core.FOO" -> "org.cordova.FOO"
Posted by Michal Mocny <mm...@chromium.org>.
Yeah, but not sure how best to do so.
Do we have a way to mark plugins as deprecated? Crazy idea: upload a
nearly empty version under the old plugin name that <depends> on the new
one, and add a <deprecated> type tag to plugin.xml spec?
-Michal
On Fri, Sep 20, 2013 at 6:53 AM, Michael Brooks <mi...@michaelbrooks.ca>wrote:
> >
> > We don't upgrade plugins as part of platform upgrade anyway, do we?
> Still,
> > its a good point that we may want to map these to newer versions.
>
>
> Good point.
>
> Regardless, we want to ease the upgrade path of these core plugins. It'll
> just annoy users if we change the plugin IDs are hide these changes away in
> our documentation.
>
> Michael
>
>
> On Fri, Sep 20, 2013 at 6:18 AM, Michal Mocny <mm...@chromium.org> wrote:
>
> > We don't upgrade plugins as part of platform upgrade anyway, do we?
> Still,
> > its a good point that we may want to map these to newer versions.
> >
> > One option could be to leave the old names registered in the plugin
> > registry for a while, and mark deprecated somehow (and perhaps not make
> > them visible from website?), but I think Andrew mentioned that
> installing a
> > plugin from registry using one canonical name and having its plugin.xml
> > specify a different canonical name meant our tools broke (fail to
> > uninstall?). Perhaps we should just fix that.
> >
> > -Michal
> >
> >
> > On Fri, Sep 20, 2013 at 1:18 AM, Michael Brooks <
> michael@michaelbrooks.ca
> > >wrote:
> >
> > > I prefer the shortened plugin IDs as well.
> > >
> > > Will we want each platform's upgrade script aware of these names in
> order
> > > to ease the upgrade path from 3.0.0-3.1.0?
> > >
> > >
> > > On Thu, Sep 19, 2013 at 10:38 AM, Andrew Grieve <agrieve@chromium.org
> > > >wrote:
> > >
> > > > Anis and I discussed a bit on
> > > > https://issues.apache.org/jira/browse/CB-4493
> > > >
> > > > So I filed https://issues.apache.org/jira/browse/CB-4874
> > > >
> > > > Wanted to see if anyone could think of what adverse effects this
> might
> > > have
> > > > before going through with it.
> > > >
> > > > Only thing I can think of is that I'd need to update the <dependency>
> > > tags
> > > > of all plugins (mobile spec and our own). The result of not updating
> > them
> > > > isn't horrible since the dependencies still install via URL.
> > > >
> > > > On a related note - we need remove the url= parameter from the
> > > <dependency>
> > > > so that it looks to the registry.
> > > >
> > > > Once we discuss / take one of these paths, I'd like to do a plugins
> > > release
> > > > so that we can test this flow with RC1.
> > > >
> > >
> >
>
Re: Change plugin IDs from "org.cordova.core.FOO" -> "org.cordova.FOO"
Posted by Michael Brooks <mi...@michaelbrooks.ca>.
>
> We don't upgrade plugins as part of platform upgrade anyway, do we? Still,
> its a good point that we may want to map these to newer versions.
Good point.
Regardless, we want to ease the upgrade path of these core plugins. It'll
just annoy users if we change the plugin IDs are hide these changes away in
our documentation.
Michael
On Fri, Sep 20, 2013 at 6:18 AM, Michal Mocny <mm...@chromium.org> wrote:
> We don't upgrade plugins as part of platform upgrade anyway, do we? Still,
> its a good point that we may want to map these to newer versions.
>
> One option could be to leave the old names registered in the plugin
> registry for a while, and mark deprecated somehow (and perhaps not make
> them visible from website?), but I think Andrew mentioned that installing a
> plugin from registry using one canonical name and having its plugin.xml
> specify a different canonical name meant our tools broke (fail to
> uninstall?). Perhaps we should just fix that.
>
> -Michal
>
>
> On Fri, Sep 20, 2013 at 1:18 AM, Michael Brooks <michael@michaelbrooks.ca
> >wrote:
>
> > I prefer the shortened plugin IDs as well.
> >
> > Will we want each platform's upgrade script aware of these names in order
> > to ease the upgrade path from 3.0.0-3.1.0?
> >
> >
> > On Thu, Sep 19, 2013 at 10:38 AM, Andrew Grieve <agrieve@chromium.org
> > >wrote:
> >
> > > Anis and I discussed a bit on
> > > https://issues.apache.org/jira/browse/CB-4493
> > >
> > > So I filed https://issues.apache.org/jira/browse/CB-4874
> > >
> > > Wanted to see if anyone could think of what adverse effects this might
> > have
> > > before going through with it.
> > >
> > > Only thing I can think of is that I'd need to update the <dependency>
> > tags
> > > of all plugins (mobile spec and our own). The result of not updating
> them
> > > isn't horrible since the dependencies still install via URL.
> > >
> > > On a related note - we need remove the url= parameter from the
> > <dependency>
> > > so that it looks to the registry.
> > >
> > > Once we discuss / take one of these paths, I'd like to do a plugins
> > release
> > > so that we can test this flow with RC1.
> > >
> >
>
Re: Change plugin IDs from "org.cordova.core.FOO" -> "org.cordova.FOO"
Posted by Michal Mocny <mm...@chromium.org>.
We don't upgrade plugins as part of platform upgrade anyway, do we? Still,
its a good point that we may want to map these to newer versions.
One option could be to leave the old names registered in the plugin
registry for a while, and mark deprecated somehow (and perhaps not make
them visible from website?), but I think Andrew mentioned that installing a
plugin from registry using one canonical name and having its plugin.xml
specify a different canonical name meant our tools broke (fail to
uninstall?). Perhaps we should just fix that.
-Michal
On Fri, Sep 20, 2013 at 1:18 AM, Michael Brooks <mi...@michaelbrooks.ca>wrote:
> I prefer the shortened plugin IDs as well.
>
> Will we want each platform's upgrade script aware of these names in order
> to ease the upgrade path from 3.0.0-3.1.0?
>
>
> On Thu, Sep 19, 2013 at 10:38 AM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > Anis and I discussed a bit on
> > https://issues.apache.org/jira/browse/CB-4493
> >
> > So I filed https://issues.apache.org/jira/browse/CB-4874
> >
> > Wanted to see if anyone could think of what adverse effects this might
> have
> > before going through with it.
> >
> > Only thing I can think of is that I'd need to update the <dependency>
> tags
> > of all plugins (mobile spec and our own). The result of not updating them
> > isn't horrible since the dependencies still install via URL.
> >
> > On a related note - we need remove the url= parameter from the
> <dependency>
> > so that it looks to the registry.
> >
> > Once we discuss / take one of these paths, I'd like to do a plugins
> release
> > so that we can test this flow with RC1.
> >
>
Re: Change plugin IDs from "org.cordova.core.FOO" -> "org.cordova.FOO"
Posted by Michael Brooks <mi...@michaelbrooks.ca>.
I prefer the shortened plugin IDs as well.
Will we want each platform's upgrade script aware of these names in order
to ease the upgrade path from 3.0.0-3.1.0?
On Thu, Sep 19, 2013 at 10:38 AM, Andrew Grieve <ag...@chromium.org>wrote:
> Anis and I discussed a bit on
> https://issues.apache.org/jira/browse/CB-4493
>
> So I filed https://issues.apache.org/jira/browse/CB-4874
>
> Wanted to see if anyone could think of what adverse effects this might have
> before going through with it.
>
> Only thing I can think of is that I'd need to update the <dependency> tags
> of all plugins (mobile spec and our own). The result of not updating them
> isn't horrible since the dependencies still install via URL.
>
> On a related note - we need remove the url= parameter from the <dependency>
> so that it looks to the registry.
>
> Once we discuss / take one of these paths, I'd like to do a plugins release
> so that we can test this flow with RC1.
>