Removal of Ebean ORM

Discussion in 'API Discussion' started by md_5, Nov 17, 2016.


Remove Ebean?

  1. Yes

  2. No

Results are only viewable after voting.
Thread Status:
Not open for further replies.
  1. md_5

    Administrator Developer

    Pretty much since it was first written, Bukkit has packaged the Ebean ORM. The idea here was that instead of each plugin implementing their own database they could use a database configured by the server, and instead of writing SQL they could use the ORM capabilities of Ebean and work with POJOs. The usage of Ebean within plugins never took off, and in a scan of every plugin uploaded to BukkitDev in 2014 (some 12,000 from memory), only one developer (ZPermissions) was using this API in public plugins. Due to incompatible changes going forward, the version of Ebean packaged with Bukkit is version 2.8 from 2012. Now in 2016 they are up to version 9. Between the badly outdated version we are forced to package and the practically non existent use of this API, I am planning to remove it in Minecraft 1.12.

    Thoughts are welcome.
    • Agree Agree x 8
    • Like Like x 2
  2. I didn't even know that was a thing! xD Sounds like a good call.
    • Agree Agree x 6
  3. Choco


    To be completely honest, I've never found any practical use for that portion of the API. I've used databases, but I just instantly jump to MySQL as it's kind of the go-to database. If it's really that out dated, I see no reason to keep it in the API if less than 0.01% of developers even use it. Worst case scenario, if some plugins do use Ebean ORM, they will have to shade the API in with Maven. It's not really all that bad. Definitely agree with taking it out for 1.12

    EDIT: Everyone suggesting to shade in HikariCP, 100% agree. This is a fantastic idea, and I know plenty of people use it, but have to use Maven in order to use it. For newer users, this might be confusion
    EDIT2: Mind changed. It makes sense that developers should manage their own dependencies. If Spigot will not use HikariCP, it makes no sense to shade it.
    #3 Choco, Nov 17, 2016
    Last edited: Nov 19, 2016
    • Agree Agree x 5
  4. I've read about this many times on Bukkit pages yet never really got into it. If I were to require database I'd instantly turn to a MySQL utility class. Great concept. Removing it seems fine if so few plugins are using it.
    • Agree Agree x 2
  5. I for one welcome a little fat trimming.
    • Agree Agree x 2
    • Funny Funny x 1
    • Winner Winner x 1
  6. Instead provide one sql wrapper that has a connectionpool and handles reconnecting. That should help user starting developing plugins with databases.
    • Agree Agree x 12
  7. Maybe add an implemented MySQL Api? Maybe even add HikaryCP so we don't have to shade it into the jars.
    • Agree Agree x 3
    • Like Like x 1
  8. I think that HikariCP should be implemented as it would sace a lot of time for those of us who support sql in our plugins
    • Like Like x 1
  9. I mean, I've tried to use it, but it's just.. no. Just a big no.
    Implement some kind of MySQL, MongoDB, MariaDB, etc. implementation which supports all of them with the same syntax, if you can.
    • Like Like x 2
    • Agree Agree x 1
  10. Well.
    Never had to use it, i personally think that mysql can do a better job, and since i've never heard of someone using it, i would personally remove it.
    What about a sort of MySQL api and HikaryCP implemented ?
  11. Choco


    Well Java has its own SQL implementation. HakariCP on the other hand, is an external library
    • Like Like x 1
  12. I would not try to encourage defaulting to a simple POJO without any db specific features. All though spring got pretty far with the abstraction, I still prefer choosing the right tool for the job (and that tool could be sql, mongo, dynamo, azure table storage...).
  13. How about implement hakari into the api and see the stats on that, xD and make a mysql system in the api.
  14. I just spent like 5 hours the other night to learn how to shade in Hikari... and before that I didn't try until a month passed because ever time I tried I messed up github and my file changes got deleted.. and i looked really dumb in irc a bunch of times because of it since I had no idea what was going on.

    I would have saved a lot of time if it was just there

    now let everyone else suffer and figure it out themselves! (just kidding, definitely add Hakari and remove this ebean thing since no one uses it)

    However I am probably just going to keep the shade so it works with other spigot versions
    #14 Synapz, Nov 18, 2016
    Last edited: Nov 18, 2016
  15. Just remove it and don't replace it with anything like anybody is suggesting. Plugins should package their own dependencies.
    • Agree Agree x 7
  16. As @Coelho said, dependencies should be isolated. All though it may sound nice at first, it's really bad practice.
  17. I read about the internal Ebean implementation when I first learned about plugin development. Quickly decided not to use it and honestly not surprised no one else did.

    I don't think I'm a supporter of including HikariCP in spigot. The Ebean removal is very welcome, though.
  18. Well there already are a few so why not. They aren't going to remove the other dependencies and break tons of plugins because it's "bad practice"
  19. iirc the other included dependencies are there because they're in the minecraft server by default. Ebean is extra.
    • Informative Informative x 1
  20. Dependencies in Spigot should only be there if Spigot itself uses them. If it doesn't, remove them.

    Except for MySQL. That'll break everything. Keep that.
    • Agree Agree x 1
Thread Status:
Not open for further replies.