Lemur maven dependency resolution

jchappelle · August 25, 2016, 3:44am

For lemur 1.8.2 I’m having all kinds of trouble getting the dependency to download. I just got a new hard drive so my local maven repository is bare. The only way I was able to get it to work before on my old hard drive was by downloading the jar and installing it manually to my local repo. The problem with that is that I don’t get the transitive dependencies for free. I have to resolve them myself and add them to my pom separately. Obviously the downside to that is that when lemur modifies dependencies in a new version then I have to become aware when I upgrade. The error I am getting is as follows:

[ERROR] Failed to execute goal on project jcraft-core: Could not resolve dependencies for project com.chappelle:jcraft-core:jar:0.0.1-SNAPSHOT: Failed to collect dependencies at co
m.simsilica:lemur:jar:1.8.2 -> org.jmonkeyengine:jme3-core:jar:[3.1,): No versions available for org.jmonkeyengine:jme3-core:jar:[3.1,) within specified range -> [Help 1]

I found a bug report on github about bintray and maven version ranges. Not sure if it’s still an issue but the error is certainly complaining about the version range declared in the lemur pom.(As a side note I’ll mention that I’ve stopped declaring version ranges in my pom files because it can cause all kinds of weird non-repeatable build problems. You build one day and it works, next day it doesn’t even with the same source code because of a change in a dependency.)

One thing that tripped me up is bintray. Apparently there’s a separate repository you have to add to your settings.xml in order to get jmonkeyengine and another repository for lemur. I added these to later find out that jmonkeyengine changed group ids of artifacts from 3.0 to 3.1 so the repository I had set up for jmonkeyengine was wrong and I needed to use the org.jmonkeyengine repository and change the group id of my dependencies.

I’ve yet to get it to work through maven properly. Below is my settings.xml.

I’ll also say that I’m not a maven novice. 6 years ago I implemented maven as a company wide tool and even written plugins where I work so I know quite a bit about it. This is really frustrating because I love the using jme3 and lemur when I can get my hands on it.

I can probably add an exclusion to the lemur dependency to get around this or just install to my local repository manually like I did before but I’d like to fix the problem on my side or make you guys aware in case it’s something you can fix on your side.

I’m sure there’s a good reason you guys chose not to put jme3 and supporting projects on maven central but I’m curious as to what that reason is.

Any help is appreciated!

<?xml version="1.0" encoding="UTF-8" ?>
<settings xsi:schemaLocation='http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd'
          xmlns='http://maven.apache.org/SETTINGS/1.0.0' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
    
    <profiles>
        <profile>
            <repositories>
                <repository>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <id>bintray-simsilica-Sim-tools</id>
                    <name>bintray-simsilica-Sim-tools</name>
                    <url>http://dl.bintray.com/simsilica/Sim-tools</url>
                </repository>

             <repository>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <id>bintray-jmonkeyengine-org.jmonkeyengine</id>
                    <name>bintray-jmonkeyengine-org.jmonkeyengine</name>
                    <url>http://dl.bintray.com/jmonkeyengine/org.jmonkeyengine</url>
                </repository>
            </repositories>
            <pluginRepositories>
          <pluginRepository>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <id>bintray-jmonkeyengine-org.jmonkeyengine</id>
                    <name>bintray-plugins</name>
                    <url>http://dl.bintray.com/jmonkeyengine/org.jmonkeyengine</url>
                </pluginRepository>                
                <pluginRepository>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <id>bintray-simsilica-Sim-tools</id>
                    <name>bintray-plugins</name>
                    <url>http://dl.bintray.com/simsilica/Sim-tools</url>
                </pluginRepository>
            </pluginRepositories>
            <id>bintray</id>
        </profile>
    </profiles>
    <activeProfiles>
        <activeProfile>bintray</activeProfile>
    </activeProfiles>
</settings>

pspeed · August 25, 2016, 3:51am

You shouldn’t have to do that. Just add jcenter to your repositories. Everything is there… (even the stuff normally on maven central).

Edit: and those version ranges are specifically there to be maven compatible… so I certainly hope they works. It’s definitely a more obtuse format than gradle would let me do. Hopefully, it’s just your lack of jcenter as a repo. I don’t even think of that because jcenter should be everyone’s repo and I forget.

jchappelle · August 25, 2016, 4:01am

Same thing. Here’s my settings.xml after adding jcenter. I went here and clicked the “Set me up” button on the top right.

<?xml version="1.0" encoding="UTF-8" ?>
<settings xsi:schemaLocation='http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd'
          xmlns='http://maven.apache.org/SETTINGS/1.0.0' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>
    
    <profiles>
        <profile>
            <repositories>
                <repository>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <id>central</id>
                    <name>bintray</name>
                    <url>http://jcenter.bintray.com</url>
                </repository>
            </repositories>
            <pluginRepositories>
                <pluginRepository>
                    <snapshots>
                        <enabled>false</enabled>
                    </snapshots>
                    <id>central</id>
                    <name>bintray-plugins</name>
                    <url>http://jcenter.bintray.com</url>
                </pluginRepository>
            </pluginRepositories>
            <id>bintray</id>
        </profile>
    </profiles>
    <activeProfiles>
        <activeProfile>bintray</activeProfile>
    </activeProfiles>
</settings>

pspeed · August 25, 2016, 4:09am

The problem is that if I don’t use maven-style version ranges that are apparently not working on maven… the f-ing greatest BUILD TOOL EVARRR (sarcasm) then I’d have to publish a new release of maven for every new JME alpha, beta, beta, beta release.

Maybe we should figure out why maven isn’t liking the maven style version ranges and then I’ll fix them. I’m open to suggestion… they pay me to work on maven during the day but I don’t get paid to work on maven in my free time. And I’d rather gouge out pieces of my skin with a melon-baller, really.

So, I’m open to suggestions on figuring out the maven-style version ranges and why they aren’t working here.

Edit: not upset at you and I do really want to fix your problem. My asshole is just sore from all of the new ways maven finds to enter there.

jchappelle · August 25, 2016, 4:13am

haha. I’ve not had too many problems working with maven but I’ve also never published to jcenter or any other public repo and that could be the other wrinkle here. I’m also not defending maven. I use gradle in my Android environment and I love it. We just have so much invested in maven at work that I haven’t played with it much outside of Android Studio.

I’ll look into it and see if I can figure out why it’s not resolving and report back.

jchappelle · August 25, 2016, 4:39am

@pspeed

The problem is that if I don’t use maven-style version ranges that are apparently not working on maven… the f-ing greatest BUILD TOOL EVARRR (sarcasm) then I’d have to publish a new release of maven for every new JME alpha, beta, beta, beta release

Why would you have to do this? If lemur has a dependency on jme3-core version 3.1.0-beta then you don’t have to publish a new version of lemur when say jme3-core version 3.1.1-beta is released. If someone wants to get the fixes that are in 3.1.1-beta they just change their direct dependency on jme3-core to the 3.1.1-beta version. Maven will omit the transitive dependency that lemur has in favor of the new one. Even if a naughty developer added a new method in a patch version like 3.1.1-beta, that method will not be referenced by lemur so it should still be compatible. Now if a method was removed in 3.1.1-beta there could be trouble. But that’s why I think semantic versioning is so important…but I digress.

I think you will remove a lot of headaches in maven if you forget that version ranges ever existed. In fact, I can’t see how they would be good in any dependency management tool. You want a version of your code to build the same every time no matter what, unless the source code changes of course. Version ranges break that integrity.

That’s my two cents. You may have other reasons for keeping it in there.

jchappelle · August 25, 2016, 4:59am

Here is a minimal example pom file that exposes the problem. I did just get the latest greatest maven which is 3.3.9. Not sure if that matters but tomorrow I may test it out with an older version to see.

I simply put this in a folder and put empty src/main/java and the other folders to make it look like a real project.

I made it resolve the 3.1.0-beta1 version first to get that jar in my local repository in order to rule out the possibility of jcenter proxying or any other request/response weirdness. After I got that version in my repository I tried to do a “mvn install” with the version range and it failed. So it’s definitely maven not resolving it. It has nothing to do with jcenter.

I’ll look into it some more tomorrow. Thanks for responding so quickly!

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	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>com.chappelle</groupId>
	<artifactId>deptest</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<name>Dependency Test</name>
	<packaging>jar</packaging>
	<dependencies>
		<dependency>
			<groupId>org.jmonkeyengine</groupId>
			<artifactId>jme3-core</artifactId>
			<!--
			<version>3.1.0-beta1</version>
			-->
			<version>[3.1,)</version>
		</dependency>
	</dependencies>
</project>

pspeed · August 25, 2016, 5:01am

This is where I got the spec:
http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html

…and it works fine in Gradle. But so did 3.1.+

jchappelle · August 25, 2016, 5:12am

I agree according to the spec it should work. My guess is the beta1 qualifier is throwing it off.

I can get by it so don’t go to trouble just for me. I just figure it might frustrate future users.

This may be a good opportunity for me to switch to gradle anyway. In fact, that’s what I’ll do. I’ll post plenty of swear words if it can’t resolve it either

pspeed · August 25, 2016, 5:14am

LOL. Well, gradle is my main jam… so it should work because it works for me in many projects at this point.

Empire_Phoenix · August 25, 2016, 7:42am

Ahahahaha … I’m currently paid to make maven build a cordova hybrid app for ios and android, without having any sdk installed on the buildserver, I certainly feel kinda like a (anal)prostitute at times, just with less fun at the job.

I also do gradle at the job, but at least it comes with some lube and is not that painful:P

david_bernard_31 · August 25, 2016, 11:42am

to avoid this version range issue with my jme lib:

I don’t use range for jme, I used the exact version I build and test it (reproductible build of the lib)
I mark the dependency as provided/compileOnly => so end-user should declare it explicitly

my 2c

Edit: you can’t trust that this version of lemur will work with jme 3.1.12

pspeed · August 25, 2016, 12:11pm

Then the JME core devs screwed up.

jchappelle · August 25, 2016, 12:47pm

Just another thought about this.

We use Apache Wicket where I work. It’s a MVC front end Web framework like JSP or Spring MVC. Their core framework is a maven multi module project and they have a separate project on github for supporting libraries called wicketstuff. The wicketstuff project is a large multimodule project that gets released when the core project is released so their version numbers move together and the 7.2.0 version of wicketstuff depends on wicket 7.2.0.

So I’m my pom I change one property and it all just works.

So lemur, lemur-proto, zay-es, sky-control and others could be under a monkeystuff project. Or maybe monkey-business

I don’t know if that fits with what you all are doing but I thought I would throw the idea out there.

pspeed · August 25, 2016, 12:56pm

That’s the kind of approach that leads to JME’s five year release cycles… so if you want that one bug in the terrain editor fixed you have to wait for the rest of the project.

I’ll continue to release the parts seprately because its easier for me, easier for everyone else, and means I can release the parts more often.

If someone else wants to go through the trouble of a double-release then that’s up to them.

…that still won’t fix maven, though.

jchappelle · August 25, 2016, 3:02pm

Ok I ran “gradle init” and then “gradle build”. Tweaked the parent build.gradle to get the build to run.

Now I’m having an issue downloading jbullet.

It’s trying to access it here and it’s definitely not there.
https://jcenter.bintray.com/org/jmonkeyengine/jme3-jbullet/3.1.0-beta1/jme3-jbullet-3.1.0-beta1.jar

Here is the dependency:
compile group: 'org.jmonkeyengine', name: 'jme3-jbullet', version:'3.1.0-beta1'

I think I’m almost there I just need one more nudge.

Thanks everyone for the help thus far.

david_bernard_31 · August 25, 2016, 4:20pm

jbullet is/will be deprecated in 3.1.0, switch to bullet native.

jchappelle · August 25, 2016, 11:07pm

Ok thanks

hololol2 · October 3, 2016, 9:17pm

I just had the same problem and found the cause and the solution:

https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm

Basically it says that for maven 3.1.0-beta1 is an older version than 3.1.0 (==3.1) so it does not consider the beta (and alpha) builds.
The solution would be using something like [3.1.0-alpha1,). At least it works for me and i don’t see why it shouldn’t do for others