Spritesheet library

User Code & Projects
1

I’ve moved my spritesheet library to gradle and published on github: GitHub - Pesegato/MonkeySheet: Spritesheet library for jMonkeyEngine

This does not count as an annoucement, in that I need to publish a sample usage + documentation, and also have a few issues to solve with gradle:

  1. I need to put a Main class (which is actually unused),
  2. the actual library classed are not compiled…

Thanks!

2 Likes
2

Sounds like you’ve included the application plugin when you don’t want it to be an application.

Uh… not sure what this means. Are they in src/main/java like they are supposed to be or?

Edit: looking at your build.gradle… you can remove like half that stuff.

3

Yes

Ah ok. :stuck_out_tongue:

https://github.com/Pesegato/MonkeySheet/tree/master/src/main/com/pesegato/MonkeySheet

Improvement and suggestion welcome :slight_smile:

4

You will be happier if you put the Java files into src/main/java… that’s where everyone (including gradle or maven) will expect them to be by default. That is why gradle isn’t compiling them because you’d have to tell gradle where to find them. (It is looking in src/main/java which is basically the defacto standard now.)

…it can be reconfigured but the question is why swim against the stream. There is actually a very good organizational reason for src/main/java.

Regarding the other, you can just remove the inclusion of the application plugin and then remove everything associated with mainClass, jvmArgs, etc…

If you include the maven plugin then you can run gradle install to install it in your local maven repo and make it available as a regular dependency to any other local project. It’s also a nice early step on the path to getting uploaded to jcenter.

1 Like
5

Please post the config for this… also thanks for the rest, almost sorted out everything :slight_smile:

6

Uh…

plugins {
          id "java"
          id "maven"
}

It’s worth having the gradle documentation on ‘speed dial’ so to speak.

Edit: though generally I opt for the ‘apply’ version of plugin inclusion… then:

apply plugin: ‘maven’

https://docs.gradle.org/current/userguide/maven_plugin.html

1 Like
7

Hey who stole my shaders? They’re right here:

https://github.com/Pesegato/MonkeySheet/tree/master/src/main/java/com/pesegato/MonkeySheet/shaders

But don’t get included on the JAR… :frowning:

EDIT: moved the shaders to src\main\resources\MatDefs . Now what?

8

You would be better off adding assets.jar support as I’ve included in my example project and at least 3 or 4 other threads here.

Edit:… but anyway src\main\resources is actually fine for a library and they should then already be in your jar and ready to go. assets.jar is better for apps… so maybe ignore my statement above.

1 Like
9

I have locally built the POM. Now how do I include as a dependency on another local gradle application? Thanks!

10

If you ran maven install then it is already in your local maven repo. Just include a dependency in the other project and make sure that mavenLocal() is in your repo list in that project.

1 Like
11

Why don’t you have something like this on your gradles:

task writeNewPom << {
 pom {
  project {
   inceptionYear '2016'
   licenses {
    license {
     name 'The Apache Software License, Version 2.0'
     url 'http://www.apache.org/licenses/LICENSE-2.0.txt'
     distribution 'repo'
    }
   }
  }
 }.writeTo("$buildDir/newpom.xml")
}

?
And yet you use mavenLocal() ?

12

You don’t need any of that stuff for maven local. Maven local is literally just an .m2 directory under your user’s home directory.

You only need that license stuff when you actually go to publish to a maven central-style repo… and then you will need a LOT more than that.

I have some stuff that Lemur, Zay-es, etc. use that I wrapped into a common utility. You can see some of it referenced in Lemrur’s build.gradle:

Because I thought this:

…was a lot to include in every build file.

1 Like