I have builds like: 1.0.0-9, 1.0.0-10, 1.0.0-11, 1.0.0-12, etc.
I've configured my dependency like:
[1.0.0,)
Which means that it should use the latest version from the existing ones (ofc which starts with 1.0.0), but instead of using the 1.0.0-12 it used the 1.0.0-9. I think that it's because the 9 is grater then the 1.
Firstly I would like to force the maven to use truly my latest builds.
I can also have 1.0.0-LOCAL build (which is a local build on the developer's PC). I would like to force the maven to use the 1.0.0-LOCAL instead any other builds if it's available.
I don't know exactly how I could do these, maybe somehow with the settings.xml configuration file which is located on the build machine and on the developer's PC as well.
If I would have a any other way to do this please let me know.
Have a good day,
Arnold Robert Turdean
Update:
It turned out that the Maven Version Range - downloads all the available versions not just the latest one was the original problem.
Which maven version do you use? From Maven point of view all of those given versions are releases? The question is if it wouldn't be better to use a SNAPSHOT version instead?
Furthermore to check if the ordering of your artifacts is correct or work like you expect this can be checked by using this:
java -jar apache-maven-3.3.9\lib\maven-artifact-3.3.9.jar 1.0.0-12 1.0.0-9
Display parameters as parsed by Maven (in canonical form) and comparison result:
1. 1.0.0-12 == 1-12
1.0.0-12 > 1.0.0-9
2. 1.0.0-9 == 1-9
which shows correctly that 1.0.0-12 is greater than 1.0.0-9. So the question is also if you are using a repository manager etc. ? Do you do only a mvn install ?
What I don't understand is your statement about `1.0.0-LOCAL' ?
Apart from that I would suggest to prevent using of version ranges cause they make you build non reproducible.
In maven, dependency hierarchy is so important. Make sure that you don't have other dependencies which added before, into other pom's.
(In hierarchy, maven cares latest dependency.). Dependency 1.0.0-LOCAL must be the latest one.
I suggest to you, while the local developing time use generic -SNAPSHOT, use numbers when you start packaging .
Related
I want to understand the difference between [3.8.2] vs 3.8.2 when mentioned for our dependency's version.
From here ,
When declaring a "normal" version such as 3.8.2 for Junit, internally
this is represented as "allow anything, but prefer 3.8.2." This means
that when a conflict is detected, Maven is allowed to use the conflict
algorithms to choose the best version. If you specify [3.8.2], it
means that only 3.8.2 will be used and nothing else. If somewhere else
there is a dependency that specifies [3.8.1], you would get a build
failure telling you of the conflict. We point this out to make you
aware of the option, but use it sparingly and only when really needed.
The preferred way to resolve this is via dependencyManagement.
But I feel something is wrong here.
if I write <version>3.8.2</version> for our dependency and that version artifact is not present in our maven repo, then it is not picking anything else. Build simply fails.
So, why above they are saying - "allow anything, but prefer 3.8.2."
Also, they say - This means that when a conflict is detected,.... I am not able to understand this. What possible can be a conflict that does not arise for 3.8.2 but arises for [3.8.2] ?
The whole thing works as follows:
Step 1: Maven builds a dependency tree for your project, including your direct dependencies, their dependencies, the dependencies of your dependencies and so on.
Step 2: Now Maven makes a list of all nodes. If it encounters a dependency in just one version (say 3.8.2 or [3.8.2]) it will pick just that version.
Step 3: If Maven finds more than one version, the magic begins.
If all versions are versions without brackets (like 3.8.2), it picks the "nearest" version as mentioned in dependency mediation principle.
If you have some (or all are) version ranges (like [1.0.0,2.0.0]) or fixed versions (like [1.0.0]), then first it finds the intersection of all ranges/concrete version (Note that it does not consider versions without brackets here for finding this intersection).
If this intersection is found null, build fails. If it is not null, then it proceeds further by chooses the "nearest" version/concrete version/version range.
If by nearest definition, we get a version range/concrete version, then maven selects the most recent available version in resultant intersection of version range found.
If by nearest definition, we get a version (not concrete version) , then maven checks if that version is present in resultant intersection of version range found. If yes, this version is selected. If not, then maven selects the most recent available version in resultant intersection of version range (and does not fail the build).
The quote "allow anything, but prefer 3.8.2" is at best misleading. Maven does not try to make up for missing dependencies in the repository, it just "mediates" versions if more than one version is found in the dependency tree.
I'm currently working on a Spigot plugin and have never bothered updating the version number as my plugins have always been private. However I've been wondering if there was a way that does this for me automagically.
I know it's possible using Ant but the answers I've seen so far require an external file in which the actual version is stored, and still requires manual actions.
For those not familiar with Bukkit/Spigot, a plugin.yml looks like this:
name: PluginName
author: Author
version: 1.0
main: path.to.main.Class
So I'm looking for a solution which gets the current version from the file and increments the minor version by 1 and if possible the major by 1 if minor is > 9.
Update the plugin.yml for many reasons (i have many private plugins)
Get into the habit of version-ing your work. What is there to differ your old "changes" to your new ones? Not only that but, that version number can be used through the plugin manager.
Lets say you need to get that version (or some other plugin does) in the future. The ONLY way (besides an MD5 check) to get the version of your plugin, which 9 times out of 10 is to differentiate it from another version of that same plugin.
If your adding it to a server, how do you know which version you are running? For example version 1.1 contains a new command, but version 1.0 does not. You cannot check that if the version was never changed.
You dont HAVE to change it. There is no reason to be required to, but its good to practice development with version numbers like almost all other developers.
However, to answer the automated incremental version, no. You cant modify that compiled jar (unless you get down and dirty with another plugin BEFORE your plugin is loaded). Possibly, you could make some sort of plugin to your IDE to automatically increment it? But do you see where this ends up? Just change it when you feel that you have made progress towards some feature.
I`d like to fetch the number based version number of a maven package programmatically - to be more specific: I need the number of the RELEASE version.
An example:
JUnit is a wellknown maven package. According to http://mvnrepository.com/artifact/junit/junit, the current RELEASE is 4.12.
So given the artifact identifier I'd like to receive the corresponding RELEASE version number (4.12 in this specific case). Since maven is some kind of a repository, I hope that there is an easy way for doing so.
I currently do have two different approaches that might work, however both are not satisfying.
I could create a pseudo java project that requires the dependency by maven. After mvn install it could be possible to get the version number from the jar-Files.
I could do a GET Request to mvnrepository.com/artifact/junit/junit followed by some fancy regex ... definitely not a best practice
Edit:
And here is the magic number three:
http://search.maven.org/solrsearch/select?q=g:%22groupid%22+AND+a:%22artifactid%22&core=gav&rows=1&wt=json
returns a json with the number I've searched.
It is not 100% clear what you want to do but, if you want to be able to use the build version when executing the artifact built by the pom, the following should help.
With the resource plugin you can do token substitution in a resource.This means you can replace any string in a property file or even a java source file with the value of a maven property like ${project.version}.
It is not clear what version you want to have but:
by using a property to specify the version of a dependency like ${junit.version} you can use the dependency version.
by using the builtin project version property you can use the version of the current project.
Currently, my Java applications have the same version on every build. I am using Maven, but I am not sure how to set up the workflow to add a version to the application on each build.
I imagine this works with my version control system? I am using git, does this mean I need git tags?
Thanks for any insights, I know it's a big question, but I am not sure where to get started.
You start by setting your version to, for example, 1-SNAPSHOT.
Then you use the maven-release-plugin to release early and often.
In the interim, each snapshot gets a unique timestamp.
If you want to apply a version that isn't the official maven version, see the buildnumber-maven-plugin.
I use this Maven plugin:
https://github.com/ktoso/maven-git-commit-id-plugin
and get it to generate a git.properties file for me. This includes the commit id, comments, etc.
From there, you can do whatever you like. I have a properties page in my webapp that simply iterates over everything in git.properties. Works for me.
You can use maven POM file to define versions. Here is an explanation.
Also you can update versions using this.
I have a Java project, which is still in a very early stage. There are no real releases yet, so I set version as 1.0.0-SNAPSHOT in my pom.xml.
Before each submit, I perform a Sonar analysis directly from Maven using:
mvn sonar:sonar
Sonar has this nice ability to record changes of KPIs over time. However, it only does that for a version. Now, as I don't update my version number, it overrides the last analysis result and replaces it with the current one.
I wonder how to get around that. I don't want to increase version numbers manually each day as this doesn't seem very natural to me.
What other options do I have? Should I use one of the Maven plugins to add a build number to the version string so that I have unique versions? Do you have any other strategy?
If you want increase version number every release, the maven release plugin is recommendation.
But if you want increase the version number everyday even every build, you can use unique version number like timestamp which can get from Maven building phase, after Maven 2.1, it has the built-in ${maven.build.timestamp} you can use, and you can use format
<properties>
<maven.build.timestamp.format>yyyyMMdd-HHmm</maven.build.timestamp.format>
</properties>
for more information you can visit http://maven.apache.org/guides/introduction/introduction-to-the-pom.html
Sonar does preserve the metrics for each snapshot build (based on your configuration). You can then rename the snapshots suitably and use them to get historical information.
You say that you don't to releases yet. As soon as you do, the Maven Release Plugin is a recommendation. It handles the SVN related stuff that comes with a release.
I'm not sure if this helps you with day-to-day work on a SNAPSHOT, though.