Hello people!
I’m trying to put LWJGL on a Maven repository but I wasn’t able to find a Maven Repository with JInput on it. Is it possible that you guys can upload JInput onto it? If not, is it possible that I can do it for you? (I’m a newbie when it comes to Maven but I think I could do it.)
Thank you!
Warm regards,
Jon
I have been thinking about doing this for a while also. I would also like to upload a nightly snapshot build too.
Had you considered how to handle the native libs?
Endolf
Hi and thanks for the quick response! 
According to http://maven.apache.org/guides/mini/guide-central-repository-upload.html, only releases (non-changing files, fixed dependencies) can be put on the central repository. Have you decided what repository to use?
I have not yet figured out how to handle native libs.
Do you want to start using Maven to build JInput? If not, perhaps we could probably just copy the binary distribution files, making one artifact for every platform.
Let me know what you think!
Thanks!
Not sure about for release builds, but I’d stick up a repository at newdawnsoftware for the snapshot build.
What I’ve done for my own code is to build the main application in to a jar per module, and one jar for the natives. That mirrors how the webstart deployment works. This might not be the best way, but seems to work (I dislike the alternatives worse so far).
Ideally LWJGL would then use that build, but I don’t think they have any plans to use maven in their build process.
I have stuck an ant task in jutils to publish it already, although locally only currently. But this might show how to create an automated publish task in jinput without having to rewrite the build. We might be able to pursuade a pom on LWJGL as long as the build was still possible without maven.
Endolf
Great!
I see. Well, let’s start with that method and see how it goes.
I started a forum thread over at the LWJGL forums (http://lwjgl.org/forum/index.php/topic,3305.0.html) and as you can see, it doesn’t look impossible.
Let me know when your snapshot build repository is up.
Take care!
Man, this Maven stuff is viral. A few of my OSS projects have gotten requests for me to put JARs up in a Maven repo. However, I don’t use or really even like Maven, and the level of effort to do so is more trouble than I’m willing to go through. Can’t Maven people just use a local repo or whatever hoops they have to jump through without bothering others!? 
;D
I was in the same camp as you Nate, I didn’t see what the point of maven was. I had ant after all. My projects have grown over time and become more modular, and for this, it makes sense. If you have a large number of dependencies it also makes sense.
The other side is ant + ivy. This is what we have at work, and it’s lead to a 6k+ line ant file that only 1 person really understands because it’s now so complicated. This would be sooooo much simple in maven.
For small projects with low number of modules, and/or dependencies, I can see no need.
That said, now I’ve started on the maven path, I’ll be using it for almost everything. It’s easy to set up once you have figured out the maven way to do things. The eclipse plugin is good (it ‘just works’).
The only issue to work out is, as I pointed out, how the natives are dealt with. Maven likes zips and jars, not so much dlls, sos and jnilibs. But they can get thrown in a jar, and unpacked if needed, or just signed and uploaded for applet/webstart.
Maven is spreading for good reasons, it’s as bad as this ‘Java’ thing, keeps spreading everywhere, if only people would see that C is all they need ;p
Endolf
Ant is absolutely horrible. Maven is better, granted, but still not my cup of tea (actually tea isn’t my cup of tea, but “not my frosty mug of Pepsi” doesn’t have the same ring, however more meaningful). Just because both of these can do the job doesn’t mean they are particularly good. Especially irrelevant is the way the masses are leaning. 8)
My point is, use whatever fantastic build system you want (the general you, I mean), but goddamnit leave me be! >:( 
Don’t preach in my house and I won’t think in your church, sorta thing. ;D
someone screwed up then…
We use ivy at work too - and the main build file with ivy targets is 156 loc, handling basic publish stuff and other call throughs (with checks for params and other “friendly” stuff). We use ivy with its default target and have configuration for 4 repositories.
It really is a lot easier to deal with than maven.
sorry for hijack, but I simply dont agree that maven is easier than ivy - quite the contrary.
[quote]someone screwed up then…
[/quote]
oh boy, did they ever, glad it wasn’t me, but now we have to deal with the fall out.
[quote]sorry for hijack, but I simply dont agree that maven is easier than ivy - quite the contrary.
[/quote]
No need to apologise. Sensible discussion normally involves opposing views. I’m not suggesting that all ant ends up that way, just that it can (the ivy bit really isn’t the problem, that works). A maven based build would solve nearly all the issues that the monster ant script tries to, and much more concisely. The downside to maven in my experience is that once you go off the mainstream tasks, you get in to trouble and have to write code. One of my applications is webstartable, and the webstart target is a pain to get working. I don’t want to touch it again now it works, it isn’t perfect. It’s not something you can quickly script around like you can in ant.
Over all, it’s made my life easier though.
Endolf
How’s it going? Are you planning to put JInput onto Nexus’ OSS Repository Hosting repository? (http://nexus.sonatype.org/oss-repository-hosting.html) If not, what are your plans?
Let me know if there’s anything I can do to help!
Nothing has happened on this at the moment, I might take a look at this over the weekend, but I won’t get any time before then.
Endolf
Hi again!
A number of projects have successfully used LWJGL and JInput using the http://www.newdawnsoftware.com/maven2/ repository for quite a while now. However, these last couple of months some people have worked on moving LWJGL to the Central Maven Repository. We use the following project to package LWJGL: http://code.google.com/p/lwjglmavenizer/.
It would be nice if JInput got moved to the central repository as well, so no repositories would be have to be added to fetch everything. Is there a specific reason why that is not the case at the moment? Is there anything I can do to help?
See https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement for the Maven Central requirements.
Thanks!
I have no objection to someone looking at the jinput pom and supplying a patch to make it work with the sonyatype requirements
Endolf
That’s great!
I made a pom.xml file using the one at http://www.newdawnsoftware.com/maven2/net/java/games/jinput/2.0.1/jinput-2.0.1.pom. Here it is:
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>net.java.games</groupId>
<artifactId>jinput</artifactId>
<version>2.0.1</version>
<packaging>jar</packaging>
<name>Maven Default Project</name>
<description>The JInput Project hosts an implementation of an API for game controller discovery and polled input. It is part of a suite of open-source technologies initiated by the Game Technology Group at Sun Microsystems with intention of making the development of high performance games in Java a reality.</description>
<url>https://jinput.dev.java.net/</url>
<licenses>
<license>
<name>The BSD License</name>
<url>http://www.opensource.org/licenses/bsd-license.php</url>
</license>
</licenses>
<scm>
<url>https://jinput.dev.java.net/source/browse/jinput/</url>
<connection>scm:cvs:pserver:cvs.dev.java.net:/cvs:jinput</connection>
</scm>
<developers> <!-- Modify this! -->
<developer>
<id>endolf</id>
<name>Endolf</name>
<email>endolf@example.org</email>
</developer>
</developers>
</project>
The developers element will need to be modified to match the list of JInput developers.
Someone representing the JInput project will have to register with Maven Central. Follow steps two and three here: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide.
The Central Maven Repository requires -javadoc.jar and a -sources.jar files for JAR packaged artifacts, so we need to create these using Ant targets. I was able to view the build.xml file but I could not checkout JInput. (Is there an anonymous user? Should I register on dev.java.net?)
When everything is in place, the project can be signed and deployed using Ant: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-7c.StageArtifactswithAnt.
Thank you so very much for making this possible!
Let me know if there is anything else I can do to help.
Best,
Jon Kristensen
You will need to register with java.net to be able to check out jinput. Not my rules I’m afraid.
Endolf
I think we should modify the JInput Maven configuration to provide the native dependencies as artifacts instead of classifiers. I believe a classifier of an artifact should be more like another view of the same program, such as the source or javadoc. I’m happy to do it.
Please let me know what you think.
Best,
Jon Kristensen
I am not sure what is the best way to do this. Until now I have been using classifiers to indicate the natives, as I think that it is a nicer place to put a naming convention, like natives-windows, natives-linux, etc in order to enable some automatic processing. I am not so sure how much I like having to force a naming convention into the artifactId.
from the maven reference:
# classifier:
The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number.
As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use.
Another common use case for classifiers is the need to attach secondary artifacts to the project's main artifact. If you browse the Maven central repository, you will notice that the classifiers sources and javadoc are used to deploy the project source code and API docs along with the packaged class files.
they talk about using classifiers to separate acording to jre versions, which I think is a similar case to what we are talking here.
at least for now, my vote is to have the main jar, as the main artifact of a library, and the natives as attached artifacts using the classifier with a fixed format like
natives-windows, natives-linux, natives-mac
Rubén