Paper: [RFC] Shade HikariCP into Paper

Created on 7 Apr 2016  Â·  11Comments  Â·  Source: PaperMC/Paper

Just felt like putting this on the table as a RFC (Request For Comment).

I think that it would be a good idea to include the HikariCP library into Paper.
This would make it so developers don't have to worry about shading it into their plugins.

input wanted

Most helpful comment

Black-Hole Said:

A library system would be much better.

This actually gave me an idea. What if inside of the plugin jar, there was a libs.yml file, or maybe just an entry in plugin.yml, that described to the server that libs it needs, which the server then goes and loads at runtime.

However, this would probably require a major overhaul to the way the server loads.
The load order would have to be:

  1. Read Plugins for Library Entries
  2. Download Required Libraries
  3. Start Server
  4. Load libs via custom loader
  5. Pre-World (Startup) Load Plugins
  6. Load/Gen World
  7. Post-World Load Plugins

Example Usage

libs:
  - com.zaxxer:HikariCP:2.4.5
  - org.json:json:20160212
  - ...

This is just a concept based on something that someone said \o/

Side Question: would libs passed in via classpath work close to the same way?

All 11 comments

:-1: This is something that should be left to plugins to provide, to be honest. Plugins use different database managers, and for the majority of people this is just going to make the Paper jar larger with no gain.

A library system would be much better. So the required libraries are downloaded by paper using maven. :)

This causes a backwards compatibility issue by overwriting classes which
may be of lower version. Unless we share it to com.paper or whatever, I
would have to say no
On Thu, Apr 7, 2016 at 6:11 PM Black Hole [email protected] wrote:

A library system would be much better. So the required libraries are
downloaded by paper using maven. :)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/PaperMC/Paper/issues/196#issuecomment-207111380

Joseph Hirschfeld
[email protected]
Ichbinjoe
Skype: ichbinjoehirschfeld

Unless we share it to com.paper or whatever

What do you mean by this?

s/share/shade

This causes a backwards compatibility issue by overwriting classes which
may be of lower version. Unless we share it to com.paper or whatever, I
would have to say no

and shading would cause "omg I can't find x.y package!" errors

ah, okay

Black-Hole Said:

A library system would be much better.

This actually gave me an idea. What if inside of the plugin jar, there was a libs.yml file, or maybe just an entry in plugin.yml, that described to the server that libs it needs, which the server then goes and loads at runtime.

However, this would probably require a major overhaul to the way the server loads.
The load order would have to be:

  1. Read Plugins for Library Entries
  2. Download Required Libraries
  3. Start Server
  4. Load libs via custom loader
  5. Pre-World (Startup) Load Plugins
  6. Load/Gen World
  7. Post-World Load Plugins

Example Usage

libs:
  - com.zaxxer:HikariCP:2.4.5
  - org.json:json:20160212
  - ...

This is just a concept based on something that someone said \o/

Side Question: would libs passed in via classpath work close to the same way?

That is just ridiculous.

This is far outside of the role of the server.

as I said, it's just a concept =P

Why is managing plugin libs outside the role of the server?

Was this page helpful?
0 / 5 - 0 ratings