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.
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 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 .
I am new to enterprise application developement and trying to create a REST server with Spring REST, JPA taking to mySQL database and Javascript on the client side. As I see loads of opensource libraries doing specific task, I started off with using 'maven project' with different 'arch type' (which is nothing but predefined POM with relevent libraries as I understand) provided by Eclipse. But I often run into version mismatch issues, in many cases found specific solution to that perticular libraries in StackOverflow or other sites.
Hence I started looking for a information these version dependancies such as, this version of JPA works with that version of Hibernate library and so on. I checked maven repository of major libraries, I did not find such information so far.
My queries are:
Where can I find these information about the versions dependancies?
Are these pre defined POM in eclipse reliable? Who owns them, where can I get last modified dates on these maven 'arch types'? (I find the ones I choose having fairly old version of libraries).
If I have to start off on my own creating a Maven dependacies, where will I get information about what are the dependent libraries, for example, if I need spring MVC, for sure it needs java servlet library. I am worried becuase the maven 'spring-mvc-jap' arch type whooping 50 libaries as dependancies.(Coming from embeded domain, I find to too hard to digest :D). So not sure if it is the right way.
Please correct if I am missing anything in my understanding.
You can find this information, if you are using maven and some IDE you can go to the dependancy and make click un > and this will show the librarys used for this dependancy or if you want to use the console you have http://maven.apache.org/plugins/maven-dependency-plugin/examples/resolving-conflicts-using-the-dependency-tree.html this will show the same that the IDE.
After normally in the documentation of the library used, you can find some doc about the dependancy about this.
Other solution is get the .jar and use 7zip to see the POM and know the dependancy used.
And for finish my answer if the IDE tell you that you dont have x dependancy normally you have to add this because any of the other dependancy used have it (they used only for the compiling task), but sometime somes projet change a lots of code between the version .a to .b so you will have some problem using the version .b, at this moment i didnt find one good and easy way to fix this, only using the way that i told you (only if i found some problem in the compilation)
3> I am not sure how it works in eclipse but in IntelliJ IDEA when you start using some class without proper dependency IDEA suggest you to add proper dependency automatically. The same approach should be in eclipse.
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'm looking into a solution that displays the subversion revision number and last modification date in my application (written in GWT, therefore reflection is not available). Encode the revision in subversion keyword doesn't work as it applies only to the current file. Is there a better solution using annotation? (e.g., a separate class that's executed during the compile time, grab the latest revision # on the whole project and inject the revision and last modification date to the source code)
I kn
#SvnRevision("$Id$")
public class Foo {
}
Then your classes are all annotated with their version. You need to make sure the annotation is defined as having runtime retention so it can be queried at runtime.
EDIT
OK, since SVN doesn't have that feature, I'd write a Maven plugin to emulate it. Maven has access to the SCM information for every file so during the build phase you could have it do the same keyword expansion.
Annotations are not really designed for this. It's easiest to do it as part of the build.
Using Ant you can generate a file that contains the version information, include it in your application's JAR, load it as a resource on the server, and serve it out to the browser-side code by RPC. Ant can also do string replacement in files as it copies them, which you can use to include the version number in your application's HTML files (no need for RPC then).
No idea about Maven, but I would be very surprised if it could not do the same kind of thing.
Subversion still has the $Id$ feature, but it needs to be enabled explicitly using the svn:keywords property on the files (set it to 'Id').
See also: http://svnbook.red-bean.com/en/1.5/svn.advanced.props.special.keywords.html
So the idea of Jherico above with #SvnRevision would work.