Old versions of maven-dependency-plugin include a dependency:properties goal. New versions don't seem to include it. Has it been moved to another plugin, or is it simply deprecated with no chance to access its features (namely having a property for each dependency, allowing as an example activation of profile based upon dependencies) ?
The properties-goal is available since version 2.2 (the latest version) of the dependency plugin. Maven 3 uses 2.1 as default, so you have to specify the version of the dependency plugin manually in your pom in the build section.
Related
The versions of Maven plugins specified in default-bindings.xml is not latest.
For example, maven-resources-plugin is 2.6, but latest is 3.1.0,
maven-jar-plugin is 2.4, but latest is 3.1.0.
https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml
I think it's not necessary to update default-bindings.xml at every minor version update of plugins.
However, the above is major update.
I know I can change the versions myself if I want.
My Question is why default versions that affect most of the maven users are clearly old.
The thing is you should always pin all your plugin (and I mean all plugins) inside your build which means define the version of all plugins via <pluginManagement>..</pluginManagmenet> this is best practice and you should never rely on those in Maven Core.
Furthermore there is work done in the background to decouple the artifact handlers (plugin binding) from Maven Core and move it to the plugins1, 2 and 3 and so on (which is done in very small steps and will take a long time).
I've got multiple projects using a certain Dependency of Version XX, if I release a new version, I have to touch every project to change it to version XX.Y.
I've came across an approach to edit my m2 settings <version>${my.version}</version>, to add a parameter and bind it into my POM.xml, but this implicit means, everyuser has to manage their m2 settings when I do a new release.
Is there a way to central (user independant) manage the versions as in SVN, so none has to change anything and it always uses the up2date version, if I release a new version?
In general, the maintainer of every project should decide for themselves if they update the version or not. Updating the version might break things, so they may choose to stay on the older version. Particularly, it is important that the maintainers notice that something has changed, so that tests are run.
For development, though, there are Snapshot versions. A Snapshot dependency always references the newest version, but the -SNAPSHOT indicates this to the maintainer of the project. Snapshot versions should not go to production - the builds are not reproducible.
If artifacts are so tightly coupled that they are build together, think about using multi module projects.
You can use a pattern called "Bill of Material".
I think your question is somehow similar to this question (but not exactly a duplicate), and my answer applies here aswell:
You create a new maven project (the bill of material) that only consists of a pom with dependency management block. Here you declare all your dependencies and their versions. The packaging should be set to pom.
This bill of material (bom) project is now used as parent of all other projects. When using a dependency, only group id and artifact id is specified, the version tag is ommited. In that way, the version will be taken from the bom and you have one central place to manage the versions of the dependencies.
More details with examples are here (in the lower part of the page) or here.
in the documentation of maven is written
You'll notice that all plugins in Maven look much like a dependency -
and in some ways they are. This plugin will be automatically
downloaded and used - including a specific version if you request it
(the default is to use the latest available).
Source: https://maven.apache.org/guides/getting-started/index.html#How_do_I_use_plugins
Does "the default is to use the latest available" include snapshots or not?
My team has a common parent project with a module containing several reporting plugin configurations (e.g. checkstyle and findbugs, similar to Checkstyle's multimodule configuration, but in a separate project). I'm going to call the common parent project "common" and the reporting module "build-tools".
I'm trying to find a way to, when the common project is released, to have the common project reference the correct version of the build-tools module without doing a manual release.
Here are a couple of the things I've tried:
Use ${project.version} for the build-tools version number. This uses the version number specified in the projects using the common as a parent.
Use regular version numbers. These are not updated in the common project.
Use a property. Again, the property value isn't updated on release.
Thanks!
Which version of the maven-release-plugin are you using? Try 2.1. That should properly handle the replacement of version properties.
The only way I know to do this is to make common and build-tools the same version and use -DautoVersionSubmodules when you release:prepare. Since common aggregates build-tools, if both modules have the same SNAPSHOT version when you do a release, the release plugin will release and uprev both of them.
Edit: To keep the dependency version correct, your first option should work. In common:
<dependency>
<groupId>com.foo</groupId>
<artifactId>build-tools</artifactId>
<version>${project.version}</version>
</dependency>
That will make your common project always have a dependency on build-tools with the same version as common itself. If they always uprev in lock-step, that should do what you want. Is there a problem with it?
I need to create a maven artifact (org.foo.bar:blarb:1.0.0) that is dependent on exactly two versions of another artifact (org.blab.har:har:1.7.0 and org.blab.har:har:1.8.0, 1.7.1 and 1.8.1 are not allowed).
Others will be consuming my artifact downstream. Unless they explicitly specify, I want the default har artifact used to be 1.7.0. But, there can be something added to the pom to specify 1.8.0. (If it is not possible to specify a lower version as the default, I can live with 1.8.0 being the default, but would prefer not to.)
Can you show me a snippet that I would place in the blarb pom so that this can happen?
One possibility is to use version ranges.
You could try specifying the following in the dependency for org.blab.har:har
<version>[1.7.0],[1.8.0]</version>
This will indicate to maven to pick either 1.7.0 or 1.8.0. I guess the default would 1.8.0 (the higher version)