Solved "Best" way to get another plugin's file?

Discussion in 'Plugin Development' started by makskay, Oct 16, 2012.

Thread Status:
Not open for further replies.
  1. Offline

    makskay

    Seeing as JavaPlugin.getFile() is protected, is there a convenient or preferred way to go about getting another plugin's file, or is it just not good practice to try?

    (Quick edit to clear up potential ambiguity: I'm referring to the plugin file on disk, which is returned as a File instance by JavaPlugin.getFile().)
     
  2. Offline

    TwistedMexi

    I'm curious, what's the goal of this?
     
  3. Offline

    makskay

    TwistedMexi I'm building an auto-update utility that can support other plugins without forcing those plugins' authors to conform to a naming convention. In order to know what files to replace with their updated versions, I need to be able to figure out the name of the actual .jar file that each plugin is running out of.
     
  4. Offline

    TwistedMexi

    Perhaps I don't understand, but why not look at what the pl command is doing/tie into it? It returns all loaded plug-ins.
     
  5. Offline

    makskay

    I don't need the names or the JavaPlugin instances; it's trivial to obtain those by making calls to the PluginManager. Instead I'm trying to get the names of the actual files (i.e. "worldguard.jar" or "EssChat.jar") out of which these plugins are running.

    Thanks for the attempt though, as you're the only respondent so far - it seems that I've stumped the Bukkit forums too :)
     
  6. Offline

    TwistedMexi

    Right I understand what you're trying to do but I'm not sure as to why you're wanting the file vs the instances? What's the advantage? Since plug-in devs can change their jar name anytime as well?
     
  7. Offline

    makskay

    That is the advantage. If I'm able to dynamically grab the file name I can replace the existing plugin .jar, whatever it happens to be called on any given server or at any given moment, with a new version - rather than simply adding a new .jar alongside the one one, which'd likely cause all sorts of conflicts.
     
  8. Offline

    McLuke500

    I just use cbutd it works perfectly its craft bukkit up to date!
     
  9. Offline

    The_Coder

    Try this:
    Code:
    getServer().getPluginManager().getPlugin(/*enter name of plugin here*/);
     
  10. Offline

    makskay

    CBUTD is great for keeping CraftBukkit up to date, but if a plugin dev wants their plugin to be supported by CBUTD's automatic downloads, they have to add information to their plugin's plugin.yml. CBUTD's developer also states explicitly that he won't be supporting automatic installation of updates, only automatic downloads. I'm trying to build a more flexible alternative with extra features that doesn't require extra work on the part of plugin devs to support.

    As I mentioned above, I've got no problem obtaining JavaPlugin instances for each plugin (which is what the code you've posted does.) I am looking for a way to get the filename of the plugin .jar installed on the server on a per-plugin basis.

    --

    I may have come up with a solution to my own problem, although it's a bit hackish: iterating over all the .jar files in the server's /plugins directory and determining the plugin name each jar is associated with (by looking at the plugin.yml). I can build a map indexing file names by plugin names and go from there.

    If anyone has a more elegant solution, feel free to suggest it.

    [Edited: removed autocorrect typos]
     
  11. Offline

    sayaad

    makskay likes this.
  12. Offline

    makskay

    Now this is more like it - looks to be the ideal solution for this sort of problem. Thanks^^
     
  13. Offline

    hakelimopu

    This code is untested, but should give you the general idea of how it should look:

    Code:
             
    Class<?> theClass = thePlugin.getClass();
    Method theMethod = theClass.getDeclaredMethod("getFile");
    theMethod.setAccessible(true);
    File theFile = (File)theMethod.invoke(thePlugin);
    
    Oh, and there will be a try catch around it with a number of exceptions that can occur, but enjoy.
     
    makskay likes this.
  14. Offline

    McLuke500

    Sorry for late reply but for all my plugins I haven't added extra info but it alerts and downloads them for me when I update them. One thing I highly value from cbutd is the automatic download and but automatic updating it, as I always have to read the change logs that it also conviently downloads, it alerts me in game so that's convient and is just a great plugin. I would hate auto updating downloads as it could seriously damage the server from exploits, or permission nodes going out of date and or a serious change to the plugin, what if it alters the games mechanics and the change log says to only update on a new map or something like that, you need to read the change log!
    Anyway that's my rant over :D
     
  15. Offline

    makskay

    Your concerns are reasonable, and I feel obliged to post some justifications of my own system here.
    • My upcoming plugin manager is fully configurable. Don't like automatic updates? Feel free to disable them. Want to be notified when a plugin has an update available, before anything is downloaded? That's a configurable option too. You can set things up to only check for updates when an administrator runs a specific command, to automatically download but not install updates every time they become available... really, the sky's the limit.
    • My plugin manager can handle plugins more granularly than CBUTD. Server owners can configure, on a per-plugin basis, how updates for that plugin will occur: whether automatic update checks will be run; whether the plugin will automatically download detected updates, or wait for admin approval; whether downloaded updates will be automatically installed, or left in the downloads bin for an admin to manually swap out (with a configurable option to nag admins if they've got updates downloaded but not yet installed, again on a per-plugin basis.) Admins can even use a command to ready an already-downloaded plugin for installation on the next reload without ever touching the file system directly -- especially great for those people who like to do everything through the console or in-game chat.
    • Since my plugin manager will only handle BukkitDev-approved plugins, server administrators who don't mind unexpected gameplay changes will be able to enable automatic updates with relative peace of mind. Files uploaded to BukkitDev are vetted by Bukkit staff, who go over every plugin update with a fine-tooth comb to ensure there's no malicious code.
    • My plugin manager can be used to browse plugins on BukkitDev without downloading anything, and download + install a plugin that looks especially interesting or useful with a single command -- as before, without touching the filesystem or a web browser at all.
    You have a valid point about how CBUTD doesn't technically require extra work on the part of devs if they follow a certain naming convention with their BukkitDev uploads -- I missed that bit earlier, as I was only skimming the CBUTD docs to see whether I should give up on my own project before I got too far in ;)
     
  16. Offline

    McLuke500

    The downloading with commands would be cool, cbutd only handles bukkit dev plugins :D, ok your plugin will be good!
    A good idea would be to be able to use text scripts that is just a list of plugins such as likem20 essential plugins and the plugin user just adds that and it auto downloads them :D
     
  17. Offline

    WaterNode

    JD- GUI.
     
  18. Offline

    coldandtired

    getServer().getPluginManager().getPlugin("blah").getClass().getProtectionDomain().getCodeSource().getLocation().toURI();
     
    makskay likes this.
  19. Offline

    Lolmewn

    You could check every file in the plugins/ folder, see if they end with .jar , do stuff with em.
     
  20. Offline

    makskay

    Doesn't really have much to do with my question, as I never said anything about wanting to decompile other plugins and look at their source code -- though I can see how the title might be misleading.

    Looks interesting, I'll have to see how that stacks up against reflection. This might actually prove preferable.

    Yeah, that was the "quick and dirty" solution I mentioned above but ended up eschewing in favor of something a bit more elegant.
     
Thread Status:
Not open for further replies.

Share This Page