Why does maven X.X.X-SNAPSHOT not satisfy a version range starting with X.X.X? - maven

I work on a large set of Maven-built services with a parent pom that uses a BOM using version ranges. In general, this works perfectly fine, when the available version is NOT a snapshot.
I'm now working on some new code that uses the same mechanism, but the only available version is a SNAPSHOT version. When I run the Maven build, it says "no versions available".
My version range is "[2.9.0, 2.9.100]". The available version is 2.9.0-SNAPSHOT, and that fails.
In a related version, using a version range of "[2.7.0, 2.7.100)", when the available version is 2.7.0 or 2.7.1, this works fine.
From what I've read, I believe it implies that "2.9.0-SNAPSHOT" is "more than" 2.9.0, so this should work. Just in case, I tried an experiment of changing the range to "[2.8.9, 2.9.100)", but it still says there is no version available.
I'm aware of the advice that "version ranges are not recommended". In general, this works for us. Do snapshots not work with version ranges?
I'm presently using Maven v3.8.2.
Update:
Note that if I change the version range to "[2.9.0-SNAPSHOT, 2.9.100-SNAPSHOT)", it does accept the "2.9.0-SNAPSHOT" version. I'm not sure if that helps in the long run.

Here's what you can do: java -jar maven-artifact.jar n1 n2 n3 ... nx
The maven-artifact jar that's part of every Maven distribution is also an executable jar, where you can add version numbers. E.g.
D:\>"%JAVA_HOME%"\bin\java -jar d:\apache-maven-3.8.1\lib\maven-artifact-3.8.1.jar 2.9.0 2.9.0-SNAPSHOT
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 2.9.0 == 2.9
2.9.0 > 2.9.0-SNAPSHOT
2. 2.9.0-SNAPSHOT == 2.9-snapshot
The rational: 2.9.0-SNAPSHOT will result in 2.9.0, hence the SNAPSHOT is before/smaller and will not be included if you o [2.9.0 .
Here's the related javadoc: https://maven.apache.org/resolver/apidocs/org/eclipse/aether/util/version/GenericVersionScheme.html

Related

Build-Jdk-Spec version in Manifest.Mf

I am using logback-classic 1.3.5 in my project but it is giving me UnsupportedOperationException. My project is on JDK 8 and when I saw in manifest file of logback-classic-1.3.5, it shows build-jdk-spec version as 19. I just want to know what exactly this "build-jdk-spec" version specifies
The build-jdk-spec attribute is a "default" attribute added by the Maven "maven-archiver-plugin" (reference). The value is the value of the ${java.specification.version} property for the build. It is (I think) the JDK version of the JVM that was running the build tool (Maven).
The [build-jdk-spec] version number most likely doesn't signify anything that is relevant to your problem. (It is NOT the the target Java version for the build!!)
The real cause of your problem can be deduced by looking at the details of the UnsupportedOperationException stacktrace.

how to change gradle version in nativescript

I'm confused as how to change a specific configuration somewhere to determine the version of my gradle, in a nativescript project.
My workspace is created with nx and when I try to run the app with npx nx run test:android I get this error message:
Could not compile settings file '<somepath>\start\learn\apps\nativescript-test\platforms\android\settings.gradle'.
> startup failed:
General error during conversion: Unsupported class file major version 62
Based on my research if I need to resolve this issue I need to either update my gradle version or downgrade my JDK version. The solution I'm searching for is to how to specify my gradle version.
Thanks in advance.
based on my understanding version of gradle is defined by #nativescript/android package (read its README.md), so if updating the #nativescript/android doesn't help do the next steps
1- install jdk 18 -> because its the first version that supports major version 62
2- add JAVA_HOME to env vars
3- in platform/gradle.properties add org.gradle.java.home=C:\\Program Files\\Java\\jdk-18.0.1 (because in my case gradle didn't read form JAVA_HOME)
4- change platform/gradle-wrapper gradle version to 7.4.2
5- in platform/build.gradle do this: replace whatever version of plugin to classpath 'com.android.tools.build:gradle:7.2.0'

Does drools-6.5 has backward compatibility of drools-2.5?

We are using drools-decisiontables-2.1.jar to generate XMLs from Rulesheets(.XLS file). And, using drools-core-2.5 version to read those XMLs.
Now, we are upgrading from weblogic11g/Java6 to weblogic12c/Java8 and drools-2.5 is failing.
JARs used in our project: drools-base-2.5.jar, drools-core-2.5.jar, drools-io-2.5.jar, drools-java-2.5.jar, drools-smf-2.5.jar
Issue we are facing in our code:
RuleBaseLoader loadFromInputStream drools 2.5 compilation error on Java8 and weblogic12c
Does drools-6.5 JARs has backward compatibility of drools-2.x for XMLs so that we can easily upgrade to newer versions of drools ?
Thanks in advance !

Gradle equivalent of maven-versions-plugin

This is my build.gradle:
group 'whatever'
version '1.0.0-SNAPSHOT'
...
dependencies {
compile 'whatever:2.2.1-SNAPSHOT'
}
I want to automate releasing process, which includes the need to set both versions to particular values, e.g. 1.1.0 or 2.2.0 using command line only. Any kind of autoincrement is not an option.
With Maven, I'd do this using maven-versions-plugin:
mvn versions:set -DnewVersion=${WHATEVER_NEW_VERSION}
How can I do the same with Gradle? I only found this unanswered question. There must be some simple way to do that?
I ended up extracting version numbers to gradle.properties and updating them as part of the automated build script using sed:
sed -i -e \"/someVersionNumber=/ s/=.*/=${SOME_NEW_VERSION_NUMBER}/\" gradle.properties
It's what I want. Although for me, coming from the Maven background, this doesn't seem natural. I may research another alternative later.
Though not related to publishing, one way to pass command-line properties is as follows:
gradle -PWHATEVER_NEW_VERSION=2.0.0
Consider the following build.gradle snippet:
def newVersion = project."WHATEVER_NEW_VERSION"
println newVersion
See ~/utils/gradle/version.gradle in this project for another approach. It uses separate environment variables for major, minor, and incremental versions and then builds the string automatically. Because it resides in the gradle directory, it can simply be imported into build.gradle, which hides some boilerplate.
I successfully used Axion Release Plugin a couple of times and was very satisfied. Functionality-wise it comes the closest to what Maven's

Project won't compile in IntelliJ IDEA after adding Maven support because of complaints about the JDK version

I'm using IntellJ 14.1.4 Community Edition
My project compiled fine before (I have it set up to use the Eclipse compiler)
But I tried to Mavenize it...
I added Maven via the Add Framework | Maven command
Now my problem is (still using the Eclipse Compiler)...
It gives me error messages like:
Error:(21, 78) java: '<>' operator is not allowed for source level below 1.7
Which leads me to suspect that it is not compiling to 1.8
However, I didn't change anything other than Mavenizing it
The Project SDK in IDEA is set to use 1.8
I did notice some setting about bytecode being 1.5.. but i tried to change that to 1.8 but still get this error message.
Anyone have any clue what's going on?
this was essentially the correct advice of course - in the comments, however I had been trying to do it for a long time both via maven-compiler-plugin and properties... to no success, even though I was refreshing Maven after making changes to pom.xml. Finally, I restarted the IDE .. and .. it works! I can compile..

Resources