Resource Denial - What should be shaded?

Discussion in 'Spigot Plugin Development' started by DarkKnights22, Oct 8, 2019.

  1. My new resource got denied because of the following:
    upload_2019-10-8_16-33-45.png
    My shading is set like this:
    upload_2019-10-8_16-33-34.png
    I don't see the problem, I have always shaded like this and Spigot or anyone else have said this is incorrect.
    My packages and classes are as follows:
    upload_2019-10-8_16-35-4.png
    Please let me know what I am doing wrong, thanks.
     
  2. What you have there, looks right, but maybe something else is shading in.

    I recommending building your jar, then decompiling it, either by unzipping it, or throwing it in JD-GUI/Luyten to see what is all being compiled.
    I dont have your jar file (obviously) so I cant see, but Im going to guess something is maybe inadvertently being shaded in, that doesnt show up in your IDE
     
  3. upload_2019-10-8_20-15-12.png
    Don't see anything unusual apart from expiringmap
     
  4. electronicboy

    IRC Staff

    > com.wasteofplastic
    I would imagine that that is what they're talking about
     
  5. I shade askyblock into my plugin as I hook into it, what's bad about that?
     
  6. Choco

    Moderator

    I also see "org" in there. Be sure you're not accidentally shading the Bukkit API or CraftBukkit into your resource as well. Really, you should only be shading what won't be available at runtime (i.e. non-plugins / libraries not supplied by the server)

    You're distributing Skyblock. If it's running on the server, it will be present. Shading it is meaningless. It should be a dependency (or a soft dependency if optional), not a shaded into your resource for redistribution.
     
  7. Thing is, I don't shade askyblock
     
  8. Choco

    Moderator

    And anything that shouldn't be in your plugin. You should treat shading as a last resort for something that will not be present on the server at any given time. Libraries such as Aikar's Command Framework is not a plugin and will never be on the server unless supplied by a plugin. Not to mention that if it is supplied by another plugin and you've not relocated it, you're going to run into some conflicts with other plugins also not relocating it.

    Thread moved to Spigot Plugin Development and updated title.
     
  9. I don't shade askyblock though:
    upload_2019-10-8_20-34-9.png
     
  10. Choco

    Moderator

    As far as I'm aware, the annotations you'll be using are going to be compile-time annotations. There shouldn't be any reason to shade those either. I highly advise you take the time to learn the difference between compile time and runtime and what is and is not necessary to be shaded by Maven.
     
  11. I don't shade those in though lol
     
  12. Choco

    Moderator

    Maven's shade plugin will, by default, shade anything that is not set to <scope>provided</scope> in its dependency declaration. You're likely depending on various libraries including JetBrains annotations, ASkyblock, so on and so forth and they're being automatically shaded because the default scope is "compile". Either configure the shade plugin to explicitly declare what should be included in the final jar (recommended), or declare a scope in each dependency.
     
  13. electronicboy

    IRC Staff

    relocations are relocations, they don't define what is and isn't shaded, check your maven build log
     
  14. Oh sugar, ofc :p thanks
     
  15. upload_2019-10-8_20-44-48.png
    This ok now?
     
  16. As choco already explained with the shading/maven, here is a good example:

    Screen Shot 2019-10-08 at 12.43.19 PM.png

    (sorry the image is so big)

    You have acf shaded into your package, but you also have it again at the top "co.aikar".
    Im sure you are aware by now that you accidentally shaded more in than you intended.

    I recommend in the future always checking your jar by decompiling it and seeing what actually makes it into the plugin.
     
  17. Oops, yeh ok. So apart from acf, it's all good @Choco ?
     
  18. Looks good, I’d recommend posting your pom.xml here though, so we can double check it. Not sure why no one else has requested it yet, would have made this process a lot simpler.