Posts Tagged ‘maven’

LWJGL on Maven central

Saturday, October 22nd, 2011

Hi we are happy to announce that LWJGL is available in Maven central. We worked hard with the @LWJGL people to make this possible.

Why was it important to get LWJGL into central?

Well, one of the biggest pains when using maven is having your dependencies available from central, if they are, you just need to add a little snippet of XML and you are done, if they aren't, then you need to install them manually to your local repo or to a private maven repo.
This is a problem in itself but this also means that projects that depend on something that isn't available in central, can't get into central themselves, making the work needed to use it grow exponentially.

Previous work

In order to get LWJGL into central we had to work first with @Endolf to get JInput into central so a huge thanks to him as well.

Future plans

Now that we got LWJGL into maven central, we can start thinking about trying to convince the authors of other useful libs that use LWJGL like Slick2D, libGDX, nifty-gui, etc to make their libs also available on central (of course we would love to help make this a reality as well).

If you use LWJGL with maven, we would love to hear from you and feel free to ask us anything.

More information:

VN:F [1.9.22_1171]
Rating: 5.0/5 (3 votes cast)

Maven Natives Dependencies Project

Wednesday, March 2nd, 2011

Mavennatives project is composed by a Maven plug-in and an Eclipse plug-in we developed in order to simplify working with natives dependencies.

The Maven plug-in unpacks every dependency with a classifier beginning with "natives-". By default its executed in the package phase, and unpacks in the target/natives directory.

The Eclipse plug-in automatically executes the Maven plug-in and configures the java.library.path for Eclipse projects with natives dependencies. This makes working with natives dependencies transparent and you can use the Run menu without having to set java.library.path manually for each run configuration. Right now this Eclipse plug-in only works with an outdated version of m2eclipse but a new version is in the works.

To work with LWJGL natives, we made custom releases of LWJGL jars with classifiers "natives-win", "natives-linux" and "natives-mac" with corresponding OS natives each one. As the Eclipse plug-in is not working with current m2eclipse version, we added the goal nativedependencies:copy to Maven -> Life Cycle from Eclipse project properties, so each time you clean the project the maven plug-in executes and the natives are copied to target/natives folder, after that, we configure by hand the java.library.path to point to that folder.

Mavennatives plug-in is already on Maven central and we are trying to get LWJGL and Jinput into Maven central too, using the natives format natives-${os} we defined for this plug-in.

If you want to take a look at the project, visit googlecode at mavennatives.

UPDATE: maven natives eclipse plug-in is updated so it should be working for latest version of m2eclipse

UPDATE2: maven natives eclipse plug-in is not working with the latest version of m2eclipse hosted in eclipse.org.

UPDATE3: LWJGL is already on maven central.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Signing JARs for Applet and Webstart

Sunday, February 7th, 2010

We are developing our games using Java and deploying them as Applets and Webstart applications.

By default, applications launched with Java Webstart or as an Applet run in a restricted environment. We are using some technologies which require unrestricted access like Lwjgl, Jinput and custom ClassLoaders. In order to have access to these features, every jar must be signed with a certificate.

Once the jars have been downloaded on the client machine and the signature is validated, the user is requested whether he trust or not the provider of the certificate and if he wants to accept it permanently.

In the beginning, one option is to generate a new certificate every time we sign the jars of an application but this means that although the user might have accepted a certificate permanently, he will have to accept the new one.

A better option is to generate a certificate once and use it every time we sign an application, so that whenever the user accepts our certificate permanently he won’t be bothered again.

A way to create a certificate and manually sign an application with it is explained at Sun's Java Documentation.

In our case, we are using maven as our build tool with maven-webstart-plugin to automatically sign our jars. This plugin allow us to use both options.

In order to easily choose between them, we configure the plugin using properties instead of fixed values, so we can override them with profiles. Using the default values of these properties, the plugin generates a new certificate each time.
If we want to make a public build, we activate a maven profile overriding these properties to use an existent certificate used by all of our applications.

Here are some snippets of our configuration files:

pom.xml - maven-webstart-plugin configuration

  
<configuration>
	<sign>
		<keystore>${gemserk.keystore}</keystore>
		<keypass>${gemserk.keypass}</keypass>
		<storepass>${gemserk.storepass}</storepass>
		<alias>${gemserk.alias}</alias>

		<!-- default values if gen is true -->
		<validity>3560</validity>
		<dnameCn>Gemserk</dnameCn>
		<dnameOu>Gemserk</dnameOu>
		<dnameO>Gemserk</dnameO>
		<dnameL>Montevideo</dnameL>
		<dnameSt>Montevideo</dnameSt>
		<dnameC>UY</dnameC>

		<verify>true</verify>

		<keystoreConfig>
			<delete>${gemserk.keystore.delete}</delete>
			<gen>${gemserk.keystore.gen}</gen>
		</keystoreConfig>
	</sign>
</configuration>

We use our company name as a prefix for the property keys in order to have a common scope when setting the values.

pom.xml - default values

  
<properties>
	<!-- Properties for keystore generation  -->
	<gemserk.keystore>/tmp/keystore-gemserk</gemserk.keystore>
	<gemserk.keypass>m2m2m2</gemserk.keypass>
	<gemserk.storepass>m2m2m2</gemserk.storepass>
	<gemserk.alias>gemserk.com</gemserk.alias>
	<gemserk.keystore.delete>true</gemserk.keystore.delete>
	<gemserk.keystore.gen>true</gemserk.keystore.gen>
</properties>

settings.xml - profile declaration

  
<profile>
	<id>useDeploymentCertificate</id>
	<properties>
		<gemserk.keystore>/opt/gemserk-keystore</gemserk.keystore>
		<gemserk.keypass>password</gemserk.keypass>
		<gemserk.storepass>password</gemserk.storepass>
		<gemserk.alias>gemserk.com</gemserk.alias>
		<gemserk.keystore.delete>false</gemserk.keystore.delete>
		<gemserk.keystore.gen>false</gemserk.keystore.gen>
	</properties>
</profile>

In order to build an application for deployment, you can activate this profile from the command line using:

mvn package -PuseDeploymentCertificate

If you have any questions leave a comment.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)