So lets say you have a common library repo. A release changes library latest version from 1.1 to 1.2.
Now any microservices that use this library need to have their pom.xml files updated manually.
Appreciate any suggestions on how to get around this.
There are couple of options;
On the dependent projects pom.xml execute mvn
versions:use-latest-releases command to automatically upgrade
dependency versions.
If all the projects are inheriting from same parent(and dependency configuration is done through dependency management), you can use mvn versions:set -DnewVersion=xx on the aggregator pom.xml to upgrade versions.
If versioning will happen quite often, Snapshot versions can be used.
Related
I would like to use the jgitver maven plugin to automatic define the version of eclipse plugins, features, repository that are built with tycho in pomless mode.
The version management of this 3 plugins are:
jgitver computes a version depending on git tree and tags, create a logical copy of pom, set the new version and associate the new pom to the current plugin in the maven reactor.
For tycho, version are defined in pom and in manifest.mf or feature.xml files. A version consistency check is performed.
When the pom is not defined, pomless maven generates a temporary pom file named .polyglot.build.properties using versions defined in manifest or feature file.
The input path are defined here and depends on PolyglotModelUtil.
The easier way would be a Jgitver evolution to locally update the feature.xml and manifest.MF. It would be a bad idea because a local file would be modified that is not compliant with the plugin philosophy.
A better way would be a Jgitver evolution to generate temporary feature.xml and manifest.MF files that would have been updated with the computed version. Then tycho and tycho-pomless should be forced to use them.
It seems to be possible if i succeed in setting a new ModelProcessor.LOCATION option
Do you think it's an effective way to solve this compatibility problem?
Do you see an alternative?
Thanks for your help.
You could also use directly the jgitver library to participate into your build environment ; it is a pure java library.
The library is the base of both the maven and gradle plugins.
I recognized that Maven not always uses the latest version of a plugin.
For example org.codehaus.mojo:sonar-maven-plugin version 2.7 has beed released on 19th of October but on 23th of October, 2.6 was still used by Maven (mvn sonar:sonar).
I even remember some plugins, where the latest version was several minor releases above the version that Maven decided to use.
Is there any (central) index/list/database where Maven looks up what version to use? If yes, where can it be accessed manually?
I know this is an ancient thread but in the interest of posterity and accuracy: all pom.xmls logically inherit from the super POM. You can always see what your "real" pom.xml looks like by typing:
mvn help:effective-pom
The resulting pom.xml that is printed is a combination of the super POM, your pom.xml, and of course any parent POMs in the mix as well.
The super POM is provided by the org.apache.maven.model.superpom.DefaultSuperPomProvider class (https://github.com/apache/maven/blob/bce33aa2662a51d18cb00347cf2fb174dc195fb1/maven-model-builder/src/main/java/org/apache/maven/model/superpom/DefaultSuperPomProvider.java#L56-L85). The resource it loads is org/apache/maven/model/pom-4.0.0.xml (https://github.com/apache/maven/blob/bce33aa2662a51d18cb00347cf2fb174dc195fb1/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L23-L149).
As far as i know, this link will answer your question.
Automatic Plugin Version Resolution
When a plugin was invoked without an explicit version given in the POM
or on the command line, Maven 2.x used to pick the latest version
available where the latest version could either be a release or a
snapshot. For the sake of stability, Maven 3.x prefers the latest
release version over the latest snapshot version.
Given the threat of non-reproducible builds imposed by automatic
plugin version resolution, this feature is scheduled for removal as
far as plugin declarations in the POM are concerned. Users of Maven
3.x will find it output a warning when missing plugin versions are detected to encourage the addition of plugin versions to the POM or
one of its parent POMs. The Enforcer rule requirePluginVersions can be
used additionally check for missing plugin versions in the POM
For command line execution if a version is not specified Maven looks up the latest version from the GA (group ID/artifact ID) maven-metadata.xml file.
Example: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml
If you're encoding command line execution of Maven goals into your builds you should specify a version for these, otherwise your builds may change as new versions of plugins are released.
Per a previous question on here, I was able to run:
mvn com.isomorphic:isc-maven-plugin:1.1.1:install -Dproduct=SMARTGWT -Dlicense=LGPL -DbuildNumber=5.0p -DbuildDate=2014-11-30
This did work. But I wonder ... do we need to do this again for the latest build? How do we even know where to find the latest build. I just want to use the latest, stable version, and not a nightly build.
Also, what is the correct dependency for SmartGWT 5.0p in my pom.xml file?
I have the old version which worked with 4.0, or do I need to use a new dependency? Is there anything else I might need to add to my pom.xml file?
Believe I hit Google for the last two days, and even on the SmartGWT Isomorphic site I still couldn't find a definitive answer.
Thanks for any help!
Due to Isomorphic licence scheme unfortunately if you need to update to a newer smartgwt build you cannot rely on maven "by design" features. You should run the install command again changing buildNumber or/and buildDate as desired.
Example
mvn com.isomorphic:isc-maven-plugin:1.1.1:install -Dproduct=SMARTGWT -Dlicense=LGPL -DbuildNumber=5.1p -DbuildDate=2016-01-07
The dependencies in your pom file should then use:
<version>5.1p-20160107</version>
where 5.1p corresponds to the buildNumber value and 20160107 to the buildDate.
Installed files are in ~/.m2/repository/com/isomorphic/smartgwt/lgpl you can check availability and versions there too.
By design, there is no answer: Maven dependency upgrades are manual.
When appropriate, you can look for new releases of your dependency (in this case SmartGWT), find out what the new version is called in the dependency's public Maven repository, update your project's POM, and update your local repository as necessary (mvn install like in the example, deleting old versions, etc.)
Well, the problem is that I want maven to check dependency version on build and warn me if there are any newer dependency versions (in fact - notify me if I use an outdated version of some module). My maven module A has the following dependency:
<dependency>
<groupId>com.example.mycompany</groupId>
<artifactId>commons</artifactId>
<version>1.0.3</version>
</dependency>
And com.example.mycompany:commons module in fact can already have 1.0.4 version. Is there any way to check version of the dependency in repo and fail the build if newer version is already available.
I hope that versions-maven-plugin can make it. But I can not find appropriate configuration.
If you are using source control and a continuous integration server (which is a safe assumption) you can:
use the versions plugin and let it modify the pom
then use the scm:check-local-modification or the release plugin as the release plugin IIRC checks for local modifications.
Here is an example checking for the latest parent pom:
mvn versions:update-parent scm:check-local-modification -DallowSnapshots=false -DgenerateBackupPoms=false
This problem can be solved with the maven-enforcer-plugin. You have to create your own custom rule, because non of the standard rules seem to match your needs.
The notion of the rule you are going to implement should be enforce dependencies are up to date. To implement the check you could get some inspiration by the versions-maven-plugin you mention.
We have a large maven 3 project with around 250 modules. All modules have version 1.0-SNAPSHOT and modules tree has single parent module with the same version as a tree root.
Project is built with Bamboo nightly and artifacts are installed to a Nexus repository using command "mvn clean install".
It happens that part of modules are built with one timestamp while the rest with the other, something like:
module1-1.0-20121127.150154-7.jar
module100-1.0-20121127.150527-7.jar
In another project I was trying to set dependency to artifacts of this project using specific version of a snapshot dependency (as discussed in this question Maven specific version of a snapshot dependency) but failed to build due to the problem described above.
Does anyone know why maven would use different timestamps and how to fix that?
MNG-6754 was finally fixed in 3.8.2.