How do I make a base Library for my mods.

[needoriginalname]

I am currently making a new mod, while at the same time need to maintain another mod. Thing is, the both mods share ALOT of code, rather then maintaining the command code base in two seperate mods, I thought it would be best to put them in a mod library, kinda like what OpenBlocks does with OpenLib, LLibrary, and various core mods. (granted, I am not using ASM at this time)

 

How exactly does someone make one, I am not even sure on the first step to how to do it.

[Draco18s]

What I did was just have separate packages in my workspace (mod.draco18s.library, mod.draco18s.mod1, mod.draco18s.mod2...) and use the build.gradle file to set up separate build tasks that would put the compiled code into separate jar files.

 

A few other folks will have other suggestions, but this is the one that worked for me.

[LexManos]

You can build a library, in this case its recommended you shade the library into the final jar to make it easiest on the end user to install it.

Trying to split a project into multiple jars would just be annoying to setup. And annoying for the end user.

[jeffryfisher]

What works for me (though there are drawbacks) is creating a separate package for shared code. One drawback is that I must avoid static fields that would work perfectly well to support one mod but fail miserably as soon as two or more mods collide. In other words, when you lift some of your existing code to a higher level of abstraction, you may need to fix some of its single-instance assumptions.

 

Another drawback is that when more than one of my mods is installed, the classes in the shared package will be loaded from only one of them. This creates a synchronization hazard for users who download my mods at different times.

 

If those mods are out of sync (built on different versions of the shared package), then some really weird run-time errors can crop up, so whenever anything changes in the shared package, I must remember to rebuild all of my mods and increment an intermediate version number.

 

I now keep one level of my dot-versioning in sync across all of my mods to denote which version of the shared package is in them (thus I can easily see a mismatch in any crash report with multiple mods loaded). When running my mods, I (and my friends) must make sure that they're all from the same generation.

[Draco18s]

I now keep one level of my dot-versioning in sync across all of my mods to denote which version of the shared package is in them (thus I can easily see a mismatch in any crash report with multiple mods loaded). When running my mods, I (and my friends) must make sure that they're all from the same generation.

 

Exactly what I (tried) to do.  Ended up realizing I'd done it in a way that didn't do what I'd been trying to accomplish.  Ended up with a scenario where I had to increment the number that was the "Library" version number despite the library not having actually changed.

 

The 1.10 version numbers will fix that.  The major-est number will be explicit the Library version, rather than just a major revision.

 

Trying to split a project into multiple jars would just be annoying to setup. And annoying for the end user.

 

Except that the reason I'm doing it is because my users explicitly requested it.  They wanted a single feature I had in a mod as its own mod, without all the other things the main mod did.

 

I did split it off as a standalone feature, but the two mods were effective "mutually exclusive" with each other (although checks were made to insure that singleton static references behaved nicely).  So in the 1.10 rebuild, they're properly separate, and the main mod instead depends on the single-feature mod.

[LexManos]

Or, you could just add a config option to disable the features they dont wont.

But this isn't what you asked, you asked to make a LIBRARY a library is not end user facing content, that is a mod.

Say you wrote a utility that made interacting with a text file easier for you. That's great, use it in all the mods you want. But to the end user your mod should still just be one file.

Having to download 5 different 'libraries' to install one mod is really annoying.

 

This is where shading/fatjaring comes in. You can build that library internally. You could develop with those 5 libraries and when you build you jar have gradle pack them all together and change their package to 'my.special.mods.libraries.{original package}' and those classes would exist and work and you wouldn't have to worry about two mods having two different versions of the library because each mod would have its own copy and use its own copy.

[Draco18s]

I've never had anyone complain, but I recognize your point as valid.

[LexManos]

Then you haven't been paying attention, 1/2 the tech support issues that aren't mc version mismatches are missing library/dep issues.

Not to mention the cluster that is IRC/Forums.

There is no reason for a modder to make it hard on the end user. It's super simple to do.

https://github.com/johnrengelman/shadow

[Draco18s]

but I recognize your point as valid.