Don't (yet) use maven range dependencies as its too unreliable and causes build and dependency tree check failures

After the 2.17.02 tagging of hippo-cms, its hippo-repository dependency version was set to [2.17.02,2.19.00).
However, this is causing (Hudson) build failures now as well as can be reproduced using mvn dependency:tree on the cms/trunk/api/pom.xml (using maven 2.2.1):

[INFO] Building CMS API
[INFO] task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree

]
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] version was null for org.onehippo.cms7:hippo-repository-api
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.NullPointerException: version was null for org.onehippo.cms7:hippo-repository-api
at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:390)
at org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225)
at org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.manageArtifactScope(DependencyTreeResolutionListener.java:358)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:574)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:527)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.manageArtifact(DefaultArtifactCollector.java:465)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:315)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:435)
at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74)
at org.apache.maven.shared.dependency.tree.DefaultDependencyTreeBuilder.buildDependencyTree(DefaultDependencyTreeBuilder.java:102)
at org.apache.maven.plugin.dependency.TreeMojo.execute(TreeMojo.java:249)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)

The exact same error is reported by Hudson which is why I suspect this change to use a range dependency is the cause of the Hudson build failure too.

Besides this, maven range dependencies still are source and cause of far too many issues (just google it) that we can already start using it reliable.

Therefore, I'm marking this as a bug and will revert it to using explicit versioning again.