[FIXED] Deploying lwjgl to maven central repo

[ruben01]

Mazon: I made a tiny huge bug in the last patch :-) the result was that it was forcing a snapshot version when the user didn't want to, this patch fixes that, sorry for the error.

[ruben01]

I am happy to say, that I started the process to get lwjgl 2.8.0 into maven central :-)
Sadly I forgot that the first time you have to add a comment to a jira issue to ask them to enable the maven central sync so even though everything is done from our side, I don't think the release will reach maven central until monday or tuesday.

The process to make the release has some server side checks and the maven build that we had was failing some checks so I made a patch that should fix that in the future.

Mazon after applying the patch and if you make the 2.8.1 release, it would be useful if you could run:
     
         ant maven-full -Doverridejinput=true

and save the file dist/lwjgl-maven-2.8.1.zip so that I can later perform the 2.8.1 release into maven central

the "-Doverridejinput=true" is used to prevent the build from aborting with this error caused by the difference in the jinput version between the regular lwjgl build and the declared maven dependency
Jinput version in project (2.0.0-b01) is different from the declared jinput version for maven (2.0.5) add -Doverridejinput=true as a command line option to avoid this check

thanks

[ruben01]

Achievement Unlocked: LWJGL 2.8.0 and 2.8.1 are available from Maven Central

I will make some detailed tutorial for how to use the dependency, and some choices I made about how to bundle the artifacts

the main dependency you need to add is

<dependency>
    <groupId>org.lwjgl.lwjgl</groupId>
    <artifactId>lwjgl</artifactId>
    <version>2.8.1</version>
</dependency>

this will bring 3 jars with the natives, the transitive dependencies will have a classifier like [natives-windows, natives-osx, natives-linux] you can use the dependency plugin to unpack those jars into a dir so that you can point to it your java.library.path  or use my maven natives plugin  that will unpack all the dependencies with a classifier like "natives-*" into target/natives

There is a sample project using lwjgl 2.8.1 from central, with this project, if you run "mvn package" you will get in your target dir, a zip file that contains a the main jar, the dependencies, the natives exploded and a couple of batch scripts (bat and sh) to run the test.

In the maven central search page you can see all the artifacts that make the lwjgl project, with the coordinates for lwjgl_utils and lwjgl_util_applet

If there is anything I can help you with don´t hesitate to ask, I am on the irc channel as "ruben01"

Hope people find this useful, and thanks for all the help from the lwjgl team.

Rubén

[Matzon]

Thanks a ton for spearheading this ruben01!

I will make a front page entry on the site tonight (CEST) - please remind me

[kappa]

<dependency>
    <groupId>org.lwjgl.lwjgl</groupId>
    <artifactId>lwjgl</artifactId>
    <version>2.8.1</version>
</dependency>

Don't know much about Maven, but just curious, is it normal for package names to be like the groupId "org.lwjgl.lwjgl" (i.e. lwjgl being mentioned twice instead of just "org.lwjgl") ?

[ruben01]

The choice I made when building this, was to take the groupId as ${organization}-${project} so in here it would be org.lwjgl as the organization and lwjgl as the project.

This is not too pretty on the eyes when the project shares the name with the organization, but I think it is still better and makes it nicer if you ever add other projects under the umbrella of lwjgl.org, examples of that could be, if you split the appletloader into a separate project from lwjgl so org.lwjgl.appletloader would be the groupId, or anything else you may want to do.

In maven projects are usually made of different artifacts grouped under the same groupId.

In our games we usually have for example

groupId: com.gemserk.games.thecodenameofthegame
artifactsIds: thecodenameofthegame-core, thecodenameofthegame-android, thecodenameofthegame-desktop

Personally I have seen both decisions even from the maven guys, having multiple projects all share the same groupId using it only as the organization or as a category of stuff like org.maven.plugins and all the artifacts from the different projects live under the same groupID. Or using the groupId as the organization + projectName.