How to publish a forge based library?

[jcranky]

Hi,

 

I'm developing a lib I want to be used by mods. The lib uses forge, and the mods will use forge as well, obviously. Do I have to take any kind of special care when generating the jar file for the lib, or can it be generated with a simple

 

./gradlew build

 

?

 

I'm asking because in my tests some methods are causing crazy NoSuchMethodErrors like the one bellow when used in the 'client' mod, which makes me think that something might be "out of sync" here.

 

[01:35:48] [specs2.env1591740272-2/INFO] [sTDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]: java.lang.NoSuchMethodError: net.minecraft.item.ItemStack.func_82833_r()Ljava/lang/String;
[01:35:48] [specs2.env1591740272-2/INFO] [sTDERR]: [java.lang.Throwable$WrappedPrintStream:println:748]:        at com.easyforger.recipes.package$.toRecipeItemStack(package.scala:12)

 

The package.scala:12 mentioned in the error contains the following:

 

implicit def toRecipeItemStack(itemStack: ItemStack): RecipeItemStack = RecipeItemStack(itemStack, itemStack.getDisplayName.toLowerCase.charAt(0))

 

My guess is that itemStack.getDisplayName is to blame. Makes sense?

 

thank you!

 

[]s,

[Awesome_Spider]

Umm, well the only guideline I would give you is to distribute a deobfuscated version. I don't know how to do that but diesieben07 (i think I spelled his name right) will probably know.

[jcranky]

Perfect! Worked like a charm, thank you.

 

Now let me just understand what is happening here. I just need the deobfJar task, plus the extra tasks.build.dependsOn definition, right? I see you also defined a sourceJar task. Why? It worked without that for me, but perhaps I'm missing something that I'm just not seeing?

[Draco18s]

I was looking at this and couldn't get it to work, as I want to have a deobfuscated package that is only one of my packages.  I've got various sub-mods all using the same build script, and while I did get a deobf version, it was everything, not just my lib.

 

So I'm not sure how to combine that build entry with something like

    from zipTree(jar.outputs.getFiles().getSingleFile()).matching {
        exclude 'com/draco18s/ores/**', 'com/draco18s/hazards/**', 'com/draco18s/wildlife/**', 'mcmod.info'
    }

[jcranky]

Draco18s, that is not a concern for me because I want everything. Perhaps that could be a way for you as well. Separate what is not part of the 'exported' lib in its own project.

 

In my case, I'll have three projects: the lib, a tester, and samples. Its a bit more trouble setting up but everything gets nicely organized. The main down side is having to publish the library 'all the time', which is not that hard if you publish to maven local.

[jcranky]

The source jar is not needed, but I have it so that people who use the library can see e.g. the javadocs and not get decompiled code when looking at the classes in the library. But technically it is not needed.

 

So the main goal is getting the sources jar? I'm already getting that, I thought this was a standard task from gradle, but perhaps that is my publish plugin doing? I don't need sourceJar even here (tasks.build.dependsOn('sourceJar', 'deobfJar')) then?

 

Also, where does the deobf classifier comes from? ForgeGradle plugin?

[Draco18s]

Draco18s, that is not a concern for me because I want everything. Perhaps that could be a way for you as well. Separate what is not part of the 'exported' lib in its own project.

 

Yeah, I could probably do that at this point.

[jcranky]

So, I've been thinking about this a little. To use the published library, I'm having to do

 

compile 'com.easyforger:easyforger-core:0.1-SNAPSHOT:deobf@jar'

 

Point being: I'm having to specify the classifier. Is that what should happen? Also, is the 'normal' (non deofuscated) jar file of any usage in this scenario?

 

thanks!

[coolAlias]

People will need to have the compiled .jar in order to run any mods using your library, unless your plan is to have each modder compile your code and distribute it with their mod (which would be a version nightmare, among other things).

 

So yes, you do still need the normal .jar.

[jcranky]

I see. So the deof is for the mod author to compile against my library, but for the client to run that mod, the normal jar will have to be installed in the mods folder. This also means that creating an uber jar is a bit more complex.

 

In that regard, would that be a good idea (the uber jar)?

[jcranky]

Depends on what you mean by "uber jar".

 

A jar with the mod and all its dependencies, so that the player doesn't need to add those manually to the mods folder.

[jcranky]

Do those dependencies include mods? If so, that's a bad idea.

 

No, I'm mainly concerned with the library itself, that will not contain any mods. I just want to make using the library as seamless as possible. All sample mods using the library are going to be in a separated project.

[jcranky]

Yeah.... that's a very complex problem. Handling libraries manually takes us back 15 years ago, before even maven was around... having to manage libraries, and libraries of libraries.

 

Coming to think of it, this can affect the libraries of my library as well. Which means that, to be really safe, it would be better to avoid any external libraries at all... or am I taking this rationale too far?

[jabelar]

Are you sure you want to create a library, or maybe you just need to publish an API -- i.e. just expose those methods that you are actually interested in providing to other modders?

 

Alternatively, if you're just keen to share useful code maybe just leave it open source and people can copy it and modify it directly if they wish.

 

I feel like publishing a library is a bit grandiose because it implies (at least I only undertake it if it has) a very high degree of general usefulness. What is the functionality this library would provide?

[jcranky]

Are you sure you want to create a library, or maybe you just need to publish an API -- i.e. just expose those methods that you are actually interested in providing to other modders?

 

And how would the modders use that API? Expose where?

 

Alternatively, if you're just keen to share useful code maybe just leave it open source and people can copy it and modify it directly if they wish.

 

It is open source already. I'm just not promoting it too much because it is just starting and there are lots to be done still. It should be a library because there won't be any reason to change the code of the library. The internals are likely to get complex and easy to break if you don't know what you are doing. Like forge itself, it should be used, not messed with.

 

I feel like publishing a library is a bit grandiose because it implies (at least I only undertake it if it has) a very high degree of general usefulness. What is the functionality this library would provide?

 

Yes, the goal is to be quite comprehensive. I'm writing wrappers and DSLs on top of forge, with Scala.

[coolAlias]

An API and a library are one and the same, the API being the public interface to the library.

 

Semantics aside, they are used in exactly the same fashion: developers use a deobfuscated jar and everyone else uses the normal jar.

[jabelar]

An API and a library are one and the same, the API being the public interface to the library.

 

Semantics aside, they are used in exactly the same fashion: developers use a deobfuscated jar and everyone else uses the normal jar.

 

My point is more the attitude about how the code is organized and presented. a professional library of course has a well managed API. But a person could create a library where everything is exposed or something and make a mess of it.

[jcranky]

An API and a library are one and the same, the API being the public interface to the library.

 

Semantics aside, they are used in exactly the same fashion: developers use a deobfuscated jar and everyone else uses the normal jar.

 

That's how I see it, and that's why I was a bit confused with jabelar's first statement.

[jcranky]

My point is more the attitude about how the code is organized and presented. a professional library of course has a well managed API. But a person could create a library where everything is exposed or something and make a mess of it.

 

Everything is exposed anyway, unless we use classloaders tricks. So yes, organization and presentation are important. But technically, its all the same and that's where I'm getting at. So I'll have to remember to have both a developer's and a user's guide.

 

Or on a second thought... installing the library seems to actually be part of the mod installing process. Does this make sense?

[jabelar]

An API and a library are one and the same, the API being the public interface to the library.

 

Semantics aside, they are used in exactly the same fashion: developers use a deobfuscated jar and everyone else uses the normal jar.

 

That's how I see it, and that's why I was a bit confused with jabelar's first statement.

 

Sorry for the confusion. Almost everything has an API of course. But I think the attitude is different when creating a library versus "just another mod with an API". When I provide a rudimentary API to mod my mods I wouldn't go as far as calling the result a library.

 

Furthermore, even though the Minecraft decomp source are a referenced library, they are in my opinion not proper libraries because there is public access to all sorts of stuff that isn't really intended as the modding API.

 

Maybe it is just me. To me a library has a high standard of intention behind it, not just any decomp code that you dump into your referenced libraries.

[jcranky]

Maybe it is just me. To me a library has a high standard of intention behind it, not just any decomp code that you dump into your referenced libraries.

 

Well, yes, I can agreed with that. It is different to say that your mod has an API, and that your mod is a library. And that is also why I am calling my thing a library: it is not a mod. It is a set of wrappers and helpers intended to help mod creators.

[jabelar]

So yes, organization and presentation are important. But technically, its all the same and that's where I'm getting at. So I'll have to remember to have both a developer's and a user's guide.

 

That's really my point.

 

I was worried that you're just taking a cool mod that you did and trying to re-purpose it as a "library". Someone just saying "I want to make a library" sounded suspiciously naive. However, you obviously know what it means: you're trying to build up a grounds-up codebase intended for multi-coder use from the start.

 

I'll be quiet now...

[coolAlias]

Sorry for the confusion. Almost everything has an API of course. But I think the attitude is different when creating a library versus "just another mod with an API". When I provide a rudimentary API to mod my mods I wouldn't go as far as calling the result a library.

 

Furthermore, even though the Minecraft decomp source are a referenced library, they are in my opinion not proper libraries because there is public access to all sorts of stuff that isn't really intended as the modding API.

 

Maybe it is just me. To me a library has a high standard of intention behind it, not just any decomp code that you dump into your referenced libraries.

I was just pointing out that any exposed part of a library/mod is an API and that the way to use an API, whether from a mod or a library, is identical.

 

It would of course be silly to call a mod with some exposed methods a library, even though that would be semantically correct

[jcranky]

I'll be quiet now...

 

Don't. Conceptual discussions are always fun =)