Why version number in package?

<rage>
Why is the version number included in the package for net.server.minecraft.* packages?
</rage>

I know Mojang did this, not CraftBukkit. It just makes it very VERY difficult to do many things with bukkit and make your plugin compatible with multiple versions of bukkit.

Case in point: NBT Tags: Why isn't there a wrapper for NBT Tags? To add a tag to an item, I must reference the specific version of Minecraft. Then when I compile, my Plugin only works with that version. So I have to maintain dozens of versions of my plugins for each version of CraftBukkit..

Sigh...

 

javaguy78 You could learn how to use reflection to use that methods without having to update your plugin when a new craftbukkit comes out!

 

This was done to "force" developers to have a look at their plugins that use CraftBukkit or NMS code at least on every major update.
It was meant as kind of a "safeguard" for the server owners. So they (in theory) can assume, that plugins which use methods outside of the official Bukki API are thoroughly verified by the developer to be 100% compatible with a certain CraftBukkit game server version.
Seach in the news for the original thread. The intention was explained there in detail.

 

Read this thread: http://forums.bukkit.org/threads/sa...cked-and-potentially-damaging-plugins.116749/

 

Check out the ItemMeta system.

 

That's fine, but that still makes it difficult for a developer to support both the recommended build and a snapshot build. I guess I'll only have 2 versions of my plugins: 1 that is old and is compatible with the recommended build, and one that is cutting-edge, but only available against the snapshot.

Makes my users upset though to not have both, and it's a pain in the neck to find/replace all the .v1_5_R1 with v1_5_R2 every time I want to compile...

I haven't found out a way to use the ItemMeta system to add a glow effect to an item without adding an enchantment. :\

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

You can easily use reflection to get around it.

Example:

Code:java

 
 
package me.zeus.test;
 
 
import java.lang.reflect.Method;
 
import org.bukkit.plugin.java.JavaPlugin;
 
 
 
public class Test extends JavaPlugin
{
 
 
@Override
public void onEnable()
{
ClassLoader cl = ClassLoader.getSystemClassLoader();
 
try
{
Class<?> village = cl.loadClass("net.minecraft.server." + getVersion() + ".Village");
for (Method m : village.getMethods())
{
System.out.println(m.getName() + "\n");
}
}
catch (ClassNotFoundException | SecurityException e)
{
e.printStackTrace();
}
 
}
 
 
 
public String getVersion()
{
String ver = getServer().getClass().getPackage().getName();
return ver.substring(ver.lastIndexOf('.') + 1);
}
}
 

 

You can make your own enchantment like I did in backpacks++ or you can use packets or ... Comphenix knows, he is the packet master of bukkit so...

 

That is, as far as we can tell, a bug and not something we would support because of how easily it could disappear.

 

Why, thank you.

This is how I would do it with ProtocolLib:

Code:java

public class ExamplePlugin extends JavaPlugin {
    @Override
    public boolean onCommand(CommandSender sender, Command command, String label, String[] args) {
        if (!(sender instanceof Player)) {
            sender.sendMessage(ChatColor.RED + "Must be a player.");
        }
        Player player = (Player) sender;
 
        ItemStack goldenAxe = MinecraftReflection.getBukkitItemStack(new ItemStack(Material.GOLD_AXE));
        NbtCompound compound = (NbtCompound) NbtFactory.fromItemTag(goldenAxe);
        compound.put(NbtFactory.ofList("ench"));
 
        player.getInventory().addItem(goldenAxe);
        return true;
    }
}

And yes, you can do it without depending on ProtocolLib. I leave that as an exercise to the reader.

EDIT: And yes, as mbaxter mentioned, this effect can easily disappear, usually if some other plugin uses the ItemMeta system on the same stack. That occurs even if the plugin leaves the enchantment list alone.

 

Why? 1: You made protocollib, 2: You mostly help on packet stuff and 3: You are the only one here who seems to exactly know what he's doing with packets...
Thats why sir.

 

Also, BUKKIT needs to get their naming conventions down. The current Recommended build is version 1.5.2 R1.0, but in the package path, it says v1_5_R3... Now, tell me how that's not going to confuse my users?

 

How would that confuse your users? Just tell them which version it supports. They don't need to know and don't care which imports you used...

 

so, you're saying it doesn't matter if internal version numbers don't match external version numbers? What's the point of putting r3 internally if externally the file says R1.0?

 

The "3" there means that this is the third obfuscation revision since Minecraft 1.5 was released. Whenever the MC server's obfuscation changes, the package number is bumped by one. This is actually better for plugin devs than tracking Minecraft's major/minor version directly, since the minor version can increase (and has increased) without an obfuscation change. No point in changing the package version if the obfuscation hasn't changed.

As ShadowDog007 correctly pointed out, the internal package name used by CraftBukkit is of absolutely no concern to plugin users, who only need to know which version(s) of CraftBukkit (e.g. 1.5.2-R1.0) your plugin works with, and that's something you should be stating on your plugin download page anyway.