https://github.com/SpongePowered/SpongeAPI/pull/1081 introduced qualified plugin ids (org.spongepowered.mymod) in addition to the existing unqualified plugin ids (mymod). The original reasoning (which I cannot find a reference to now) was that there can be multiple plugins with the same ID -- qualified plugin ids don't fix that at all, I can just create two plugins with the same qualified id.
Plugin ids should be unique - if there are two with the same ID then the authors should be slapped. Introducing qualified plugin ids just makes things more complex - commands can be super long (/org.spongepowered.example.flardians:flardians instead of /flardians:flardians) for example.
Commands are already additionally aliased to the unqualified plugin ID, so that is not really a big problem.
The actual question is not really if they affect usage, but rather if they're actually really necessary. Most usage "problems" can be bypassed using different ways, for example, for the configuration directories I recently suggested actually disallowing two plugins with the same unqualified plugin ID to load at the same time, which would basically result in the following:
@Minecrell: I don't think that they're really necessary. As @kashike said, having two plugins with the same name is a problem in itself. Conflicting ids are merely a symptom of the underlying issue, and having non-conflicting ids only allows people to ignore the issue.
I also don't feel that fully qualified ids add any real additional clarity. Unless someone has worked on a particular plugin, they most likely won't be aware of its underlying package name. The result it that the plugin id is made longer, but doesn't make it any easier for a human to identify which plugin it's actually referring to.
I'm in agreement with @kashike and @Aaron1011 here. I also voiced my concerns regarding this change but we ultimately went forward.
Looking out where we are now and were, I've come across no advantage to fully qualified names. It seems the system was made to fix a problem that ultimately isn't one since plugin devs and admins alike are aware that sometimes people use the same names and handle it accordingly. For the peeps that haven't, we're talking MAYBE 2% of the entire install base in the history of Minecraft modding that have had an issue with how things have been.
While Sponge sets out to do things differently (and ideally better) this is a great example of where the previous way of doing things _just makes sense_
@Minecrell
As far as Ore needing these for maven resolution, we can easily either...
A. Read the namespace their plugin uses from the jar or...
B. Have you provide the namespace for maven resolution in your project's properties on Ore.
With the above options, I've yet again expelled any sensible reason for qualified ids.
@Zidane I kind of agree with you, just wanted to say they're not "completely useless".
Maybe @Mumfrey wants to share his views here, since he was the one who originally suggested supporting this.
I recently posted an issue on SpongeCommon that partially is caused by FQDN plugin IDs. Since they necessarily include ., problems arise when the plugin ID is used to disambiguate custom data stored in a DataContainer. Ideally the plugin ID would be kept as a single entry, but many data storage methods use . as a separator of paths causing the plugin ID to be expanded. The linked issue provides some examples.
I agree with @Zidane on changing this back how it used to be. Plugins shouldn't be forced on naming their id's a specific way. If it was such an issue, FML would be having a ton of problems with all the mods they have but no such problems exist. Not even Bukkit had this requirement and those plugins have been fine.
@Minecrell @Zidane: What's the status of that branch?
@Aaron1011 It is done, just needs a proper annoucement on the forum so everyone knows our recommendation was changed.
oh yay here we go again... @Minecrell I already prepared myself for this but I reckon that most devs are not gonna be happy about this one.
So are we waiting for such a change in 4.1?
@liach no its for 5.x.x
@kinggoesgaming No, qualified plugin IDs will stay supported, we just change our recommendation which is not a breaking change.
ah thats good :smile:
Most helpful comment
I agree with @Zidane on changing this back how it used to be. Plugins shouldn't be forced on naming their id's a specific way. If it was such an issue, FML would be having a ton of problems with all the mods they have but no such problems exist. Not even Bukkit had this requirement and those plugins have been fine.