Libs folder

[AlfieC]

Could we add a libs folder? I mean, it's somewhat simple to do w/ the classpath but less experienced users won't know how to figure out what the main class is.

[MiniDigger]

do you mean for building the project (compile time libs) or libs that get used in plugins (run time libs)? I am assuming you are talking about the latter one. Don't think that this is needed since most developers shade their libs into the plugin or provide lib plugins.

[AlfieC]

Runtime libs. This would prevent me having to shade MongoDB 10 different times if I have 10 plugins that use it. I suppose that it's specific to be, to be honest; but alas it could make workflow smoother.

[MiniDigger]

problem is: different plugin developers will build against different lib versions and all of a sudden the user needs to administer the libs their plugins use. and what whappens if a plugin devs decides so upgrade a lib? this would just not work out. you can do it for your own setup tho, like you mentioned, using the classpath argument

[sgdc3]

best solution would be to start using a dependency manager that downloads and manages multiple libs versions automatically

[MrPowerGamerBR]

@AlfieC create a empty plugin and shade MongoDB on it, done. (That's what I do)

[sgdc3]

Maybe the bukkit world should start thinking about a plugin manager like Sponge's ore. In my opinion Bukkit is way better than Sponge, but it should add some new features and tools.

[phase]

That's a lot to ask. A lib folder could be useful, but a lib plugin gets the job done with only one or two more classes.

[AlfieC]

If I'm testing a plugin for example, compiling (without Maven) in my IDE is faster than maven - but it won't include any dependencies. A libs folder would allow me to just put, for example, the Mongo driver in there and consider it done.

[Techcable]

What would be nice would be the capability to specify maven libs in plugin.yml, which can be loaded onto a plugins classpath automatically. Due to the way java's classloaders work, we can make it so other plugins wouldn't see the dependency and different plugins can use different versions of the same library. It wouldn't be that difficult, assuming we stick to releases-only, and it wouldn't add much overhead either, since we could cache the dependencies in the local maven repo.

For now, I say we should not handle transitive dependencies, as that over-complicates the implementation and leads to unnecessary confusion.

Here's an example:

maven-dependencies:
    # Database connection pooling
    - 'com.zaxxer::HikariCP::2.4.7'
    # MongoDB is webscale better than /dev/null
    - 'org.mongodb::mongo-java-driver::3.0.0'
    # I need a newer version of guava
    # Assuming we implement this properly, this will override bukkit's builtin version
    - 'com.google.guava::guava::19.0'

[sgdc3]

@Techcable Great idea! :)

[sgdc3]

@Techcable What about adding also custom repos?

[Techcable]

@sgdc3 That'd probably be needed too, since it's pretty hard to get into maven central.

[DenWav]

I really really dislike the idea of the server handling dependency management. Just shade the lib in the jar and everyone's happy, the extra bulk isn't a real problem.

[sgdc3]

@DemonWav bukkit needs such features, in my opinion it is becoming an "old generation" api

[sgdc3]

The api should be easy to use, complex maven relocation are usually configured in the wrong way.

[sgdc3]

@DemonWav what's the issue with that? Security? I really don't understand your point of view.

[Deamon5550]

You'll need to mirror maven central somewhere, they got pretty annoyed at the traffic coming from forge before they mirrored it.

[sgdc3]

really? damn apache servers xD

[MiniDigger]

@sgdc3 I think I outlined very clearly why the server should not do the dependency management. This has nothing to do with bukkit becoming an "old generation api". I don't see any gain from this other then a few mb storage saved but I see a he'll lot of problems and work for the team. Just not worth it.

[sgdc3]

What about sponge's Ore then?

[DenWav]

Sponge's Ore is totally different from what you're suggesting. They provide plugin hosting such doubles as a pseudo Maven repo, but you still have to shade your libs. Bukkit is an old and outdated and generally bad API, but this isn't an example why. And yeah, Forge did the same thing and pissed off a lot of people, they ended up having to host it themselves.

[sgdc3]

I don't want to emulate Sponge, i was trying to say that Sponge is offering cool new features while bukkit/spigot is only updating to next minecraft versions.

[MiniDigger]

paper adds new cool stuff if its worth the work of implementing and maintaining. don't see how a whole dependency manager would fulfill that criterium

[AlfieC]

Maybe we could have plugin-specific libs folders? Or a hierarchy where all in the base "libs" folder would be available to all plugins but if I put, say, a new Guava in libs/WorldGuard it would become available to WorldGuard only.

[MiniDigger]

then whats the benefit over normal shading?

[AlfieC]

Faster development - wouldn't have to shade for every test build.

On 8 Sep 2016, at 20:45, MiniDigger notifications@github.com wrote:

then whats the benefit over normal shading?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Ichbinjoe]

So then what is stopping using the classpath method for development then running the shade target for release? On Thu, Sep 8, 2016 at 16:33 AlfieC notifications@github.com wrote:

Faster development - wouldn't have to shade for every test build.

On 8 Sep 2016, at 20:45, MiniDigger notifications@github.com wrote:

then whats the benefit over normal shading?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/PaperMC/Paper/issues/412#issuecomment-245731085, or mute the thread https://github.com/notifications/unsubscribe-auth/AC9UqQi5YopypTNCYn5d4FUh-tPbD3S1ks5qoHEMgaJpZM4J1Nfg .

Joseph Hirschfeld joe@ibj.io Ichbinjoe Skype: ichbinjoehirschfeld

[MiniDigger]

@AlfieC is compile time really that big of a deal for you? just ran some tests and even tho shade is way slower then normal it doesn't really justify such a big change in paper. tested a multi module maven project (10 modules) that shade ~20 libs into the final jar (the modules and some other dependencies) and compile time was ~13s with shade vs 6s without (3 tests, forced recompile, 4 threads) idk how many recompiles you need to make per hours (hotswapping can drastically reduce that ;) ) but for me it's pretty much a non factor.

[phase]

Having travis build it for you makes compile time irrelevant. Just set it up add artifacts to the git tags and wait a couple minutes (if it's that big).

Instead of changing distribution, we should be changing how we develop plugins. I don't know everything IntelliJ can do, but setting up a hotswapping plugin on the server would solve the problem for shading during development.

@sgdc3 at least google things before you comment them. Ore is Sponge's version of BukkitDev (give or take). If we really wanedt to upgrade Bukkit, it wouldn't be that hard. Fixing up the API and implementation wouldn't be that hard. I think a Bukkit2 would be quite easy to do. @chibill has been working on generating mappings for the snapshots. A new implementation using these mappings would get rid of the (L?)GPL license on CraftBukkit. Bukkit is still GPL, but I think @PaperMC had some ways around linking it. I could be completely misinterpreting how Paperclip works.

[sgdc3]

@phase I know what Ore is, thanks.

[wgaylord]

I have a basic system for building mappings it still sucks a bit. (As I am still developing it) But I will drop my link here. https://github.com/Beta-Bukkit/Mappings

[aikar]

I think the concept would be best for server owners to use for their own stuff rather than something for plugin authors to push to use (since barely any plugin requires paper to begin with)

I know I shade in some deps to CB side because shading them in plugins makes /reload even riskier.

I've considered moving to a class path loading my self.

But can you even load 2 versions of same lib under 2 different class loaders and plugins stay within their own even with namespace conflicts?

Normally one would shade and relocate to avoid that. But most plugins arent even relocating their shaded deps, so any plugin running into version conflicts would already be a problem.

but we could drastically cut down on jar size by leaving out the mc internals that provide guava for example, and reference the vanilla jar instead to grab those.

[aikar]

though wed have to further reconsider build styles for that, as right now paperclip is optional (which I don't even use...) so I don't see my comment about moving minecraft-server out of the compiled jar being realistic in paper itself, but i could do that for my own server.

[zachbr]

I don't think this is actually going anywhere. After watching the discussion here I still don't see any compelling reason why we need to be handling this, rather than just letting plugin authors do it themselves, as they have been for quite some time now.

Implementing this does not modernize the API, it does not (arguably) make Paper a more attractive development platform, nor does really do anything other than be an interesting concept. It is an extremely marginal quality of life improvement for plugin authors at the cost of a lot more code (among other things) for us to maintain.

I would much rather us spend that same effort on the API or the implementation directly, rather than some moonshot like this. Which, again, while arguably a cool concept, starts to fall down when it comes to practicality and priority.