[FIXED] Deploying lwjgl to maven central repo

[ruben01]

Hi endolf I made a patch for the jinput build that generates everything needed for deployment into maven central

The patch is made of

• build-maven.xml
• maven/jinput.pom
• maven/build.xml
• maven/jinput-parent.pom
• maven/jinput-platform.pom

In order to make the maven build you need to download the natives and jutil.lib (as is done now in the hudson build) execute the normal build with the dist and javadoc targets to generate the jutils.jar and the javadoc.
Then running "ant -f build-maven.xml mavendist" a directory dist-maven will be created and in there it will create:

• jinput-sources.jar
• jinput-javadoc.jar
• copy of the jinput poms with the current version
• build.xml a copy from maven/build.xml this supports local repo install and signing and deployment to a repo
• copy of the maven-ant-tasks-2.1.0.jar so that dist-maven is a complete unit of work

In order to be able to deploy to maven central you have to request access to the oss sonatype people as explained here using as groupId "net.java.jinput"

I got a lib into maven central that is hosted in google code using the groupId "com.googlecode.mavennatives" here you can see the request as a reference

This is a first attempt at this so there are still some details to see, like if you want this as a separate build or something more integrated into the normal build, about jutils I think that perhaps leaving it like it is, as just classes inside the jutils jar would be the easiest and fastest way.

If there is any problem please let me know

thanks.

Rubén

[Endolf]

Hi

Seeing as JInput already has a maven target in it's build, would it not have been better to modify that?

Endolf

[ruben01]

yes if you want I will modify that target, seeing that there was some differences like classifier of the natives and using jars instead of zips and as I didn't know if you were using the maven stuff in your projects right now I didn't want to break anything.

any other comment?

[Endolf]

Nope, not looked at it other than that yet , I would suggest adding the jutils stuff to the jutils project, then removing those classes from the jinput.jar file. Rather than mixing the two. The jutils jar only ends up in jinput to make distribution easier.

Endolf

[Endolf]

I am using the jinput maven build in a project of mine, but I can change things if that makes sense. I would probably use net.java.games.input as the groupid as that is the package name.

[ruben01]

I uses the other groupId because it matches the domain of the project in the rules for inclusion to maven central they say

the groupId of your Maven project, it must match your domain name, so com.googlecode.myprj is valid one but myprj is not

not sure if it won't be a problem to use another groupId but I have no personal problem with either one

[Endolf]

Ok, that makes sense.

[ruben01]

Well this is attempt number 2 at the jinput patch

now the build is integrated into build.xml

the targets are
mvninstall - to install to the local repo
mvndeploy - to sign (with gpg) and deploy to a repo (currently to /tmp/m2repo)
mvndeploy-old - this allows to deploy using scp (couldn't replicate this with the new method) shouldn't be needed for the sync to maven central

Endolf it would be great if you could start creating a user and requesting access for the oss sonatype repo as explained here it will allow us to start testing snapshot deployment and deploy to the staging repo before asking for sync to maven central (requesting access takes a couple of days for them to enable it).

thanks

[ruben01]

This is me again :-)

This time I have a patch for the jutils dependency of jinput to try and get that to maven central as well

it has the targets mvninstall and mvndeploy

because this project doesn't have the ant tasks included you have to add that (and the extra config to the build.xml) or add the ant tasks to .ant/lib in your home dir(in linux)

[Endolf]

Hi

I'll start looking at this next week hopefully. I'm helping fun a festival this weekend and it's all about to kick off

Cheers

Endolf

[ruben01]

Mazon: would you mind applying the patch I attached in that post: http://lwjgl.org/forum/index.php/topic,3707.msg20794.html#msg20794
we talked about it some time ago, you weren't sure because it requires jdk 1.6 for the scripting, I asked endolf and he said that the build farm has jdk 1.6 and the requirement would only apply when building the maven version.

This patch would also prevent stuff like this http://lwjgl.org/forum/index.php/topic,3953.0.html from happening

and would allow me to send you the next changes needed to use the jinput version that endolf got into maven central.

thanks

[Matzon]

ok, will do this tonight CEST

[Matzon]

fixed in r3519

[ruben01]

I made a new patch that should get us closer to having lwjgl in maven central

This new patch:

• uses jinput from maven central, instead of deploying
• compares the jinput jar version with the declared maven version and aborts the build if they are different (the check can be overridden by a command line parameter)
• changes the naming convention of how native jars declare the OS to match the ones used in jinput on maven central
• supports install to local repo, deploy to repo, and deploy with gpg signing (needed to deploy to maven central)

One issue remaining is that the MappedObject feature in lwjgl_utils is using a version of asm that isn't released yet, and isn't in maven central, so for now it doesn't add asm as a declared dependency. This means that if someone wants to use the ljwgl maven release, and use MappedObjects, they have to add the asm library to their project.

With this patch applied, we could start talking about deploying snapshot artifacts so that people can check the nightlies using maven in an easy way, and also start talking about releasing lwjgl into maven central 

thanks

[ruben01]

Created new patch, that adds to the build a flag -Dsnapshot=true that transform the lwjgl.version into a maven snapshot version, this would enable the hudson build server to build snapshot versions without having to specify the maven version in the hudson job config, it would just say -Dsnapshot=true and the ant build would make the transformation itself.

Also added some better logging for when there is a difference in the jinput version between the one used for the regular ant build, and the declared maven dependency.

thanks