[FIXED] Deploying lwjgl to maven central repo

[ruben01]

Hi, I am trying to get lwjgl deployed to the maven central repository, this would allow people using maven to have easy access to working with lwjgl, but also as a lot of libraries use lwjgl as a dependency (slick2d, nifty, twl, jmonkeyengine, ardor3d, libgdx, etc) it would make it possible for those to be deployed to the maven central repository as well.

What I am trying to accomplish doesn't involve migrating the lwjgl build to maven or anything like that, the proposed changes try to be the as minimal as possible.

In order to do that there are some requirements imposed by the people who manage the central repo.

   
• All the project dependencies should be in the Maven Central Repository
• For each jar with java classes there should be an attached jar with javadocs
• For each jar with java classes there should be an attached jar with sources
• All project artifacts are signed using GPG

To be able to fulfill these requirements I need to apply a patch to the current build in order to make some definitions in build-definitions.xml a little more fine grained. (for example to be able to tell which natives are for lwjgl + openal and which are for jinput)

In a local git repo I already have an extra build-maven.xml that makes all the extra artifacts, copies the poms, and signs everything, but that still needs to be validated depending on how is the lwjgl release process.

I am attaching the patch for the build-definitions.xml I tested it and it seems to not break anything but please check it out, and if everything is ok it would be great if you could apply it so I can move on to the rest of the steps.

EDIT: This is a link to the instructions and requirements for uploading to maven central just for reference -  https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

thanks

[void256]

+100

I'd really like to have LWJGL available in the central maven repo! It would allow so much easier access to LWJGL for all Maven users and it will allow third party libraries that use LWJGL to be available in the Maven Central Repo as well! That would be really really really great!

[Matzon]

patch looks fine and a build test didn't blow up - patch applied. Thanks.

[ruben01]

Hi, I want to share how this task is advancing, I made an extension to the build that generates a zip file that contains the needed artifacts to make the deployment together with an extra build.xml file that executes the deployment into a maven repository. In the current version it just deploys to a /tmp/m2repo file repository.

In order to generate the zip you just need to apply this patch to the latest version from svn.
This will add two ant targets:
   ant maven-full:  makes a build from scratch
   ant maven: it is supposed to be used after the regular lwjgl build

in both cases you need to download the natives from the hudson builds (I will attach a little script to do that in linux)

When you generate the zip, it is placed in the dist directory as lwjgl-maven-2.6.zip

To perform the distribution you need:

• To install the maven ant tasks: just save the jar into your ant lib dir, or in your home .ant/lib
• Generate a gpg sign key: using "gpg --gen-key"
• Add a profile to your maven .settings file in ${home}/.m2/ directory declaring the passphrase used for the gpg key
  
  
  
  • If you know how to do that look at the sample settings.xml and copy the profile declaration changing the passphrase to match the one used to generate the key
  • If you don't know just use the example settings.xml changing the passphrase to match the one used to generate the key

Then to perform the distribution just unzip the lwjgl-maven zip somewhere and inside there is a maven dir with a build.xml file, in that directory, just run "ant deploy" this will sign with your gpg key and deploy everything to a local repo in your /tmp/m2repo dir.

If you have any question, or if anything fails don't hesitate to ask me for help, here or in irc.

thanks

[Matzon]

nice. I will look into it this weekend. In between some LoL sessions, it would be nice to get this out with a 2.7 release - if time permits.
What about the jinput version issue?
How are the lwjgl dependencies such as lzma.jar and AppleJavaExtensions.jar handled ?

[ruben01]

Hi, I made another patch in order to add jinput to the maven distribution.

With this patch jinput will be deployed as a subproject of lwjgl it is not an ideal solution, but for now is the easiest one, and gives us a fully functional lwjgl maven distribution.

The new patch will create the native jars for jinput and has the poms to deploy all the jinput artifacts to a repo. Also jinput is added as a dependency of lwjgl in the lwjgl pom.

Also the new patch adds support to install the distribution in the current user local maven repository as well as deploying to a repo.

If you want to make some test and generate a custom version of lwjgl there is a property called "lwjgl-maven-version" in platform_build/build-maven.xml you have to set that property to the version you want before generating the maven distribution, currently there is no way to change that after the distribution is generated but before installing or deploying (other than manual edit of the generated poms). In the future I want to make this property calculated from the "lwjgl.version" property (like transform from 2.7 to 2.7.0 and adding -SNAPTSHOT to the nightly releases).

To answer Matzon questions in his last post:

• The AppleJavaExtensions.jar is used only at build time, so it doesn't have an impact in the maven distribution.
• The lzma.jar is used as a deployment tool with the appletloader, but not as a transitive dependency to other projects that use lwjgl so for now it is not handled in the maven distribution.
• About jinput, I have been unable to find any info about version numbers for jinput, or a release process that allows to match the jinput.jar used in lwjgl to a stable jinput release. This fact, and that I have been unable to get in touch with endolf made me add jinput as part of the lwjgl release, instead of an external dependency. This will work fine for now, but is not an ideal solution at least according to maven best practices.

Extra github info.

In order to make this development a lot easier we made (with arielsan) a lwjgl github repo that is synched to the latest svn version (https://github.com/gemserk/lwjgl) and the latest work with the maven distribution can be seen in my fork in the branch maven (https://github.com/rgarat/lwjgl/tree/maven). There is also a page where you can see the difference between the latest svn version I merged to my master branch on my repo (doesn't have to be the actual latest svn version) and the latest work on the maven branch (https://github.com/rgarat/lwjgl/compare/master...maven).

I am a complete git noob so I can't promise that the gemserk/lwjgl repo will stay in sync without any hiccups, or that it won't have to be deleted and rebuild (I already screwed up once, and had to start from scratch).

Ruben

[Matzon]

Looks good. Will apply tonight.

At some point we need to look into pushing this into the central repo.

[Matzon]

postponing until 2.7.1 is out - dont want other changes in

[ruben01]

no problem, good luck with the openal fix

[Endolf]

Hi

I replied to your DM on twitter last week, not sure if you got it. If memory serves, to get in to the central repo you have to control the domain that is the same as your package structure, in the case of jinput, that is java.net, which I have no access/control over, which is why I gave up on sticking jinput in the central repository when I was looking at this a year or so ago.

I tweaked JInput so that the results of a normal build can be shoved in to a maven repository, and I set up one on newdawnsoftware.com for jinput

http://www.newdawnsoftware.com/maven2/net/java/games/jinput/

Not sure this helps much, as I can't get jinput into the central repo.

Endolf

[Matzon]

patch applied

[Matzon]

doh, with attribution to arielsan instead of you - doh - for that commit, still in the credits file

[ruben01]

sorry for the delay, had some family visiting over

endolf: about the requirements to get a project into maven, the groupId should be a valid domain, but you don't have to own it for example you can have com.googlecode.myproyect or in jinput case net.java.jinput or something like that.

here are the requirements and process to get a project into maven central https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

about getting jinput to maven central, I have identified a couple of issues:

• jutils is added to the jinput jar, should it be an external dependency?
• a sources.jar and javadoc.jar is required to get into maven central
• we are using a similar but different nomenclature for the natives jars
  
  
  
  • they are jars not zips
  • we are using the format natives-${OS} like natives-win, natives-mac, natives-linux for the maven classifier, then you can use our maven plugin (coming soon to maven central) to extract the natives content automatically
• all the jars have to be signed with gpg

another issue with how lwjgl uses jinput, is that right now lwjgl can take a nightly that has a needed fix, and update the lwjgl distribution to use that, by having lwjgl as an external dependency they would need a formal jinput release.

[Endolf]

We can rip jutils out during a maven build and add that to the central maven repo too

Endolf

[ruben01]

I added support for generating the maven version from the lwjgl.version property.

This is needed because maven versions should be like <major version>.<minor version>.<incremental version>-<qualifier> (with the qualifier being optional) and currently what would be for example the 2.7.0 version in maven land is 2.7 in lwjgl.

The patch uses a task made in javascript to add the extra ".0" to the version if it is Number+.Number+. if the lwjgl.version has another format it leaves it untouched (this makes it easier to make temporal builds like 2.7.1-test1 or stuff like that and being able to install it locally or in a personal repository).

In this patch I could not use antcall to invoke the custom task because antcall generates a new project environment to execute the task, so any changes made to properties in the called task are not seen by the caller. So I had to make the maven task depend on the custom one.